Kanban by Example
Typical Agile teams take on work based on their capacity to deliver in a fixed time frame, often called a sprint or iteration. For example, if a team’s sprint length is four weeks, the amount of work they take on in the sprint is based on how many user stories they think they can deliver in that four week time frame.
So, what about Kanban?
In Figure 1, you’ll notice the Kanban board is similar to a Scrum board, except the features don’t have sizes (e.g., story points,hours, etc.) and there are no tasks. Work is managed on a Kanban board by setting limits on work in process (or WIP), which is determined by cycle time and flow. Cycle time is the amount of time it takes for a user story to be ready to ship (or "complete" in this example), after it has been put into WIP and flow is the amount work flowing through WIP at any one time. If cycle time is too long or the flow of items into WIP is too large, then the WIP limit needs to be adjusted. In the following example, the WIP limit is three.
As work is completed, a signal (or Kanban) is sent to the previous step to “pull” more work into WIP, but never more than three user stories at a time. If you compare Figure 1 and Figure 2, you’ll notice that user stories four and five moved from the WIP column to the Complete column. As a result, user stories six and seven were pulled from the To-Do column into WIP. The features going into WIP should always be the next-highest priority items.
Usually, more work is added to the To-Do column and prioritized as the team completes work in the WIP column. Teams that operate in this fashion look to improve cycle time by eliminating waste, rather than committing to deliver work in time-boxed sprints or iterations. Operations and maintenance teams, which often aren't time bound like project teams can benefit from managing work using a Kanban-based approach. In Helix ALM development, we use a Kanban system for managing the Agile Services team work as shown below:
You may be wondering where the WIP limits are. Truthfully, we don't have any. Because our team is relatively small and our impediments are minimal, the cycle time for each story is usually days (as opposed to weeks), which is good for us. However, we are toying with the idea of adding WIP limits as we grow and run into more blocks.
Another consideration is to add additional columns or Kanbans. Usually, the more hand offs, the more WIP columns should be added to allow the team to manage their work better and discover the impediments, bottlenecks, or wastes (in lean terms) that are keeping them from delivering stories sooner. For example, instead of having one WIP column, you may have a "develop" and a "review" column, together representing WIP and each with their own WIP limit. A deeper dive would require a much longer post, but hopefully you get the idea.
The ideal organization will have as few columns (or Kanbans) as possible because of efficiency. In our case, we are using red dots to indicate impediments and, given the relatively small number of them, we are not using additional columns. Again, this may change.
As you've seen here, Kanban is effective for non-software as well as software-related efforts. Due to the limited lifespan of projects and their urgent nature, I have found that delivery methods that use time-boxed sprints or iterations are best for project work. However, for operations and maintenance environments where sustainable pace seems to matter more than speed of delivery, I have found that Kanban works quite nicely and even better in some cases.