Well actually my award for best QCon London talk goes to "A Kanban System for Software Engineering".
Kanban is probably best known as a lean, JIT production scheduling method. The approach is basically “pull” based as opposed to” push. A "push" method requires accurate forecasting of demand in order to plan levels of effort.
Kanban can be more responsive to changing needs (changes in customer demand) by having later stages in a production pipeline signal that items of work are needed. Item of work are pulled into and along the production pipeline. In Kanban tokens (for example cards) can be used to signal that a later stage in a pipeline is ready for more work.
In the context of software development projects, Kanban promises "iteration-less" development, no more estimation, increased productivity and morale.
Like a lot of agile things, to get started all you need is a white board and post-its. However the speaker David Anderson, was anxious to dispel the myth that Kanban was in fact anything to do with whiteboards and post-its.These are enabling "technologies" and they also help create the foundation for transparency as well. However the real issue is:
“How much work is currently in progress?”
I’ll come back to this point, but essentially “work in progress” is what Kanban is all about.
So let’s have a look at the claims that the speaker made.
Development without iterations? Otherwise known as "Is he mad?"
In a nutshell, everything is just one big iteration. Releases may be made every two or whatever weeks, but work comes from one single work queue. There is a concept of lead time, which is how long something should take to get from start of pipeline to production, but this is not the same as an iteration, and it does not have to synchronize with a release schedule.
Items are taken from a work queue and enter a process, a pipeline or something that whatever you want to call your sequence of stages. The stages that make up the sequence are those “things that need to be done” with the item of work. Those "things to be done" can be analysis, design, development and so on right up to release.
The decisions about what items enter work queue and their priority are taken by the customers or product owners.
The approach I’ve just mentioned (analysis, design, development) sounds a bit waterfall. In fact the Kanban approach can happily accommodate the waterfall approach to development. There is no need to mandate any particular life cycle or development methodology for a project.
As mentioned before a key ingredient in Kanban is the notion of “work in progress”. Work in progress is a central variable that the Kanban system is focussed on controlling. The idea is to set specific limits for work in progress in any stage of the pipeline.
In the talk, David gave an example of a team with three developers, in which only three items could be in the development portion of the pipeline at any one time.
For each stage, the number of items of work in progress can be different and adjusted according to observed throughput. The system is explicitly setup to allow such adjustments by the members of the team.
No more estimation? Otherwise known as "Is he mad?"
I admit this one, while very attractive (since I can't estimate ... never have been able to, and don't think I ever will), is a bit difficult for me to comprehend.
Let’s say you can only have three items of work and an agreed lead time. Without estimates, how can I tell if I grab the next item off the queue that it will fit into the lead time? David did mention that items can be bounced back if considered too big, so I suppose there is a bit of sneaky just in time estimation involved somewhere.
At basis I think, in the example provided, it was not so much that there is no more estimation that is the issue. The point here is that that system focuses on the elimination of waste. Therefore where estimation was considered wasteful it was eliminated. So I may be misrepresenting Kanban to say that there is no more estimation. This may be particular to the example given. I'll update you when I am enlightened enough to understand more.
Increased morale and productivity? Otherwise known as "I hope he is not mad"
With regard to morale and productivity I think the latter stems mainly from the elimination of waste (download the slides - in the project study cited in the talk it emerged that 33-40% of developer capacity was spent on estimation. The morale boost of witnessing rapid improvement of throughput is something I can easily understand.
In addition I think the approach encourages transparency. This is a bit of an obvious claim given the way in which project details are held. Having a big whiteboard with all the tokens representing items of work, visible to all in the room promotes simple visibility of the state of the project. Physical proximity helps of course. Although it is obvious it should never be underestimated or taken for granted in what is basically a social activity.