Trying to Understand Kanban in Software

I was very interested to hear Karl Scotland's talk yesterday at Minispa2009 about Kanban. I think he's a addressing some very important issues, but as I've said on Twitter, I wasn't quite convinced by his talk. I think he's nearly there and can't quite make out whether the problems are in my understanding; his communication; or in the actual ideas themselves. Anyway, here are some notes on things that I think at the moment are an issue.

Software components aren't car parts

One of the way I try to explain stories when I'm doing agile training or consultancy is that stories are stories. A story is an out-of the ordinary situation which needs resolution. It's news. Software development spends most of it's time dealing with "Man Bites Dog" cases because "Dog Bites Man" cases are already catered for in the language libraries and the API. Software people, project managers and the people who support them with training and consultancy are all what Peter Drucker called "Knowledge workers". Ironically, that means we spend most of the time NOT knowing what we're doing. I'm not sure how well this fits with manufacturing car parts, or assembling cars.

Toyota Production System is a "That would never work for us" method

Anybody who has ever tried to advocate any kind of project management method to someone in an organisation will be familiar with the "That would never work here, that would never work for us," response. What isn't perhaps discussed so much is that exactly that attitude is the root of the Toyota Production System from which Lean and Kanban ideas are extracted.

As I understand it from my reading of Taiichi Ohno's book and from reading "The Machine that changed the world." One of the original spurs for the Toyota Production Method was an understanding that the way that Ford made cars wouldn't work in Japan. They simply couldn't make enough cars to get the economies of scale that Ford (claimed) he was getting. Another realisation was that Japan's demand for manufactured goods was extremely cyclical and so Toyota needed a method that could "smooth" out these oscillations in demand. But Ford's model of hiring and firing low-skilled workers as the need arose simply didn't fit with Japan's cultural understanding of what work was. People worked for the same firm and stayed loyal to it all their lives. Enormous value was placed in the deep knowledge and mastery of skills. Toyota decided to put together a system valued skilled workers and held onto them through all stages of the economic cycle.

This is what I don't see in Lean and Kanban approaches to software. It doesn't say "We need to design our own Toyota Production System that reflects our culture, values and economic cycles," rather it says "we need to use theirs!".

Flow vs frame. How do you know what you're capable of?

This maybe not so much an objection as a lack of understanding. I didn't quite understand what Karl meant by the term "cadence". It seemed to be something like an iteration, but of variable length. I sat up and paid very close attention at this because one of the things that you're always asked when consulting and training about Agile methods is "How long should iterations be?" And so some kind of rule - even a rule of thumb for working this out would be interesting to know about. But at the same time I'm worried that giving up on the idea of fixed-length iterations, results in the loss of information about velocity. And one of the things that I think is vitality important about Agile methods is the ability to get better and better understandings of what you're capable of as a team.

Another way of thinking of iterations is a frame that you put around the work that would be getting done anyway that allows everybody (developers, project manager, clients) to talk about it in an different way, to reflect on progress, to decided on changes of emphasis and direction.

The aim of these comments and objections isn't to dismiss Kaban/Lean approaches because I think they would be particularly well-suited to settings such as web development agencies, where the work tends to turn up in a continuous flow and doesn't necessarily fit itself into time-boxed. Iterations.

Thanks to Karl for an interesting talk.

For further information, contact Mark@agilelab.co.uk (07736 807 604)