In the context of software development delivery, a bottleneck refers to work demand queuing within a functional area, i.e. a bottleneck in Test. Common examples of bottlenecks within software development are, developed work waiting for testing, analysed stories waiting for development, tested work waiting for deployment. This queued work vastly impedes predictability making forecasts of completion dates highly inaccurate.

The focus on reducing and removing bottlenecks originated from the Kanban method. The realisation that the bigger the bottleneck, the slower value will be released due to the increase in overall work in progress. Little’s Law provides further detail on the impacts of having too much work in progress.

Teams have developed several strategies for exploiting the bottleneck. The first one is to subordinate all activity within the process steps to the slowest point. Subordinating the activity to the slowest point materialises in the form of work in progress limits (WIP limits). These WIP limits encourage the act of team swarming. Team swarming means a multidisciplinary group of people all work at the point of the bottleneck to reduce the WIP. The net effect of this is to increase flow.

Another mechanism used within software development is to introduce queues to create a pull system. Creating a pull system is critical to reducing the possibility of bottlenecks. The queues come in the form of ‘Done’ columns for each phase of delivery. A common Kanban system may have columns consisting of Analysis WIP, Analysis Done, Dev WIP, Dev Done, Test WIP, Test Done. The aim here is to prevent specialisms from chucking work over the wall and overwhelming the next specialist in the process. Instead a specialist can only put completed work into their own ‘Done’ pile. The next specialist in the chain can now pull from this ‘Done’ column, but only when the have the capacity to deal with it.

I would like to speak with an advisor