I’ve been using Kanban for a few years, quite a few years. I like it and mention it often in this blog, so I thought I would outline some of the basics for the benefit of those who haven’t dipped their toe in the Lean waters. Of course I’ll comment on what I like/dislike about it as I go along.

Origins of The Kanban Method

Just for the record I’m talking about what is now known as “The Kanban Method” which originated as “Kanban for Software Engineering”.

My own introduction to The Kanban Method came from David Joyce who, at the time, worked for BBC World Wide in the building adjacent to mine. David, and hence the BBC, was one of the early adopters. This was back in 2009 although the concept had been around since 2007.

But the inventor of The Kanban Method was a guy called David Anderson at a company called Corbis. Actually calling David Anderson the “Inventor” of The Kanban Method is controversial. From what I can tell all of the ideas existed before – much of them from Don Reinertsen who is the big name on Lean Product Development. However, Anderson has done a very successful job of imposing his brand on a small collection of these existing ideas. So he might not have invented the practices but I’ll give him credit for inventing “The Kanban Method” brand (but not Kanban in general).

Purpose of The Kanban Method

A lot of software people use The Kanban Method and I’m no different. I find it very useful in a software context. However, technically speaking, The Kanban Method is not an approach to software development. Officially it is an approach to process improvement. David Anderson says that:

The Kanban Method defines my approach to incremental, evolutionary change for technology development/operations organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to improve the system. One example of such a pull system, is a kanban system, and it is after this popular form of WIP limited pull system that the method is named.

According to Anderson (2010) an average team can use Kanban to produce world class results. He contrasts this to the craftsmanship snobbery prevalent in Agile community that suggests success comes from having a small team of really good people.

And, by the way, The Kanban Method is also not Agile. David Joyce (2009) suggested being Agile might be one result of using The Kanban Method:

Rather than focusing on being Agile which may (and should) lead to being successful, Kanban focuses on becoming successful, which may lead to being Agile

What does Kanban mean anyway?

I’m not a fan of using Japanese terminology in software development in an English speaking country. So the phrases “coding Kata” and “coding Dojo” give me the shudders. But it is too late – as with the craftsmanship terms the phrase “kanban” is here to stay.

The Kanban Method was inspired by kanban systems used in some Japanese manufacturing systems. In Japanese:

• “kan” means “signal”
• “ban” means “card” or “board”

Putting those two terms together means a kanban is a signal to trigger to action in the form of a signal card. In The Kanban Method these signal cards go on a card wall – the Kanban board.

Kanban Principles

The Agile movement has some underlying principles and all the various methods seem to have some guiding principles of their own. The Kanban Method has some too. I’ve taken these, and much of the detail below, from David Anderson’s post called The Principles & General Practices of The Kanban Method (Anderson, 2010, Updated 2014):

• Start with what you do now
• Agree to pursue incremental, evolutionary change
• Respect the current process, roles, responsibilities & titles

I found these principles quite refreshing after the scorched earth policy of some Agilists. For example, Ken Schwaber (2007), of Scrum fame, advocates organisations abandon whatever they were doing before and do a wholesale transition to Scrum. The entire organisation. That includes adopting both the Scrum process and the Scrum role titles. Despite the benefits Scrum can bring that sort of ground up change comes with considerable risk. So, for me, The Kanban Method’s take-what-you’ve-got-and-improve-it approach is appealing.

Core Practices of Kanban

The Kanban Method includes some core practices or, more accurately, practices have been spotted in organisations with successful Kanban implementations. As of September 2014 the core practices of The Kanban Method are:

1. Visualize (the work, workflow and business risks)
2. Limit WIP
3. Manage Flow
4. Make Process Explicit
5. Implement Feedback Loops
6. Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

It is worth noting that The Kanban Method evolved rapidly and if you look at older material you might find different core practices. For example Anderson’s work in 2010 (2010a, 2010b) listed five core practices. But by 2014 there were six and the words had changed (Anderson, 2010, updated 2014). In general I like the changes that came with the update because the titles of the practices seems to be to make them less prescriptive and more encompassing. Less one-true-David-Anderson-way-ish, if you would.

Visualize (the work, workflow and business risks)

This practice started as “Visualise the workflow” and the obvious manifestation of this is the card wall. In the lean-agile software world this card wall is called a “Kanban Board”, although strictly speaking this is only true if the board has WIP limits and is a pull system.

The point of the Kanban Board is to visualise the workflow of the team and where the work is within the workflow. Often that means mapping the value stream to find the workflow.

The value stream can be quite rough. For example I just sketch it up with stickmen representing somebody doing something and boxes representing the results of their activity.

Limit WIP

Work in Progress (WIP) is the sum of all parts in the workflow. Less is better. When WIP is low Lead Time is shorter and Throughput is higher. So not surprising The Kanban Method is keen on limiting WIP. The practice that enables the team to limit WIP is the “pull” aspect of the approach. Participants in downstream steps in the workflow “pull” completed cards from the upstream steps, but only when they have capacity.

