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.
