10 things to know about Kanban software development

1) Kanban software development originated by David Anderson. Many of the practices and heuristics have been seen on other Agile teams before but they were first described as a cohesive whole by David.

David’s innovation was to explicitly limit the work in progress. This had been done by other Agile teams before but in Kanban there is a well-known limit on the number of work items which may be worked on at one time. The limit is usually quite low, in the teams I have worked with the limit is approximately the same as the number of developers on the team or slightly less.

2) Many Agile teams use a white board to track work during an iteration. Typically this is divided in to three sections: “To do”, “In progress” and “Done.” When a physically limit to work in progress is imposed it becomes useful to split this down further. Work in progress could be: in development, in test, in analysis or in other states. Each of these may have its own limit.

Thus, the second innovation in Kanban is to split the board into many other columns. Sometimes buffers are placed between the limited columns, these may be labelled “ready”.

3) The Kanban test: In November 2008 on the Kanban mailing list, I asked: “What is the defining characteristic of Kanban that make”, in response David Anderson said:

“For me it is simple... Are you limiting work-in-progress? Are you signaling to pull work from an upstream process? If it is a WIP limited pull system, it is kanban!”

Which give a test for Kanban and is pretty much points #1 and #2 above.

4) The Kanban approach was summed up by Karl Scotland when he said (on Kanbandev again):

“a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important - it just happens to be the best way we (or at least I) know at the moment.”

5) The best place to learn more about Kanban is the Kanban dev Yahoo list.

6) There are currently no books on Kanban software development. There is one that comes close, Corey Ladas ScrumBan - Essays on Kanban Systems for Lean Software Development. I’ve read this book and I’m not rushing to recommend it.

7) Kanban derives more directly from Lean Thinking and Lean software development then many of the previous Agile techniques. Once you apply the innovations in 1 and 2 above just about everything else follows.

8) Kanban teams focus more on work flow, the time it takes to get work from one end of the pile to the other. In the extreme Kanban teams dispense with work estimating (which do not add value), iteration planning meeting (planning is an ongoing process), fixed release dates (they release when it is ready) and scheduled retrospectives (they have a stop-the-line approach to address a problem when it is seen).

9) Originally the Japanese word Kanban is two words kan and ban; kan means visual and ban means card. Like many people I talk about Kanban cards but strictly speaking I’m duplicating myself.

In Lean systems the cards are used to pass information, to signal when limits are reached, to signal an out-of-stock situation or some other trigger for action. Thus Kanban has come to mean more than it literal meant, and now the word is used as the name of a method it means even more.

10) Whenever I blog about Kanban I get more hits on this blog. It seems people want to know about Kanban. Actually, I just discovered that at the moment this blog appears on the first page in Google if you search for “Kanban software development.”

The lesson: Kanban is still new and still in its infancy.

For my previous description of Kanban see Making sense of Kanban (and some doubts), Agile and Lean - the same but different, Notes on a Kanban software development experience and there are some other pieces too if you search the blog.