Theory of Constraints

⏱ 4 min  ·  📅 2026

The Theory of Constraints (TOC) is a management framework developed by Eliyahu Goldratt which holds that every system has at least one constraint that limits its overall throughput, and that improving the system must focus on identifying and managing that constraint. The system's throughput is determined not by the sum of its parts, but by its weakest link.

Goldratt introduced TOC in the form of a business novel in The Goal (1984) and developed it more formally in later works. TOC has been widely adopted in manufacturing, logistics, and, more recently, agile project management.

The Five Focusing Steps improvement cycle

Goldratt proposes a five-step continuous improvement process:

1. Identify the constraint: where does work pile up? What prevents the system from producing more?
2. Exploit the constraint: get the maximum possible throughput from the constraint without making costly changes. How can we make the constraint work at its full capacity?
3. Subordinate everything else: adjust the pace of all other parts of the system so that they support the constraint rather than outpace it.
4. Elevate the constraint: if the previous steps are not enough, invest in increasing the constraint's capacity.
5. Go back to step 1: once the current constraint is resolved, a new constraint will appear elsewhere in the system. Improvement is continuous.

TOC in Agile Teams

TOC has a direct connection with kanban and lean practices:

• Kanban WIP limits are a practical implementation of step 3 (subordinate everything else): they limit the rate at which work enters the system so that it does not exceed the capacity of the bottleneck.
• Cycle time is the metric that reveals where the current constraint lies: the stage with the longest average time in stage is the bottleneck candidate.
• The retrospective is the mechanism for implementing the five-step cycle: the team reviews where the constraint lies and decides how to address it.

Common mistake

Improving parts of the system that are not the constraint. If the bottleneck is code review, investing in getting the development team to code faster does not improve the system: it only increases the pile-up before the bottleneck and gives a false sense of productivity. Goldratt called this "local optimization": every part of the system appears efficient, but the system as a whole does not improve.

References

• Goldratt, Eliyahu M.; Cox, Jeff. (1984). The Goal: A Process of Ongoing Improvement. North River Press.

See also

Bottleneck Work In Process Systems thinking Kanban: origin and definition Lean Muda, Mura, and Muri: some tips for adjusting the flow

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.

Search calls

Agile Club