When delivery slows, teams often push everyone to work faster, creating more unfinished work, handoffs, and queues at the system’s bottleneck.

The Theory of Constraints asks: what limits the system now? In software development, it may be code review, testing, security approval, production access, or a scarce expert. Improve that constraint first to help the whole system move.

What Is the Theory of Constraints?

The Theory of Constraints (TOC) improves systems by identifying and managing performance limits. Eliyahu M. Goldratt introduced it in 1984 in The Goal, a novel about a plant manager whose shipments are always late while inventory keeps climbing. In the book, new robots make one part of the plant more efficient, but the plant’s throughput stays flat. The Phoenix Project, set in software and IT operations, explores similar flow constraints.

TOC views an organization as a connected system constrained by at least one limiting factor. Improving a nonlimiting department may boost its efficiency without improving customer outcomes.

A pipe’s narrowest section limits its flow; widening a wider section won’t help. Similarly, a delay is a constraint only when it repeatedly limits the system’s goal, not merely because it’s visible or frustrating.

Software systems change, so constraints can shift after improvements. TOC is a cycle of observation and adjustment, not a permanent label for one team.

Why Does TOC Matter in Software Development?

Software delivery is a flow of interdependent decisions and work: ideas become small changes that are implemented, reviewed, tested, approved, deployed, and observed.

When a stage processes work slower than upstream stages supply it, a queue forms. Utilization hides this: developers seem busy while customers wait for valuable work to finish.

Local optimization can hurt delivery:

  • Starting features while reviewers are overloaded grows the code inventory.
  • Unreliable test environments make parallel work harder to diagnose.
  • When release approval is the bottleneck, more completed code just adds to the queue.

TOC shifts focus from individual busyness to system throughput, lead time (start to customer), and work in progress. Measure throughput (completed work per period), queue age (time waiting), blocked time (time unable to progress), and work in progress (started work not yet delivered).

Throughput counts finished items, and it works without making every item the same size. As Dan Vacanti explains in The Kanban Pocket Guide, most unpredictability comes from time work spends waiting.

What Counts as a Constraint in Software?

A constraint is anything that limits how well the system reaches its goal. Software constraints fall into several groups.

A scarce capability

A single person may be the only one who understands a service, database, compliance rule, or deployment path, delaying every change that depends on them.

The expert isn’t working too slowly; essential knowledge is concentrated in one place. Pairing, documentation, automation, and shared ownership can reduce dependency.

A queue or approval gate

Code, architecture, security reviews, and release approvals become bottlenecks when demand exceeds capacity. Queues show work arrives faster than the next step can process it.

An approval step can reduce risk. Ask whether it protects the system at its current cost, and whether work can reach the right reviewer faster.

A technical environment

A slow test suite, unstable builds, limited staging, or manual deployments constrain the team, forcing developers to wait, rerun, or work around issues instead of delivering and learning.

A policy or decision rule

A team may have technical capacity yet face rules that constrain it: monthly releases, large deployment batches, or weekly committee approval for operational decisions.

These constraints are harder to spot because no one needs to be busy; the system waits because its rules delay useful work.

How Does TOC Improve Software Delivery?

The Theory of Constraints Institute describes five focusing steps, a repeating cycle that keeps attention on the system’s current constraint.

1. Identify the constraint

Identify where work piles up, waits, or repeatedly requires scarce attention. Use delivery evidence: queue age, blocked time, review delays, test duration, deployment frequency, and changes awaiting release.

Don’t infer the constraint from a team’s reputation or loudest complaint. Track work through the system to see where it spends time.

2. Exploit the constraint

Get more from the constraint without major investment. If review limits flow, reduce reviewer interruptions, make smaller changes, provide context, and automate manual checks.

Exploitation protects the constraint’s capacity from avoidable work, without extending anyone’s hours.

3. Subordinate other work

Align the system with the constraint: limit new work entering the queue, finish in-progress items, and don’t feed the constrained stage faster than it can process.

A developer may have capacity for another feature, but starting it can slow the system if reviews or testing are saturated.

