In the context of Agile teams where the “Kanban method” of continuous improvement (or some of its concepts) has been followed, the following adaptations are often seen:
- such teams deemphasize the use of iterations, effort estimates, and velocity as a primary measure of progress;
- they rely on measures of lead time or cycle time instead of velocity;
- and in the most visible alteration, they replace the task board with a “kanban board”:
- unlike a task board, the kanban board is not “reset” at the beginning of each iteration
- its columns represent the different processing states of a “unit of value”, which is generally (but not necessarily) equated with a user story
- in addition, each column may have associated with it a “WIP limit” (for “work in process” or “work in progress”): if a given state, for instance “in manual testing”, has a WIP limit of, say, 2, then the team “may not” start testing a third user story if two are already being worked on
- whenever such a situation arises, the priority is to clear current work-in-process, and team members will “swarm” to help those working on the activity that’s blocking the flow
Also Known As
The term “kanban” is Japanese (看板), with the sense of a sign, poster, or billboard, and derived from roots that literally translate as “visual board”. Its meaning within the Agile context is borrowed from the Toyota Production System, which designates a system to control the inventory levels of various parts. It is analogous to (and in fact inspired by) cards placed behind products on supermarket shelves to signal “out of stock” items and trigger a resupply “just in time”. The Toyota system affords a precise accounting of inventory or “work in process”, and strives for a reduction of inventory levels, considered wasteful and harmful to performance. The phrase “Kanban method” also refers to an approach to continuous improvement that relies on visualizing the current system of work scheduling, managing “flow” as the primary measure of performance, and whole-system optimization – as a process improvement approach, it does not prescribe any particular practices.
Common Pitfalls
Kanban boards are generally more sophisticated than “mere” task boards. This is not a mistake in and of itself; however, it is not advisable that the kanban board should serve as a pretext to reintroduce a “waterfall”-like, linear sequence of activities structuring the process of software development. This may lead to the creation of information silos or over-specialization among team members. In particular, teams should be wary of kanban boards not accompanied by WIP limits, not only defined but also enforced with respect to demands from managers, customers, or other stakeholders. It is from these limits that the kanban approach derives its effectiveness.
Expected Benefits
In some contexts, measuring lead time rather than velocity, and dispensing with the regular rhythm of iterations, may be the more appropriate choice: for instance, when there is little concern with achieving a specific release date, or when the team’s work is by nature continuous and ongoing, such as enhancement or maintenance, in particular of more than one product. At the risk of oversimplifying, a “kanban board” setup can be considered first for efforts involving maintenance or ongoing evolution, whereas a “task board” setup may be a more natural first choice in efforts described as “projects”.
Origins
- 2001: Mary Poppendieck’s article, “Lean Programming“, draws attention to the structural parallels between Agile and the ideas known as Lean or the “Toyota Production System”
- 2003: expanding on their earlier work on Lean Programming, Mary and Tom Poppendieck’s book “Lean Software Development” describes the Agile task board as a “software kanban system”
- 2007: the first few experience reports from teams using the specific set of alterations known as “kanban” (no iterations, no estimates, continuous task boards with WIP limits) are published, including reports from Corbis (David Anderson) and BueTech (Arlo Belshee)
- 2007: the “kanbandev” mailing list is formed to provide a venue for discussion of kanban-inspired Agile planning practices
- 2009: two entities dedicated to exploring the kanban approach are formed, one addressing business concerns, the LSSC, and a more informal one aimed at giving the community more visibility: the Limited WIP Society
