Applying Theory of Constraints

GWW Opinion

June 30, 2025

Agile Project Management

Does your organization have a plan for what happens when there’s more work than you can handle? Or not enough work? Or when the amount of work coming down the pipe is uncertain?

We asked Agile consultant Kevin Callahan to share some tips on using the Theory of Constraints (TOC) to create organizational efficiency. He breaks down TOC concepts that help organizations change dynamics to manage uncertainty and deliver value.

Kevin has spent more than 20 years helping organizations of all sizes improve agility and flow. He discovered Scrum in 2007 and became a Scrum Master to help teams remove blockers. That hands-on work led him into organizational development and enterprise coaching, supporting companies like Liberty Mutual, WEX, and Retail Business Services, as well as smaller global teams. He’s also worked in the public sector, including with the Maine Department of Education (DOE), where he helped the DOE create flexible vendor contracts that managed uncertainty within fixed budgets—a big shift that was welcomed by both the procurement and legal departments.

Here’s an overview of our discussion with Kevin.

What is the Theory of Constraints?

The Theory of Constraints (TOC) is a problem solving framework introduced by Dr. Eliyahu Goldratt in his 1984 book The Goal that has become a cornerstone of modern management practices. Its central principle is a set of disciplined steps to focus improvement efforts on the system’s primary constraint—the factor currently limiting performance. Organizations implementing TOC can expect a range of benefits, including increased profits, improved capacity, shorter lead times, increased agility and ability to respond to change, and reduced inventory. These gains stem from optimizing the system’s weakest point, which enhances overall flow and output without unnecessary effort across non-constraining areas. By concentrating resources on this constraint, TOC provides a targeted and efficient path to rapid improvement. The constraint is often referred to as a bottleneck.

Why focus on the bottleneck?

The bottleneck is the key limiting factor—or constraint—that hinders progress toward a goal. Once identified, the TOC process involves methodically addressing and improving that constraint until it no longer restricts performance. This limiting factor is commonly known as the bottleneck. Alternatively, if the economics of the bottleneck are acceptable, it can be “pinned” at its current location, which offers a substantial degree of predictability and stability.

Every system has a bottleneck. The bottleneck sets the pace. Adding more work upstream only creates backups. Imagine a faucet dripping into three funnels. The slowest funnel limits everything. Same with teams: if the bottleneck is overloaded, the whole system slows.

How do you manage overcommitment?

One of the biggest mistakes teams make is focusing on starting work rather than completing it. A VP of Product once told me, “The most important thing I can report to my peers is that we’ve started your request.” That’s like opening all the beers in the fridge at once. Instead, leadership should focus on when work will be delivered, not when it starts. More critically, delivering work that does not create value is to be avoided. Throughput, the ToC metric of value creation—not just activity—should be the key measure of success.

Imagine a crowded ski slope with skiers arriving at the top faster than those can exit at the bottom. The constraint is the rate at which people can descend the slope; the slope has inherent capacity. As the number of skiers increases, it matters a lot less the skiers’ skill level or quality of equipment; there are simply too many of them to be able to navigate the slope!

If we control the arrival rate at the top—perhaps with a gate that only allows a new skier when one exits—we prevent congestion and ensure a steady flow. On a side note, we have now created a basic kanban system, which uses pull to manage capacity! This is the same concept applied in managing work queues. Highways in cities like San Francisco and Los Angeles use the same principle with metered on-ramps, regulating entry to prevent gridlock.

Similarly, in software development, managing work-in-process prevents commitments from overwhelming the downstream processes. Work-in-process limits help to restrict the number of active tasks in a workflow stage to prevent overload. In a perfect world, correctly managing the system’s capacity using the constraint is the only WIP limit you’ll need.

To improve efficiency, teams must also be willing to redistribute work dynamically. If QA is overloaded, other team members should assist with testing, even if they’re not as skilled. It may not be as efficient as having an expert do it, but increasing the constraint’s capacity is more valuable than keeping specialists isolated in their roles.

Can you give us an example?

I like to use the metaphor of a can of beer. While it is unopened, I have several choices of that I can do—I can put it back in my fridge, leave it on the counter, or carry it around. I can even hand it off to someone else and they have the same choices. Critically, I have options and some flexibility. The moment I open that beer, everything changes. Now it’s a commitment to drink it. I can’t “un-open” it. If I open cans of beer at a fast rate than I can drink them, problems start to become visible quickly. If instead of just cans, I add a keg in there, things get a lot worse. Most technical organizations are navigating the equivalent of banquet tables of opened beers that everyone is already too busy to consume. So they sit in various to-do lists, queues, and tracking tools.