4. Elevate the constraint

Invest in capacity if the constraint still limits the system: improve test infrastructure, automate a release step, train another reviewer, redesign approval policies, or split a service causing a queue.

Elevation costs time and money. Remove avoidable work around the constraint first; otherwise, the team may automate or staff a process slowed only by unnecessary demand.

5. Repeat the process

After improving a constraint, reassess: the bottleneck may shift to deployment, operations, product decisions, or another technical dependency.

Don’t let yesterday’s bottleneck become a permanent explanation; optimizing it may hide today’s constraint.

One constraint through the cycle

Picture a team whose pull requests wait days for two senior reviewers. Queue age shows that review, not coding, holds the work, so review is the constraint. The team exploits it with smaller changes, clear context, and automated checks. It subordinates by finishing open pull requests before starting new features. When review still limits flow, it elevates by training another reviewer. Then the queue forms at the monthly release window, and the cycle starts again.

How Does TOC Change Software Team Behavior?

TOC changes what a team treats as progress. A feature started in a development branch is inventory, not delivered value. A pull request waiting for review is inventory. A tested change waiting for a release window is inventory.

That distinction encourages teams to:

  • Reduce work in progress instead of maximizing local utilization.
  • Make work smaller so it moves through the constraint more easily.
  • Measure waiting and blocked time, not only coding time.
  • Share knowledge where a single expert constrains decisions.
  • Automate repeatable checks at the point where they reduce the most waiting.
  • Treat queues as signals about system design rather than personal failure.

This approach shifts conversations from why a team hasn’t finished to where work is stalled and what the system asks them to absorb.

How Does TOC Relate to Agile, Lean, and DevOps?

TOC complements, but isn’t synonymous with, other software development approaches.

Agile methods enable short feedback cycles and adaptation. Lean prioritizes value, flow, waste reduction, and respect. DevOps unites development and operations through shared responsibility, automation, and feedback.

TOC asks: Which constraint currently limits the system’s goal? Teams can ask this whether they use Scrum, Kanban, continuous delivery, or none.

Kanban work-in-progress limits expose constraints by preventing queues from hiding in started work. Continuous delivery reduces release bottlenecks only if testing, operations, risk controls, and product decisions can handle the increased flow.

What TOC Does Not Mean

TOC doesn’t assign blame; constraints arise from the system’s design, demand, capacity, and policies.

TOC doesn’t mean maximizing every stage’s utilization. Overloading upstream stages can overwhelm downstream constraints and increase waiting.

TOC bottlenecks can be nontechnical: product decisions, funding rules, compliance reviews, or unclear ownership can constrain software delivery as much as slow builds.

TOC doesn’t replace engineering judgment. Higher throughput that harms reliability, security, or maintainability can undermine the system’s true goal. Define that goal to include key outcomes and risks.

A Practical Mental Model

When delivery slows, trace work from request to customer outcome. Ask four questions:

  1. Where does the work wait?
  2. What limits the rate at that point?
  3. Which work can the system stop, simplify, or automate before it reaches the constraint?
  4. After an improvement, where does the queue form next?

Let reliable work flow through the system, even if some people are idle.

For the full path that work follows, read What Is Software Delivery?. For the release side of flow, read Fundamentals of CI/CD and Release Engineering.

References

  • Theory of Constraints, from the Theory of Constraints Institute, for the core concept and system constraint.
  • Five Focusing Steps, from the Theory of Constraints Institute, for the ongoing improvement cycle.
  • The Goal, by Eliyahu M. Goldratt and Jeff Cox, for the business novel that introduced TOC to a broad audience.
  • The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford, for a software and IT operations novel that explores flow constraints.
  • History of TOC, from the Theory of Constraints Institute, for when Goldratt introduced the theory.
  • The Goal Summary, from the Theory of Constraints Institute, for the plant’s late shipments and the robots that raised efficiency without raising throughput.
  • The Kanban Pocket Guide, Chapter 6, by Dan Vacanti, for why throughput counts items without requiring equal sizes.