Just finished Henrik Kniberg’s Blogprint book about Scrum vs Kanban and after starting reading I immediately found something many software teams can relate to. It’s the trouble of planning iterations when important customers demand immediate attention. This is against the general principle of Scrum. In Scrum you, the team, commit to a set of work for a fixed set of time N. This is very unfortunate because big customer runs the risk of waiting N days before work on his/her item starts. An alternative is to plan overhead into each sprint but this can be unwanted if the disturbance is infrequent but large. Some teams really need constant re-planning.
Kanban suggests solving this problem using lean software development and by being a smaller scrum: Scrum without sprints essentially. Then there is a team or department-based visual representation of the different states of selected packets of work, just like a scrum board but with more columns (states). Then the trick is to limit for each column the amount of work in that state. This is essential to Kanban and logically called “limiting the Work In Progress”. When implemented this guarantees a more constant flow which is essential to predicting the lead time for an individual packet of work. Constant flow gives you better productivity and you can start estimating lead times to the packets of work, based on the items already done.
The second pillar is more difficult to implement: this is a cultural thing, going from a push based process to a pull based method. This is also essential when implementing scrum or other agile methodologies. What this means is empowering people or teams to pull from a central queue rather than pushing work into them until they say stop (which some people forget to do). Thing to take into account is the accountability. The implementation of this shift is a key step when moving towards a more agile development process.
An easy pitfall for Kanban is in its size: it’s very small. This seems to suggest that implementing it is done at the push of a button but it is not. Kanban shares this shortcoming with Scrum, also a very small process/ritual description. To make it work effectively you must borrow from the older and fatter process descriptions like XP (pair programming / review), RUP (UseCases) and even from scrum (daily stand-up, retrospective) to tune the process. What is Kanban then? It’s an essence of a software development process, not necessarily _the_ essence but a very good choice when you have a team that can re-plan on a daily basis and still be agile. Next for me is reading David J. Anderson’s book Kanban and learning from implementing it at a support and maintenance team. Kanban for software team is a very interesting development that I will keep researching!