How Is Kanban Different From Other Approaches?

There has been a lot of discussion recently around trying to define what Kanban is. Is it a tool? A process? A philosophy? During a discussion on the kanbandev list, Ron Jeffries led me (probably unintentionally) to an idea for a different way of trying differentiate Kanban from other Agile approaches. Rather than attempt a direct comparison and identification of unique differences, I realised that the various approaches are different only in where they place their emphasis. XP places a lot of emphasis on the technical practices. Scrum places more emphasis on the project management practices. Kanban, places its emphasis on business and value flow practices. As Ron would say, its all the same elephant, but each approach has a different view of it. At the end of the day, its having the most appropriate elephant for any given context that is most important.

Using Kent Beck’s distinction of Primary and Corollary Practices in XP (2nd Edition), I think that Kanban can be differentiated by identifying its Primary and Corollary Practices. As such, these practices may not be unique to Kanban, but are considered the most important. High performance Scrum and XP teams will inevitable use these practices in some form, but I don’t consider them to be clearly described as Primary Practices in those methods.

The Kanban Primary Practices I see (at the moment…) are:

1. Map the Value Stream. A Kanban approach looks at the whole stream of work, from where it enters the scope of the team, to where it leaves. Thus typically, a Kanban system will explicitly include the transformation of work from the problem or idea, through to its release. i.e. Concept to Cash (or Consumption), or Incubate to Liquidate.
2. Visualise the Work. A Kanban approach will make all the work as visible as possible, across the whole Value Stream. In particular, this includes the visualisation of expanding/contracting, or zooming in and out, of work items to make their value/solution, or other hierarchical relationships visible.
3. Limit Work in Progress. A Kanban approach will explicitly limit work in progress. This is distinct from managing work in progress through the use if time-boxes as described by David Anderson. This absolute limiting of work in progress is what makes Kanban a pull system, rather than a very small batch push system.
4. Establish a Cadence. A Kanban approach will create a natural rhythm by setting up a cadence which will help the team deliver. This will typically de-couple the input (planning and prioritisation) from the output (release), allowing more freedom than the time-box, but still providing a framework to release regularly, measure performance and continuously improve.

A Kanban team will almost certainly use Corollary Practices which may be considered Primary in another process. For example, a high performance Kanban team will inevitably use technical practices from XP, such as TDD and Continuous Integration. Other Corollary Practices from other methods might be the use of MMFs and User Stories to manage the work items. Equally Use Case Scenarios and Steps could serve the same purpose. Metrics such as Cycle Time, Throughput, Velocity, Cumulative Flow Diagrams and Due Date Performance are further Corollary Practices which could be used alongside the Cadence. The list is probably endless. The above Kanban Primary Practices set the foundation for a team use whatever other techniques help them be successful.