This idea applies to decision-making. The options we consider—whether in project planning, discussions with clients, or internal team requests—can all be framed as choices versus commitments. If you’re overcommitted, you’re likely opening beers faster than you can drink them. Every system has a delivery capacity, and if you exceed it—if you make more commitments than you can fulfill—you’ll flip from a system that delivers work to a system that stores work. This is another critical point, because as the system begins storing, rather than delivering work, Throughput—the measure of creating value—decreases and inventory increases. The simplest way out is to reduce inventory levels, which can translate to some really tough conversations about real timelines.

Where does Agile come in?

Agile practice elevates early and continuous delivery of value to be the highest priority. Achieving continuous delivery requires two approaches: knowing what is valuable, or how to quickly and find out when we don’t know, and knowing how to organize processes to deliver that value with an optimal balance of lead time and capacity.

When we don’t have a clear understanding of value, we tend to make sub-optimal decisions. The biggest one is committing to too much work, which invariably creates delays and lengthens lead times, among a whole slew of other problems. In knowledge work, automation creates degrees of scale unimaginable in manufacturing. It can be difficult to appreciate and operationalize policies that reflect having capacity (that means people!) available to deliver the highest-value work is more valuable than the Operating Expense that capacity costs. The bottom line is that we cannot get away from something waiting for something else. In overloaded systems such as the examples above, the items wait artificially long in various queues to transform from Inventory to Throughput. A system operating in harmony with ToC will have various steps along the way waiting for work to arrive, such as team members in a relay race waiting for their turn to run with the baton. The race is won when the baton, not any person, crosses the finish line!

How does TOC create value?

The Theory of Constraints helps us understand that focusing on Throughput rather than utilization is how we create value. In TOC, Throughput with a capital “T” is synonymous with value; the flow metric of throughput with a lowercase “t” is a measurement of output over time and largely assumes what is created is valuable. If we start to focus on both throughput AND Throughput, we may see that completion rates are far below start rates and there’s something happening that has nothing to do with effort: a bottleneck or constraint, which is the step that takes the longest for work to move through. That might be because it takes a long time, such as manually testing even a small change that has the potential to make a large functional impact. Or it could be because there’s a highly specialized bit of knowledge in one person’s head that only he knows, so all work of a certain type must be done by him.

We use a very simple decision-making rule of thumb: use the completion rate of the bottleneck to decide when to start something new. If we can operationalize that so there’s an explicit signal, at the commitment point, we now have two of the three components of a TOC drum-buffer-rope system.

The drum is a cadence set by the constraint’s completion rate.
The rope is the pull signal to allow a new item to be started (a new can of beer to be opened).
The buffer is a special queue that sits directly in front of the constraint so that it can never starve of work.

There is no such thing as excess capacity at your constraint, and if the constraint becomes idle, you realize the cost of the entire system until it resumes.

Where do you start when consulting with an organization that has too many commitments?

I begin by asking two key questions with some followups:

Where are you committing? How do you know?
At what rate are you committing? How do you know?

What comes next?

Theory of Constraints offers two tools to work with your bottlenecks that we’ll address in another post:

Five Focusing Steps
Throughput Accounting

Five Focusing Steps follow these steps to improve processes:

Identify the constraint: The constraint is generally the longest-running step and/or the step with the most work piled up in front of it (which, even if the touch time of the step is brief makes it long-running; a “ready for” queue belongs to the step it’s waiting for, not the step it’s departed!).
Subordinate the entire process to the constraint: The constraint sets the cadence of starting work.
Exploit the constraint: This means not letting it go idle, or processing anything other than critical work (we need to be extremely careful here when our constraints are people and not machines; sustainability and respect must be primary considerations!).
Elevate the constraint: This means using targeted investments to improve the capacity at the constraint.
Prevent inertia from becoming the constraint in finding the new constraint: Don’t celebrate too much too early! Once a bottleneck is no longer the bottleneck, usually a new one exists.

Throughput Accounting is the decision-making arm of ToC. When confronted with operational decisions, TA suggests the following order:

Maximize throughput
Reduce inventory
Optimize operating expenses

These steps essentially invert the dominant paradigm of Cost Accounting and, while initially simple, demand that we thoroughly and fundamentally reexamine our perceptions and sense-making around organizational success. We also need a profoundly clear understanding of Throughput and how we create it from the executive suite all the way through the organization to each individual contributor.

Stay tuned for more on how to use these tools.