Bottlenecks are figments of imagination

As I mentioned in a previous post, one of the productivity killers on any team is a dependent event that slows the entire process.  The common and somewhat inverted way to look at this situation in the software world is to claim a bottleneck exists.  I use inverted because a bottleneck is often interpreted to mean that a fixed throughput exists, while a dependent event doesn’t attempt to imply any sort of throughput.  A dependent event is just some action that must occur before another.  How a dependent event is interpreted and handled is left wide open as a problem for the team to solve.

So, enough of the theory junk, a real world example will help.  Let’s consider a large software engineering team composed of many smaller Agile teams.  When one Agile team (Team A) is bogged down with a part of the software that other teams require, the other Agile teams end up waiting.  Is Team A considered a bottleneck?  The answer depends on the flexibility of the organization.  If Team A is only allowed to work on a certain part of the functionality, a bottleneck exists, but if there are no restrictions on teams relative to any specific functionality, a dependent event exists where the other teams are able to come to the rescue.  While it may sound obvious, this setup requires teams that have the capability to work on all parts of the functionality, which may necessitate significant organizational and cross-training changes.

A second example is the case where apparent resource constraints within a team force delays within the team itself.  Let’s take an example where the designated technical writer for a team unable to keep up with documenting the new functionality because of other commitments.  A bottleneck exists if the team continues to create new product without the writer or just stops and waits for the writer.  On the other hand, a dependent event problem exists if the team considers that getting the documentation ready is the real requirement and does not get bogged down with the thought that there is only one resource-constrained writer.  In this case, the team may designate others to help create or research content, or the team may choose a different method for documentation such that everyone can participate.

In both cases, claiming a bottleneck exists is just one interpretation of the problem.  Just thinking bottlenecks exist should be a mental trigger to reconsider looking at any apparent resource constraint.  Creating teams where bottlenecks can be turned into dependent event problems can require major shifts in process, and it may take time to build a cross-functional team, so starting yesterday is the key.