2 Ways to Reduce Bottlenecks with the Theory of Constraints
A chain is only as strong as its weakest link. That’s the idea behind the Theory of Constraints. Just a few weak links will limit any system, but you can improve the whole system’s performance by focusing on improving those links.
Whether your system is a software delivery process, a large production line or your household chores, the only way to improve the whole system is to work at the bottlenecks.
Theory Is Great, in Theory
There are two ways to learn about the Theory of Constraints. You can read Eliyahu Goldratt’s business novel, The Goal, or read the accompanying handbook, Theory of Constraints.
Either option explains the set of focusing steps you use to apply the theory.
- Identify the system’s constraint.
- Decide how to exploit the constraint.
- Subordinate everything else to this decision.
- Elevate the constraint.
- If the constraint resolves, go back to step one.
The theory is wide-reaching. It can be applied to any system. For example, a production line in a factory, managing software delivery or a group of Scouts trying to hike to their destination with their equipment. Because of this, the language is likely to be a little abstract for your real-world situation.
Specifically, the terms exploit, subordinate and elevate might be unclear.
Let’s simplify the language a little, then look at two practical ways to apply the Theory of Constraints to your work.
Exploit, Subordinate and Elevate
A “constraint” in the Theory of Constraints is essentially a bottleneck. You are trying to flow work to completion to get some value, and many steps are involved, possibly many people. If you look closely at this flow of work, you’ll find there is one stage where things get stuck.
You might be making computers and have a pile of almost finished products stacked, waiting for someone to install a graphics card. Well, the graphics card stage is your bottleneck or constraint.
You can spot this problem thanks to the pile of computers sitting in front of the graphics card workstation, but you’ll also notice workstations after the bottleneck are starved of work while those ahead of it are producing more laptops that only add to the size of the queue.
If your work is less physically visible, having a visual system like a Kanban board can show you the problem. Seeing work items stuck in a queue in front of a specific task shows you ther’s a bottleneck.
When you can see this bottleneck, you’re ready to apply the three mystical terms.
You can exploit the constraint by improving it with existing people and resources. If you can transfer someone to work at the constraint, your overall production (finished laptops, software features or clean clothes) will increase.
You then subordinate everything else to the pace of your constraint. That means setting the speed of the upstream process to match the speed of the bottleneck. If you can fit 10 graphics cards into laptops in a day, you can assemble only 10 laptops a day. Everything from start to finish runs at the pace of the stage with the bottleneck.
Once the system is running at a matched speed, you look at ways to elevate the constraint. That means finding ways to increase the throughput from 10 graphics cards daily to something more than 10. Assuming you’re not using existing people and resources to elevate the constraint, you’ll need to look at the costs and benefits of increasing throughput. If you doubled the size of the team or introduced tools to support the process to increase throughput to 20 graphics cards a day, how much would you invest to get those extra sales?
You continue to apply this three-stage process until the constraint moves. For example, you are producing 20 graphics a day while selling only 18 laptops a day. Now you apply the focusing steps to the sales stage instead.
This theory can be applied to physical or knowledge work. Work is like water flowing down a canal with many locks. You can’t allow the water from higher stretches to flood the lower ones or allow a section of the canal to run dry.
Let’s look at two practical ways to apply these focusing steps in real life.
Start on the Right
In software development, work is usually visualized on a task board that follows work as it flows from left to right. The columns on the board represent queues and work stages, such as “waiting for testing” and “in test.”
To apply the Theory of Constraints, first ensure the task board accurately represents every hand-off and queue in your process. Once you have represented the real flow of work, the board will quickly show you where bottlenecks are.
You can apply the focusing steps to the bottleneck, but there’s a simpler option for cross-functional teams. Always work on the right-most work item before anything else. If a feature is ready to deploy to production, deploy that before testing the feature to the left.
By always progressing the work closest to completion, you get the exploit and subordinate focusing steps with no effort. Your cross-functional team is self-leveling, even for dynamic bottlenecks. The speed of the system is automatic, and the team will apply their time flexibly to the tasks that require their attention.
When using this approach, you just need to keep inertia out of your improvement process. You won’t have a stack of work telling you what needs to be improved, so you’ll need to pay attention to which tasks must be improved — or elevated, in Theory of Constraints terminology.
Sometimes, the simplicity of this approach is what makes it so powerful.
Schedule to the Bottleneck
If you don’t have a cross-functional team, you can schedule to the bottleneck. For example, if you have a separate testing team, you should produce features only at the speed they can be tested without increasing the queue size.
This is where adding work in process (WIP) limits to your task board can help. The most important WIP limit is the one for the queue in front of the bottleneck, but you may need to add limits to other columns to the left of the constraint. You don’t need limits after the bottleneck; if you find yourself adding WIP limits on the right, it means your constraint has moved.
When you schedule to the bottleneck, ideally you want to provide work to the constraint just as they need the next task. However, most teams use a buffer to make sure the bottleneck is never idle.
Scheduling to the bottleneck takes more effort than starting on the right. However, its one advantage is highlighting the constraint very clearly. Nobody on the team has any doubts where improvement efforts should be focused.
The Powerful “Aha” Moment
The reason the Theory of Constraints has such an impact is that it highlights how all the work you do above what your bottleneck can handle is wasted. In the laptop example, no amount of assembled laptops you produce makes a difference to how many you sell if you can’t complete them with a graphics card.
The answer can be as simple as moving someone from assembly to graphics installation, or you may need better tools to support this stage in the process. The Theory of Constraints sets you on the right path and provides concrete motivation for improving the right thing.