Pain in the Bottleneck

One of the crucial properties of Kanban is spotting bottlenecks and facilitating steps, that lead to resolving them. Leaving items too long in the pipeline can cause them to lose value (particularly in case of software). Also, according to the Theory of Constraints, the slowest delivery rate in process - the worst bottleneck - is the delivery rate of the entire system. Quite important to make sure the bottlenecks are being sorted out then, isn't it?

Instead of rushing, facilitate optimization

There is a tendency for when a bottleneck occurs to simply apply more pressure on the developers or analysts to get moving. This – more often than not – causes a decrease in quality and demoralization. With time this will also lead to placing more value in the speed of work, rather than in quality. Not quite what you need.

WIP limits & no WIP limits

Very often, managing and preventing bottlenecks is done with Work In Progress limits. By setting a maximum number of tasks than can be progressed at any time, you're automatically placing a limit on potential bottleneck size. To show the importance of this action, Gareth brings us examples of what will happen, when there is no WIP limit anywhere within the system. The basic process stages are prioritization, analysis, development, testing and deployment.

Bottlenecks in analysis

Clearly, when the bottleneck starts in this early process stage, all the work in next process steps will be affected. If you begin to put pressure on the analysts, the quality of the resources gathered and their breakdown will fall, which will inevitably lead to poorly described and designed items for the developers. This in turn will cause developing items that don't meet the stakeholder's requirements. Also, constant adding of differently prioritized issues to any column will cause wasteful context switching and multi-tasking.

Bottlenecks in development

The problem with work piling up in this stage of the process is that there will be an aging process going on with regards to the information researched in analysis. And since software development is knowledge based, allowing the information to out-date before it gets applied makes no sense. The developers will either have to consult the analysts (and get them to refresh the analysis – basically start them over) or develop basing on what they've been given, often producing a low quality, sometimes unusable item.

Bottlenecks in testing

The main reason for wanting to avoid this is the growing cost associated with items sitting in testing for too long. This is the part of the process where you can and should prioritize getting things finished, not started and continued. Especially, that working on a number of things simultaneously causes great productivity loss (20% on each switch minimum). Should you allow for quality to be compromised over to speed at this point, you won't prevent bugs getting into production, which will have an enormous backlash effect.

Bottlenecks in deployment

Letting ready items sit before deploying is purely giving advantage to competition. You're also losing out on early customer feedback, henceforth reducing your responsiveness to change and market needs.

Conclusion

It makes a lot more sense to apply Kanban with Work In Progress limits. Particularly from the point of view of wanting to deliver with a balanced and foreseeable rate. By applying WIP limits, you're making sure that any impediments and issues occurring anywhere along the process stage are spotted immediately, while all participants still remember the nature of the item. So, reduction of waiting time leads to limiting the waste, which causes increase in Cycle Time and this results in better process capacity – therefore higher company value and reliability.

Read our article on the easiest solution to bottlenecks in Kanban »