Continuous Improvement with Kanban

Kanban (Japanese 看板, signboard or billboard) is a lean method to manage and improve work
across human systems. This approach aims to manage work by balancing demands with available
capacity, and by improving the handling of system-level bottlenecks.

Work items are visualized to give participants a view of progress and process, from start to finish—
usually via a Kanban board. Work is pulled as capacity permits, rather than work being pushed into
the process when requested.

In knowledge work and in software development, the aim is to provide a visual process management
system which aids decision-making about what, when, and how much to produce. The underlying
Kanban method originated in lean manufacturing,[1] which was inspired by the Toyota Production
System.[2] Kanban is commonly used in software development in combination with other methods
and frameworks such as Scrum

volution and documentation of method

David Anderson's 2010 book, Kanban,[4] describes an evolution of the approach from a 2004 project
at Microsoft[5] using a theory of constraints approach and incorporating a drum-buffer-rope (which
is comparable to the kanban pull system), to a 2006–2007 project at Corbis in which the kanban
method was identified. In 2009, Don Reinertsen published a book on second-generation lean
product development[6] which describes the adoption of the kanban system and the use of data
collection and an economic model for management decision-making. Another early contribution
came from Corey Ladas, whose 2008 book Scrumban[3] suggested that kanban could improve Scrum
for software development. Ladas saw Scrumban as the transition from Scrum to Kanban. Jim Benson
and Tonianne DeMaria Barry published Personal Kanban,[7] applying Kanban to individuals and small
teams, in 2011. In Kanban from the Inside (2014),[8] Mike Burrows explained kanban's principles,
practices and underlying values and related them to earlier theories and models. In Agile Project
Management with Kanban (2015),[9] Eric Brechner provides an overview of Kanban in practice at
Microsoft and Xbox. Kanban Change Leadership (2015), by Klaus Leopold and Siegfried Kaltenecker,
[10] explained the method from the perspective of change management and provided guidance to
change initiatives. A condensed guide to the method was published in 2016, incorporating
improvements and extensions from the early kanban projects.[11]
Kanban boards for software development

Main article: Kanban board

Sample Kanban Board.png

The diagram here shows a software development workflow on a Kanban board.[12] Kanban boards,
designed for the context in which they are used, vary considerably and may show work item types
("features" and "user stories" here), columns delineating workflow activities, explicit policies, and
swimlanes (rows crossing several columns, used for grouping user stories by feature here). The aim
is to make the general workflow and the progress of individual items clear to participants and
stakeholders.

As described in books on Kanban for software development,[4][3] the two primary practices of
Kanban are:

Visualize your work

Limit work in progress (WIP)

Four additional general practices of Kanban listed in Essential Kanban Condensed,[11] are:

Make policies explicit

Manage flow

Implement feedback loops

Improve collaboratively, evolve experimentally

The Kanban board in the diagram above highlights the first three general practices of Kanban.

It visualizes the work of the development team (the features and user stories).

It captures WIP limits for development steps: the circled values below the column headings that limit
the number of work items under that step.

It documents policies, also known as done rules,[9] inside blue rectangles under some of the
development steps.

It also shows some Kanban flow management for the "User Story Preparation," "User Story
Development," and "Feature Acceptance" steps, which have "In Progress" and "Ready" sub-columns.
Each step's WIP limit applies to both sub-columns, preventing work items from overwhelming the
flow into or out of those steps.
Managing workflow

Kanban manages workflow directly on the Kanban board. The WIP limits for development steps
provide development teams immediate feedback on common workflow issues.[4][9]

For example on the Kanban board shown above, the "Deployment" step has a WIP limit of five (5)
and there are currently five epics shown in that step. No more work items can move into
deployment until one or more epics complete that step (moving to "Delivered"). This prevents the
"Deployment" step from being overwhelmed. Team members working on "Feature Acceptance" (the
previous step) might get stuck because they can't deploy new epics. They can see why immediately
on the board and help with the current epic deployments.

Once the five epics in the "Deployment" step are delivered, the two epics from the "Ready" sub-
column of "Feature Acceptance" (the previous step) can be moved to the "Deployment" column.
When those two epics are delivered, no other epics can be deployed (assuming no new epics are
ready). Now, team members working on deployment are stuck. They can see why immediately and
help with feature acceptance.

This workflow control works similarly for every step. Problems are visual and evident immediately,
and re-planning can be done continuously. The work management is made possible by limiting work
in progress in a way team members can see and track at all times