Introduction to the Theory of Constraints


I’m obviously a big fan of the Agile methods and Lean/Kanban, as evidenced by how the teams on which I work, consult, or participate use aspects of each for their chosen processes. One of the underlying philosophies of both Agile and Lean/Kanban is the Theory of Constraints (ToC). The Theory of Constraints was developed by Eliyahu Goldratt in the early 1980s to describe how workflows can be understood and improved by focusing on the bottlenecks that constrain the flow of value through the system being measured.

Goldratt explained his reasoning in three novels, The Goal, Critical Chain, and It’s Not Luck. In each of these, different aspects of the ToC are described through mildly entertaining characters and story lines. The first book, The Goal, describes the ToC itself and the Process of Ongoing Improvements (POOGI). Critical Chain talks about Critical Chain Management, a style of thinking that takes the concept of a critical path for a project and expands it to support multiple projects. And finally, It’s Not Luck introduces Goldratt’s Thinking Processes, which are orderly patterns of thinking that help you understand the current situation, define the intended future state, and chart a path from to that future. All great reads, highly recommended.

The Theory of Constraints

His most important point, however, is the ToC and advice about how to apply it. In a nutshell, the ToC boils down to understanding how value flows through your production system, learning where the bottlenecks are, and iterating over improving the efficiency and effectiveness of processing at the bottlenecks. He gives the outline of a process to follow in this improvement, called the 5 Focusing Steps:

  1. Identify the constraint in your system,
  2. Exploit the constraint by making sure that this particular part of your workflow is busy and productive all the time,
  3. Subordinate everything to the constraint by reducing production eveywhere else in your system to avoid having work pile up, waiting to be processed,
  4. Elevate the constraint by improving its ability to process the value by adding capacity, changing the nature of the work, hiring, and so on,
  5. Return to the first step to find the new constraint in the system.

This process never stops, as there is always exactly one bottleneck in a system, and you can always discuss ways to eliminate it.

In The Goal, Goldratt writes a pretty approachable example of the Theory of Constraints in practice when he describes a Boy Scout march the protagonist, Alex, leads with his son. His job is to take the whole troop on a trip through the woods to a camping site before nightfall. The boys start marching through the woods, and for various reasons they aren’t making the kind of progress that he hoped for. One boy in particular, Herbie, is moving a lot more slowly than the rest, and he is both slowing down everyone behind him and allowing everyone in front of him to spread out so far that they can’t keep track of each other.

Through some careful thinking, Alex understands that Herbie is the limiting factor, or constraint, in how fast the team can march. So he exploits how fast Herbie can march by putting him at the front of the line of boys, so that he can always keep moving, and and subordinates the progress of every other boy by telling each to keep a 10 foot margin behind the boy in front. Now everyone is marching at the same rate, and the length of the column is fixed for the most part. Since the speed is now constrained by how fast Herbie can march, he elevates that speed by offloading the junk in Herbie’s pack to the other boys, which lets Herbie and the whole troop march faster. They arrive at their destination, all are happy, and Alex learns a valuable lesson he can take back to work the next day.

It’s a better story in the book, but you get the idea. The ToC is actually a pretty simple theory, but it has amazing applicability to so many situations. Read the books and judge for yourself.

Why Should You Care?

The whole reason why I’m writing about this is that I believe the Theory of Constraints can be used to explain and justify the processes and practices that are part of the individual Agile methods. In future blog posts, I want to take a typical team and talk about how you can optimize the progress made by that team through applying the ToC to the constraints of that team.

I plan on writing posts about the importance of good and important stories, the criticality of acceptance tests to avoiding unnecessary work, and then discuss the Extreme Programming engineering practices of Pair Programming, Refactoring, Test Driven Development, and Continuous Integration/Deployment.

Thanks for reading this far, and I’m looking forward to writing the rest of this series over time.


Additional Reading