Kanban for software development
Originally posted on March 16, 2010, after a Kanban training with David
Anderson.
I used to have a blog, then discontinued. Here, I am reposting some of the
old content, the one I still like or and that I feel still somewhat relevant.
Overall, my opinion of Kanban evolved from back then, and while I
still think one of the main strengths in Kanban is its explicitness in
showing the process and the bottlenecks, I think now that allowing for some
slack is also a key part of it.
In agile methodologies, Kanban is the new kid on the block.
Extreme Programming, Scrum are ten years old, while Kanban is relatively new –
less than five years. Yet, it’s quite hot: in the blogosphere, one year ago you
could find almost nothing about Kanban applied to software engineering, while
now it is virtually known to everybody.
But what is the meaning of Kanban applied to software engineering?
The Kanban system was developed in Toyota more than half a century ago, and is
one of the key points of lean manufacturing; its translation in software
engineering, however, is not as straightforward and actually I am of the opinion
the name is a bit misleading.
In our case, Kanban focuses on workflows, and their optimization.
As it focuses on process improvement, Kanban may be applied to all kind of
development processes; the only requirements are a whiteboard, and a good
configuration management system.
Analyzing the process, workflow and policies are made explicit.
Then, a limit is set to the work in progress – it means that each phase of the
workflow is not allowed to proceed (and may even stop) until the next step is
cleared.
Finally, there’s the optimization, based on actual, measured data. Optimization
is continuous process, and usually affects workflow itself.
The main advantage of the system lays in its explicitness.
When the process is explicit, everybody can improve it, at any moment: any
proposal may be confronted with the hard data, and changes are easier. On the
other hand, issues are immediately spotted – just because they will impact on
the flow, and there is no way to hide it.
As the process gets streamlined, it becomes more efficient and predictable than
before.