In some of the early Theory of Constraints literature Eli Goldratt would talk about three types of bottleneck - capacity constrained resources (CCRs), policies and market constraints. In recent, years he changed his mind and simplified the model. Policies are no longer constraints, they are merely exploitation or subordination techniques - elements 2 and 3 of his Five Focusing Steps.

Later in a lecture I remember watching Eli tell a story of how he'd scolded a client (or maybe it was a consultant) for confusing a non-instant availability resource with a capacity constrained resource. He argued that non-instant availability resources are not constraints because they are not capacity constrained. The non-instant availability is the side-effect of a policy that controls the process. However, I believe that we can still call these bottlenecks.

Hence, I now teach that there are two types of bottleneck: capacity constrained resources CCRs; and non-instant availability resources [we need a good acronym (TLA) for these ;-) ???]

Only CCRs should be treated with the Five Focusing Steps: identify the constraint; decide how to exploit the constraint; subordinate all else in the system to the decision in 2; elevate the constraint (i.e. add capacity); do not inertia prevent you repeating by identifying the next constraint and starting again at 2.

Non-instant availability resources exhibit bottleneck behavior but we don't try to exploit them as first step to improving the throughput. The reason there is a lack of throughput is lack of availability. We must identify the policies, transaction costs, coordination costs or other physical constraints that cause the non-instant availability.

For example, an ambulance is a non-instant availability resource because it must be dispatched from a central base like a hospital and it must travel to the location. We can improve availability (response time) by locating ambulances closer to where they might be needed. To illustrate this, imagine a seaside town that is a popular retirement destination such as Largs in Scotland (a town where I lived 20 years ago.) Largs with a population of 11,000 is too small to support a hospital let alone an accident and emergency (ER) department. The closest one was around 20 miles distant. To improve response time for ambulances, the ambulance service stationed vehicles in Largs even though there was no depot or hospital. This is an example of improving availability on a resource that impedes flow of value in the system.

The dispatching of the ambulance and its travel time must be seen (economically) as a transaction cost on the delivery of value. In Lean terms all transaction costs are waste. So non-instant availability is waste. Hence, improving availability is a way to reduce waste. It also improves flow and alleviates a bottleneck.

So how can we describe this generically in order to abstract a set or rules or principles for dealing with non-instant availability bottlenecks in process flow?

Figure 1. Doug Burris, build engineer and a kanban board showing the "Build Ready" state

At Corbis, we discovered that our build engineers such as Doug Burris pictured in Figure 1 were a non-instant availability resource.

We had in place a policy which stated that only build engineers could build code and push it from our development code-line in to our test environment. This policy existed in order to maintain the integrity of our test environment. Developers, through prior bad behavior, were not trusted to keep the test environment in working order and the negative effect that this had on the team was sufficient that the policy that only build engineers can touch the test environment had been introduced.

Further, we had a policy that our build engineers were generalists within their own field of configuration management. They each had to work three different types of problem: build code for test; maintain pre-production environments, applying software patches and configurations; and build out new environments. Each of these types of work required different amounts of time and effort: builds approximately 15 minutes to 2 hours; maintenance up to 2 days; and environment builds up to 2 months. In order to cope with the different time scales across the three different types of work, the team members multi-tasked by (effectively) time-slicing their effort across the three types. Hence, build was a non-instant availability resource, as the build could only be undertaken when the build engineer was in "build" mode and not in "maintenance" mode or "environment build" mode.

What is important about all of this is to understand that all of this is controlled by policies, and that management has it within its power to change those policies.

So for example, do we want to have instant availability build engineering? do we really need the policy that developers are considered untrustworthy and are not permitted to build code on their own?

In the end, we settled for a multi-faceted approach to attack this problem: invest in automation - a long term strategy; increase the time slice for build from some of the engineers; relax the no developer can build policy under some circumstances.

I'm still distilling out the abstract set of rules for improving throughput through non-instant availability bottlenecks. I'll publish more as develop it.

For now, it is enough to question: is this bottleneck truly a CCR? or is it a non-instant availability problem? If it is a CCR apply the Five Focusing Steps. If its a non-instant availability problem, examine the policies, transaction costs, coordination costs or physical obstacles that cause it to be non-instant availability and consider what you can change to improve availability. Technorati tag: David+Anderson, Software+Engineering, Kanban, Lean