Library→First Way: Flow→Concepts→Theory of Constraints
Theory of Constraints
Every system has one bottleneck that limits its throughput. Goldratt's TOC applied to software delivery — and why local optimization never improves the whole.
Video Lesson
A video lesson for this topic is in development. The library articles and mission exercises cover the same material in the meantime.
The core insight
In 1984, Eliyahu Goldratt published The Goal, a novel about a factory manager trying to save his plant. His central insight: every system — factory, hospital, software team — has exactly one constraint that limits its output. Improving anything other than the constraint does not improve the system's output. It only creates more inventory piled up in front of the bottleneck.
Gene Kim, Kevin Behr, and George Spafford adapted this for IT in The Phoenix Project (2013). The factory manager's insights map almost exactly to software delivery pipelines.
System throughput = 2/day (constrained by Review)
Making Dev faster (20/day) does not help. Review still processes 2/day. Work piles up before Review.
The throughput of any system is determined entirely by its constraint. A chain is only as strong as its weakest link. In software delivery, the constraint is almost always not coding — it is review, testing, or deployment.
The five focusing steps
Goldratt's method for continuously improving a constrained system is called the Five Focusing Steps. Unlike a one-time fix, it is a continuous loop.
Identify
Find the constraint. What single step determines the maximum throughput of the entire system? In most software teams it is code review, QA, or deployment approvals.
Exploit
Get the most out of the constraint without spending money or adding resources. If code review is the bottleneck, reviewers should never be idle. Review is the first priority, not a background task.
Subordinate
Align everything else to the constraint. Do not let other stages run faster than the bottleneck can absorb. Excess WIP upstream of the bottleneck is pure waste.
Elevate
If exploiting the constraint is not enough, invest in it. Add more reviewers, automate checks, reduce review scope, pair on reviews.
Repeat
Once the constraint is resolved, it will move. A new constraint will appear. Return to step 1. Continuous improvement is the goal, not a fixed endpoint.
Where is the constraint in software teams?
The constraint moves as teams improve. Common constraints at different maturity levels:
TOC at Nexus Corp
When you ran the Value Stream Mapping exercise in M-01, you identified Nexus Corp's constraint: 12 days of wait for the monthly production deployment window. Every other improvement was blocked by this single constraint.
In M-04, you eliminated it by connecting the pipeline to a continuous deployment platform. The constraint moved. The next constraint will be visible in the updated VSM.
Improving code review speed, test coverage, and environment provisioning all mattered — but none of them improved lead time until the deployment constraint was resolved first.
Further reading
The Goal — Eliyahu Goldratt
The original novel that introduced TOC. Alex Rogo saves his factory. A surprisingly fast read that changes how you see systems.
The Phoenix Project
IT fiction adapting The Goal. Bill Palmer identifies Brent as the constraint and learns to protect and then eliminate him.
DevOps Handbook
Chapter 3: Where to Start. How to identify and exploit constraints in the technology value stream.
Beyond the Goal — Goldratt
Audio lectures expanding on TOC applications beyond manufacturing, including knowledge work.