This chapter is from the book
This chapter is from the book
This chapter is from the book
Kanban
In software practices, Kanban has become the name of more than the task board; it is also the name of an alternative process, most closely associated with David J. Anderson, who has been its primary proponent.12 Where Scrum uses the team's commitments for the sprint to regulate capacity, Kanban uses work-in-progress (WIP) limits. Kanban models workflow more deterministically with finer state transitions on PBIs, such as Analysis Ready, Dev Ready, Test Ready, Release Ready, and so on. The PBIs in each such state are treated as a queue, and each queue is governed by a WIP limit. When a queue is above the WIP limit, no more work may be pulled from earlier states, and when it falls below, new work is pulled.
Kanban is more prescriptive than Scrum in managing queues. The Kanban control mechanism allows for continuous adjustment, in contrast to Scrum, which relies on the team commitment, reviewed at sprint boundaries.
Recent conferences have featured many experience reports comparing Scrum and Kanban. Kanban clearly works well where the team's workflow is relatively stable, the PBIs are fairly consistent, and the release vision well understood. For example, sustaining engineering projects often have a backlog of maintenance requests that are similarly sized and lend themselves well to Kanban.
In other words, in the Stacey terminology of Figure 1-1, Kanban works well for complicated or simple projects. The jury is out with regard to complex projects. Where higher degrees of uncertainty exist in the process, the explicit sprint cadence of Scrum can prove invaluable. In my experience, the concept of team commitment and the sprint rhythm are empowering to teams working in uncharted territory, the common ground of software development.