Mere mention of the word “bottleneck” is often enough to generate a flurry of proposals on ways to eliminate it. But every system has a bottleneck, and yours may be right where you want it.
A useful definition
Examples of bottlenecks, both at work and out in the world, abound. Work piles up on the desk of a co-worker who is out sick. Traffic comes to a standstill on the freeway while driving to and from work. (The most common one in my commute is a particular spot on Highway 101 north of Novato where three lanes turn into two.)
But some things that we think of as bottlenecks, aren’t. In a work environment, it’s common for people to label anyone or anything that is preventing them from starting their own next work task as a bottleneck.
A more useful definition of bottleneck comes from The Goal by Eliyahu M. Goldratt:
“A bottleneck is any resource whose capacity is equal to or less than the demand placed on it.”
That’s a powerful statement. And it’s the “equal to” part that I find the most interesting. If you turn the definition on its head, you can express it as:
A bottleneck is any resource with no spare capacity.
The bottleneck is a pacesetter
It’s convenient to think of a software development environment as a chain of dependent operations (e.g. requirements gathering, design, development, testing, deployment).
The bottleneck in your software development environment is the operation with no spare capacity with respect to the demand on your chain of development operations as a whole. If you measure the rate at which finished product is leaving the end of the chain, you can identify the bottleneck by finding the operation whose production rate matches the system’s rate.
In other words, the bottleneck operation sets the pace of production for the entire system. And that’s why I find it useful to refer to a true bottleneck as a pacesetter.
Deciding whether or not to eliminate a bottleneck
Your system is going to have a bottleneck somewhere, and fixing a bottleneck at one operation will have the effect of moving it to some other operation. You only want to move a bottleneck if you don’t like it where it is.
So how do you know if your bottleneck is in the right place? Just take a look at the rate of production of your development environment as a whole. If delivery of finished product (e.g. features, user stories, or whatever units of work you use) is keeping up with demand, you’ll likely want to leave the bottleneck where it is.
And how do you assess demand? In a software development environment, demand might be determined by your marketing organization (i.e. “We need to have features A, B and C delivered by the end of March”).
A bottleneck side-effect
A development environment that is keeping up with demand, and that has a well-managed bottleneck, will also exhibit what is often perceived as an undesirable trait: Not every operation in the development chain will be occupied 100% of the time. In other words, some people are going to appear as if they’re not working at least part of the time.
But this is intentional. If the bottleneck is the pacesetter for the entire system, then all of the non-bottlenecks will, by definition, have spare capacity which can be used, when appropriate, to make sure that the pacesetter operation is never starved for work.