So here’s a question. Let’s say you are working in an assembly line of some sort, what is your primary goal? 

a. To be as efficient as possible when items are passed to you so that you can pass them along as quickly as possible.

b. To help the entire line maximize its output. 

c. All of the above.

Believe it or not, the first two objectives are mutually exclusive. Knowing this, the answer of course is ‘b’, since logic dictates that without ‘b’, ‘a’ does not matter. As humans we like to think that doing our job to the best of our abilities will elevate the overall system we are apart of. Unfortunately history has proven this logic flawed. I stumbled across an apropos article on the principle of suboptimization a few months ago, and it’s amazing the number of situations it applies to. It states: 

“Optimizing each subsystem independently will not in general lead to a system optimum, or more strongly, improvement of a particular subsystem may actually worsen the overall system.” – Machol, 1965, pp. L-8

This principle shows that we have to look at the system as a whole to optimize its performance. This is where Systems Theory plays a roll. It encourages us to study the interworking parts of systems to better understand how the system achieves synergy or value greater than the sum of its parts. Based on this body of work, and the trends that have been observed over the last century and a half, it has become clear that optimizing the output of the whole system does not equate to optimizing the output of all subsystems. This concept can seem counterintuitive though and for many who have not seen this in action, it can be hard to except. This truth is the basis of the Theory of Constraints (TOC).

So what is the Theory of Constraints you ask? It is a theory of how to diagnose and then optimize a system to achieve maximum output, then once maximum output is achieved it proposes a plan on how to expand the system while maintaining maximum efficiency.

The Theory of Constraints was first proposed in the 1984 book The Goal, Written by Eliyahu M. Goldratt. Several subsequent books have been written on the topic to expand on the theory and show how it works in a business whose main output is the completion of projects vs traditional assembly line processes. Such is the case in a software development shop of government agency. It follows many of the concepts you see in Lean but its main focus is on optimizing the output of the system where Lean’s main focus is on reduction of waist. 

There are plenty of nuances on how to fully implement the Theory of Constraints but the main value can be gleaned from understanding its five steps to system optimization. These are

  • Identify the system’s constraint(s).
  • Decide how to exploit the system’s constraint(s).
  • Subordinate everything else to the above decision(s).
  • Alleviate the system’s constraint(s).
  • Repeat the Process

Identify the system’s constraint.

In every process there is a bottleneck. This is the step that sets the speed of the entire system. This plays into what we discussed above around the importance of optimizing the whole system, not just one part. You see, if you optimize something that is not the bottleneck it does nothing but create a large queue of work for the bottleneck to process through. It does not increase the output of the system because it did not speed up the bottleneck. In fact, larger queues can often slow down the bottleneck for various reasons, ranging from demotivating workers, to creating pressure to maximize the bottleneck capacity resulting in parallel jobs that choke the work center. In other words, optimizing anything other than the bottleneck is a waste of time and is likely doing actual harm to the overall output capacity of the system. 

This is why the first step in the Theory of Constraints is to, ‘Identify the systems constraint’, also referred to as the bottleneck. It is possible for there to be multiple constraints simultaneously in a system but there is generally one primary constraint that should be addressed first.

Decide how to exploit the system’s constraint.

It is important to recognize that this says “exploit” not “alleviate”, which comes later. After you have identified the constraint, focus improvement efforts on maximizing efficiency in this one area. Make sure the constraint’s usage is being maximized before throwing additional machinery or people at it. This can be done through reducing downtime, off loading some of the constraints tasks to an earlier work center, or engineering better sub processes to speed up the constraint. In manufacturing, this could take the form of building out a manageable buffer of work to insure the constraint is never waiting, or it could take the form of rearranging the work center to optimize the movement of people and tools. In software development this could be done by including a technical resource in the requirements phase to make sure developers don’t have as much downtime as they translate business objectives into technical options, or it could be done by creating better deployment processes and automating testing to move software to production faster.

Subordinate everything else to the above decision.

Once a constraint has been identified and optimized it is important to make sure all other steps in the system do not exceed the constraints capacity. All other steps are capable of exceeding its capacity by definition which is why they are not the constraint. By allowing other steps to self optimize you break the concept of flow. This creates large work in process (WIP) queues, and long lead times, resulting in extraneous effort spent on managing flow that would be better spent on optimizing and elevating the constraint.

