Geek Philosophy

Last week at work I transitioned my team to a Kanban system (warning, pdf). I’ve been thinking of doing this for a while, and in fact a lot of the process that I had already put in place was very similar to Kanban, but a couple of recent developments made the time seem right to take the plunge and fully implement the system.

First of all, what is Kanban? Kanban is a term that comes from lean manufacturing that means “visual card”.  The basic idea of Kanban is to have a system that facilitates flow and pull-based scheduling by limited Work In Progress (WIP).  In software engineering, this manifests as a visual process control system such as a whiteboard / cork board with story cards on it, or an electronic version of such a board. This board shows what state these cards are in, such as “backlog”, “in development”, “in test”, “customer acceptance”, and “waiting to ship”. So far, this sounds like pretty basic fare for an agile team.

The real key with Kanban is the limited WIP. All states of the board should have a WIP limit. For active states such as development or test, this intuitively makes sense, as it’s generally agreed that multitasking is not optimal. For a state such as “waiting to ship”, limiting the work in progress ensures that code is always shipped to customers in a timely manner. For a state such as “backlog”, limiting WIP (as opposed to considering the backlog to be the entire collection of defects, suggestions, and new features for the product) makes it possible to stabilize average cycle time (the average time it takes for an item to move from “backlog” to “complete”) and greatly eases prioritization.

As I said before, this is very similar to a system that I had set up for the team over the past year or so.  I would informally limit work in progress (by gathering a list of relatively high priority items in the backlog, encouraging team members to finish off in-progress stories before starting new ones, and shipping frequently). I encouraged a “pull” system instead of a “command and control” style approach, where team members would have a clear idea of relative prioritization and thus be able to choose the next task to work on when they’ve finished their own. I had a card wall that showed the various states that items were in.

What lead me to create a system that was similar to Kanban before I had heard about Kanban? I’ll talk about that in my next post in the series.