I like all of this. However, it can be quite hard to get teams to enact “pull”. Corporate culture is to “push” and shout when the downstream folk aren’t ready. (There is also the business tendency to “pull” before the upstream process is ready.) Making this change requires careful focus.

Manage Flow

Although now called “Manage Flow” this practice used to be called “Measure and Manage Flow”. And measurement there is in plenty. Most Kanban advocates are very keen on metrics. I’m not so keen but at least most metrics in The Kanban Method are pretty simple. It all starts with counting things. David Joyce (2009), who I mentioned above, is quite keen on measurement. Back in 2009 this is what he recommended people count at the end of each week:

• Number of things in process this week (lower is better) — this is WIP
• Number of things completed this week (higher is better) — this is Throughput
• The same for each of the T-Shirt sizes (Small, Medium, Large)
• The same for things in Development
• Number of things in states of interest for Cumulative Flow Diagram (see below; the delivered portion will steadily grow)
• Number of types of item of interest (e.g. Feature, Fault, etc)

Then you would calculate:

• Average completion rate (items per week; higher is better; use only recent measures to cater for improvement)
• Total Cycle Time (weeks or days; lower is better) = Number of things in process / Average complete rate
• The same for each T-shirt size, e.g. 7.4 days to do a “Small” feature
• The same for things in Development

You can still do The Kanban Method and measure a lot less than this.

The real magic comes with the Cumulative Flow Diagram – a tool I love. This is Kanban’s equivalent of Scrum’s burn up chart. But it comes with much more information. You plot the number of things in states of interest (e.g. pending/inventory, in progress, delivered) on a particular day – that is pretty much the minimum metric to collect.

The whole point of this is to see whether we’ve got a fast smooth flow. Cards moving across the board rapidly in a steady stream.

Make Process Explicit

Anderson (2010, updated 2014) is keen to have “rational, empirical, objective” discussions on process. He believes the way to avoid “emotional, anecdotal and subjective” discussions is to make the policies affecting the process explicit. Not too surprisingly this practice used to be called “Make Process Policies Explicit”.

Although I agree with making process explicit, I’ve seen some folk go over the top here. Remember that these should be explicit, but “barely sufficient”, process policies. Typically this practice manifests as some notes on index cards outlining the exit criteria for key steps in the process slapped on the Kanban board.

Implement Feedback Loops

The “Implement Feedback Loops” practice is the new one of the six, the one added in the Sep 2014 update to the list on The Principles & General Practices of The Kanban Method. Actually adding it to the list of core practices just acknowledges some stuff that was already happening.

Monitoring and Control in The Kanban Method is similar to any other Lean-Agile project so the starting point is the daily stand up. Same meeting different format. For one thing the Facilitator walks the board and does much of the talking. The questions are also different:

1. “Is the board up to date?”
2. “Do we have a bottleneck?”
3. “Do we have an unresolved blocker?”
4. “Are we within our WIP limits?”
5. “Are priorities clear?”

After the stand up the Facilitator updates the charts, removes done items from the board (i.e. those that have gone Live), synchronises any electronic tracker and organises any follow up meetings (e.g. technical discussions).

The Kanban method includes three other specific practices for feedback: the service delivery review; the operations review; and the risk review. These are late additions to the mix and I haven’t explored them.

Improve Collaboratively, Evolve Experimentally (using models & the scientific method)

This practice was called “Use Models to Suggest Improvement Opportunities”. I think the move to “Improve Collaboratively, Evolve Experimentally” is very healthy. “Models”, if you use them, are an implementation detail however the goal is improvement. Retrospectives from the Agile world are one way to “improve collaboratively”.

The sub-text to use “models & the scientific method” reflects the quantitative outlook of the Kanban guys. They love metrics and modelling. Personally I follow the Agile Manifesto and value “Individuals and interactions over processes and tools”. So I’ve very keen to “Improve Collaboratively” and to “Evolve Experimentally” but I’m not keen to put models before people.

Further Reading

This has been a very rough overview. For more detail, or just a different perspective, I recommend:

• Patton, J. (2008, 20 April). Kanban Over Simplified. Agile Product Design.
• Kniberg, H. and Skarin, M. (2009, 21 December). Kanban Scrum Minibook. InfoQ.

References

Agile Manifesto and Principles behind the Agile Manifesto

Anderson, D. (2010a). Kanban: Successful Evolutionary Change for your Technology Business. Blue Hole Press.

Anderson, D. (2010b, 11 Oct). David Anderson: Back to basics with Kanban

Anderson, D. (2010c, 10 Dec; Updated Sep 2014). The Principles & General Practices of The Kanban Method.

Joyce, D. (2009, 24 Apr). Kanban for Software Engineering. Presentation at an internal BBC conference. Author

Kniberg, H. and Skarin, M. (2009, 21 December). Kanban Scrum Minibook. InfoQ.

Patton, J. (2008, 20 April). Kanban Over Simplified. Agile Product Design.

Schwaber, K. (2007). The Enterprise and Scrum. Microsoft Press.