Traffic Jams! For some it is the bane of driving. Accidents, construction, reduced speed zones are all some of the root causes. But did you know of Phantom Traffic Jams? For no apparent reason the traffic slows to a crawl. No accidents or lane closures and there is no easy way out. Researchers have linked such phantom traffic jams to traffic density and variations in driver behavior. See the creation of a phantom traffic jam even under controlled environment. A trivial reason such as a driver braking too hard, can cause a phantom traffic jam 8 to 10 kms behind. And this traffic jam takes a life of its own. You could spend hours within that jam.
So what does phantom traffic jams have to do with WIP limits on Kanban for software development? Traffic density and variations in driver behavior – do you see a connection? Traffic density = feature backlog list; variations in driver behavior = variations in ETC of each feature in the backlog. If your backlog increases at a greater rate than you can deliver, this indicates that the traffic density is increasing and the risk of a phantom traffic jam increases. If a predecessor task took longer than expected, the duration on all future tasks will increase; i.e. all the successor tasks are sitting longer in the queue for their turn thereby increasing lead time.
Now, if I am driver stuck in such a traffic, I would like to know how long I am going to be stuck for and when might I expect to break free from the jam. This is where the Kanban board comes in handy. Let’s revisit the three main Kanban principles:
Visualize your work
Visualizing your work flow using a Kanban board shows which stage of development each feature is in. This is very helpful in seeing what the total backlog is and what work has been completed. A Kanban board can be very simple with just three queues – To do, Doing and Done, or as complex as outlined in the Agile Development Blog. If you are just starting out with Kanban, you might want to consider implementing a simple board. As you get better at it, you can add more complexities to it.
Limit your work in progress (WIP)
Phantom traffic jams will not occur if the density (number of vehicles on the road) is less than the road’s capacity. Reducing driver behavior variability will also reduce or eliminate the phantom jams. Limiting work in progress has a similar effect on your software development pipe. Limiting WIP to match your team’s development capacity helps ensure the traffic density does not increase the capacity of your team. The Kanban board will help you get to the right WIP limit as you become better at it. Without WIP limits you will continue to pile up partially completed work in the pipe thereby creating the phantom traffic jam. Adding to your WIP without completing anything just increases the duration of all tasks in the queue. If you are a product development shop, having a large duration (lead time) can significantly effect your company’s profitability.
Only start new work when an existing work is complete
The third principle – start new work only when you finish some existing work – also helps keeps the traffic density in your development pipe in check. If you take on more work then you can complete, you will quickly see the density of work in your development pipe increase and will become out of control.
Since software development is a creative process, there are times when you may need to put something aside when you are stuck and pick it up again later. Or customers may not be available for testing when you are done. For that you need a buffer – but adding more tasks to your queue without completing existing ones is a recipe for disaster.
It is going to take some serious effort to have people respect the WIP limits. People in your organization might say, “Do you expect developers to sit around doing nothing until the bottlenecks have been resolved?” WIP limits are designed to help people doing the work resolve the bottlenecks themselves – no one likes to sit idle. This helps develop a culture of ownership. Nothing motivates the management to help you with external bottlenecks when you tell them that you are sitting idle due to WIP limits. If you see backlogs increasing consistently even with WIP limits, that’s an indication to increase capacity.
So in conclusion, Kanban WIP limits are important to reducing lead times on your project. Keep the WIP low – start with two per developer – and see your bottlenecks become visible almost immediately on the Kanban board. Now if there could be some way to warn the traffic authorities of a phantom traffic jam in the making …