This is the step that some find hard to swallow. Traditional command and control style management taught us to maximize the effort of every resource. Idle hands or equipment were thought of as costing money. It seems counterintuitive, but by maximizing the utilization of non constraint work centers, you are actually slowing down the output of the overall system. Instead of maximizing a work centers capacity, focus them on staying in sync with the constraint while trying to see if they can play a part in exploiting the constraint through additional preparation of the item for faster processing through the constraint. 

Alleviate the system’s constraint.

Once we know what the constraint is, we have maximized the constraint, and we have made sure that all items are keeping in sync with the constraint; now we are ready to remove the constraint by adding additional machinery, or manpower. This must be done slowly so that you can continue maximizing the constraints capacity as you add additional resources. As you methodically alleviate the constraint you must keep an eye on the rest of the system as they increase their capacity. At some point another workstation will no longer be able to keep up with the capacity demands of the elevated constraint and thus becomes the new constraint of the system. When this happens, you must stop alleviating the old constraint and refocus your efforts on the new constraint.

Repeat the Process

Once a new constraint is identified, you should start over again and repeat the process.

It is worth noting that some scenarios require the maintenance of a constraint rather than the alleviation of the constraint. This happens in a scenario where there is significant variability in demand. In these cases the constraint can be used as a lever to increase or decrease the output of the system on demand. There is a limit to this of course and that is at the point when the constraint shifts to another place in the process. For situations like this, it is important to make sure the entire system can increase to the maximum desired output level without the constraint shifting. This allows a company to increase or decrease output by simply increasing the constraints speed.

To pull this off, The Theory of Constraints suggests the Drum-Buffer-Rope concept:

Drum Buffer Rope

To manage variability and to set cadence in a process, a signaling method is used to release work or materials into the system each time a job is completed by the constraint. This signaling method is referred to as the Rope. When a job is completed by the constraint a proverbial rope is pulled to let the controller at the beginning of the system know that they should let another batch of work or raw materials into the system. The Drum is the proverbial rhythm setter that keeps all steps between the controller and the constraint in sync so that work does not build up. The idea being that every time the rope is pulled, the drum is beaten, and all batches move to the next workstation in sync. Reality is never quite this perfect you might say, but as long as every station is faster than the constraint, the work at every station should be completed before the next beat of the drum allowing all batches to stay in sync as they move down the line. The Buffer is how you insure that the constraint never stays idle. Even though the non constraint work stations are faster than the constraint normally, the loss of an employee, the breaking down of a machine, or the flow in a batch can cause issues in perfect flow. As long as there is a small queue of work waiting on the constraint at all times, these small disruptions can be handled without decreasing the output of the system. This small queue in front of the constraint is referred to as the  Buffer.

Theory of Constraints in Software Development

The theory of constraints was conceived originally for process driven organizations like manufacturing plants. It was later adapted for project driven organizations like software development companies. Regardless of its implementation, its principles are proven. A company should stop focusing on improving everything, and instead focus all effort on the systematic process of improving the one thing that is setting the speed of output for the whole system. This is extremely apropos in a software shop using the Waterfall Project Management methodology. In that scenario each step in the process can be seen as a work center and the goal is to identify which step is slowing the rest of them down and then focus on efficiency gains in that step. Historically the actual development step has been the bottleneck in these cases which is one reason why so much of the definition of the project is specked out before the developers get involved. The goal is to off load as much work to other work centers as possible to make the constraint as efficient as possible. Other solutions include better tooling, reusable API’s, and third party libraries.

In more recent years, Agile has replaced the Waterfall method and instead of steps in a process, a team is encouraged to self optimize. Even in Agile, the Theory of constraints should be understood because of its implications on the team’s efforts and on the company as a larger system. If the team understands TOC it can focus its efforts on iteratively improving the most important parts of how it functions each sprint or iteration. Agile companies often have their teams operate as a step within a larger sequential value stream of sales, development, marketing, etc. This larger value stream can also be improved significantly by using the Theory of Constraints.