Igor's Blog

Every time when I try to introduce Kanban ("visual card/board") Lean system in an Agile team I got the same question - Kanban looks exactly the same as the current index card board, so what is the difference? As I mentioned in my previous post, the main difference that really defines a Kanban system are limits. Logically, the next question to follow is why we need limits.

Well, there is a problem that I see occurring often with the basic index-card task board. There is nothing to prevent accumulating a big pile of story cards that are work in progress. Usually, the bottleneck could happen in multiple places. Sometimes, it is the huge backlog that is constantly and prematurely prioritized, other times it is the familiar pattern of busy developers in the beginning of an iteration and busy BAs and QAs at the end of the iteration. More often than not a big story card queue for testing is left beyond a current iteration without any timely feedback.

Actually, an iteration, which is central part of an Agile practices is a natural time-boxing constraint to how much Work in Progress can be accumulated. However, the time-boxing limit doesn't help in optimizing the overall team workflow and throughput, doesn't avoid premature work.

Let's take a common example of an agile story board:

I see some bottleneck from the pile of story cards in the testing backlog on the picture above but I can't tell for sure if this is a problem. I don't know what the team testing capacity is because looking at the story board I don't see visual indication of the current limit - the time left to the end of an iteration.

So, I have to wait to the end of the iteration to know for sure if there is a problem and I would still not find out where the bottleneck is. Even if all the story cards are completed on time, the basic index-card task board with time-boxing limit show team progress during an iteration but doesn't indicate whether the team has optimal throughput. Also, accumulating a big backlog at some stage of the work in progress (as the big pile of cards in the testing backlog on the picture above) could delay feedbacks (development going in wrong direction until BAs/QAs complete review/testing) and consequently allow for premature work to be done.

At the end, one of the goals of a development team should be to maximize overall team throughput and reduce waste through constantly optimizing team workflow and enhancing teamwork. A Kanban Lean system is one mechanism that can be used to control a workflow and indicate waste in form of bottlenecks.

Kanban is what enables a pull system for just-in-time work. Very simply, there is a queue of work, which goes through a number of stages of development until its done. When someone needs new work to do, they pull it from their upstream queue. Not much different from an Agile story board until here. However, the important element, as I mentioned above, is different type of limits. There are two basic limits – Queue limits and Work in Progress limits.

Queue limits try to achieve just-in-time work and are designed to avoid premature work. The limit should be large enough to keep the team busy (i.e. there is always something in it for the team to start work on), but small enough to avoid premature prioritization (i.e. having things sitting in the queue for too long before they are begun). The later is what pressingly is missing in a typical Agile team story board.

Work In Progress limits are designed to reduce multi-tasking and maximize throughput. The former concept of reducing context switching and performing task sequentially to yield results sooner is very familiar to Agile teams. The later, however, is usually overlooked in typical Agile settings. Maximizing overall throughput by decreasing Work in Progress is often seen in various areas. Simple examples of this effect are traffic jams, where traffic speed reduces as more traffic builds up.
Limiting Queue size and Work In Progress like this can seem unusual for teams, and there is often a worry that team members will be idle because they are having no work to do, but are unable to pull any new work. However, the Queue and WIP limit sizes can depend on type of work and size of a team and should be adjusted to achieve maximum flow and reduce bottleneck. One easy approach is to adjust the WIP limits to the number of available people/pairs in a team. For example, if there are 6 developers in a team and they work in pairs, the size of development Work in Progress limit should be 3. The development Queue size limit should be large enough to keep continues development Work in Progress (so at least 3 story cards) but not big enough to allow premature prioritization on every developer pull (so this would require some adjustment and depends on the Average Developers and BAs Completion Rates as well as the number of BAs. I think that twice the size of WIP could be a good start as a queue limit).

Finally, the consequences of using a Kanban system could be a little surprising or even controversial and could include eliminating the Story Card Backlog (because the immediate queue is the only work of interest), time-boxed iterations (i.e. Sprints) can be eliminated as well because work is pulled as necessary, and consequently estimations can be eliminated because work is not planned into iterations.

Now, most of the questions at this point would be along the lines that if an Agile team isn't estimating or planning within iterations(Sprints), how it can make reliable commitments in front of business product owners.

As a start, Kanban could help you eliminated iterations, estimations and backlogs but can work equally well within a time-boxed limit and with a reasonable backlog size. However, the real answer to that questions is Cadence Lean system, which is an approach to achieve commitment and reliability with a Kanban system and for which I will continue in further post on this topic.

Labels: agile, kanban, lean, Redpoint