Kanban systems for software, derived from the Toyota Production System, are an iterationless approach for scheduling work. Instead of using a time boxed iteration and planning meeting, the pulls stories from the backlog only when it has completed its previous work.
According to Dave Nicolette, an Agile coach with Valtech: “Some in the agile community seem to be turning into shadetree handymen. They've got a single model for agile work that they apply to every situation. When all you've got is duct tape, everything looks like a duct.” He thinks that its important to expand our repertoire beyond the basics of Scrum/XP and become familiar with other tools like Kanban.
There are variety of approaches to implementing Kanban in software development teams. James Shore, author of The Art of Agile Development, writes about one: “The team takes a story from the backlog, develops it, and ships it as soon as it is done. Then they take the next story from the backlog, develop it, and ship that story. Work is shipped as soon as it's ready, and the team only works on one story at a time.” According to James there several key elements in to making a Kanban system work:
- Minimally Marketable Features (MMF): An MMF is the smallest feature that has value to the market. MMF’s are maintained in queue (much like the Scrum Product Backlog), but with a strict limit to the size of queue (James prefers two to three, Arlo seven).
- Work In Progress: The team works on the most important item until its completed. They only work one item at a time, breaking it down into many small discrete tasks.
- Estimation: Instead of using formal planning and estimation its assumed that MMF’s all have approximately the same size. By tracking the average time to complete a feature it is possible to come up with an good idea of the waiting time for each item in the queue.
- Urgent Items: Occasionally emergency work crops up. A single slot is kept for emergency work – this slot bypasses the backlog and the team works to complete the work as quickly as possible. If additional urgent work appears it goes through the regular backlog.
- Bugs – are fixed immediately if the feature is in progress. Otherwise they’re placed in the backlog.
David Anderson, author of Agile Management and Kanban proponent, says that his recipe for success is: “Focus on Quality, Reduce Work-in-Progress, Balance Capacity against Demand, Prioritize”.
Corey Ladas answers the question of Why Pull? Why Kanban? by saying:
People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy. … I think kanban solves this problem more efficiently than the known alternatives.
David Laribee, introduced Kanban at his former employer Xclaim because, after two years of using XP he was having trouble surfacing the impediments and problems. In addition he felt that was a lot of waste involving over processing in the planning, retrospectives and demos. He feels in the end every good agile team will derive its own process: “Of course we can't get there from day one. We need to setup a good baseline with the practices we know have broad applicability, acceptance, and tolerance: TDD, rolling wave planning, etc. Good Agile teams, however, continually adjust their process to fit their product and the needs of their customers.”
Kanban discussion happens on the Kanban mailing list.
Previously on InfoQ on Kanban: Future Directions for Agile, Visualizing Agile Projects using Kanban Boards, Scrum-ban Paper Adds Kanban to Scrum
