The Kanban software development community can be traced back to Agile 2007 in Washington DC. At that conference a number of people were talking about their different approaches to development that they were using. Chris Matts was talking about Real Options and Feature Injection, Arlo Belshee was talking about Naked Planning, and David Anderson was talking about Kanban. All three had some similarities, which inspired a group of people to go away and experiment themselves and share their experiences. The name the group chose to use as an identity was “Kanban”.
Kanban is the Japanese word for visual card, and can have a number of interpretations with respect to software development. Firstly, it could be used to refer to the index card commonly used by Agile teams. Secondly, it could be used to refer to an Agile team’s task board, or story board. Finally, it could be used to refer to the whole system within which an Agile team works.
In his book “Toyota Production System” [i], Taiichi Ohno says, “The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.” With this perspective, a Kanban System for Software Development refers to the whole system, and not simply the tool or the board. The community chose to name the systemic approach after the tool that inspired much of the thinking.
Viewing Kanban as a systemic approach leads to Systems Thinking. Systems can be thought of as being made up of elements, which interact, to meet a purpose. They are more than the sum of the parts, and the system’s purpose is crucial in determining the system’s behaviour.
John Seddon, in his Vanguard Method [ii], says that the way we think about systems usually defines the system which then defines performance. In order to improve a system, we should change our mind-set by first understanding the purpose of the system. This allows us to define measures which help create knowledge about whether the system is meeting that purpose. Finally we can design a method to enable the system to meet that purpose.
Kanban is a way of designing a method, and generating metrics, in order to improve capability to meet a purpose. The remainder of this article discusses five aspects of a Kanban System; workflow, visualisation, work in process, cadence and learning. These aspects are not practices to be followed, but leverage points which help thinking about the method used to change and improve an organisations delivery capability.
Workflow is the understanding of how business or customer value travels through the Kanban System. The Agile community recognised that software development is a knowledge creation activity which includes randomness and variation and the “Inspect and Adapt” mantra is the response which makes the impact visible such that the feedback can be used to learn and respond accordingly. We can take this further by understanding the mathematics and science behind the randomness and variation and exploiting this to our advantage.
Recognising the workflow through an activity such as Value Stream Mapping can give us this additional transparency which we can use to influence our process. Value Stream Mapping is so called because its focus is on understanding how units of value flow through a system. For software development, this can be generalised into how units of value expand into smaller units of work, which then collapse back to deliver the original value.
For example, a specific Benefit to a customer may expand into a number of Features, which may expand into various User Stories,