You are only as agile as your biggest constraint – Introduction to the Theory of Constraints

The pace of technological advancement is rapidly increasing, and so too are the changing needs and expectations of our clients.

As technology consultants we are always looking to improve our clients’ processes by building in more efficiency and agility, enabling them to keep pace with shifting market demands and move faster than their competitors to deliver new products and services. So what better place to start than the most inefficient part of that process: the constraint.

The constraint in a process can be one of many things. A person or team whose capacity is spread too thinly, an application or tool that does not function optimally, or a less tangible thing like product quality or unclear business requirements.

One method of identifying and “breaking” the constraint in a system is the process improvement methodology the Theory of Constraints (TOC), first introduced by Israeli business management expert Dr. Eliyahu M. Goldratt in his 1984 business novel The Goal.

Productivity gains may not increase output

Before we talk more about the Theory of Constraints, let’s look at an example of process improvement without a structured approach:

Trudy is the Delivery Lead for a software development team working on a B2B app that recently soft-launched with a pilot customer. The customer is regularly raising new requirements based on their user experience.

Trudy’s team consists of:

The Product Owner, Lakshmi, works with Trudy to prioritise new customer requirements in the team’s backlog, and the backlog is regularly replenished.

The tasks performed by a developer to implement a new customer requirement are:

The developers work 7.5 hours per day on the above tasks. The Tech Lead, Stephanie, has the capacity to perform two code reviews per day. When a developer has finished a code review with Stephanie, they proceed to check-in the new code to the source repository. Each day, a new build is deployed to production containing any new code checked-in since the last deployment.

Currently, the team perform 10 new code check-ins per week:

The company’s CTO, George, tells Trudy that he’s concerned that the team is struggling to keep pace with delivering new customer requirements. He asks Trudy to find ways to increase the team’s number of code check-ins.

In the team’s next stand-up, Trudy asks the team what might be slowing them down. Two of the developers, Ying and Fatima, say that they regularly spend about an hour of their coding time clarifying the requirements provided by the Product Owner, Lakshmi.

To remedy the situation, Lakshmi implements changes to the documentation process for new customer requirements. The changes have improved handling times of coding by one hour:

The developers are able to perform coding for one additional customer requirement per week:

As you can see however, the team’s number of check-ins are unchanged.

How is it that we’ve boosted our productivity but made no difference to our output?

Enter the Theory of Constraints

The Theory of Constraints consists of the “five-focusing-steps”:

1. IDENTIFY the system's constraint
   The first step is to identify the constraint in your process, i.e. the part of your process that places the greatest limitation on your overall output. Discussions with teammates and stakeholders can be a great place to start! But what might appear on the surface to be the constraint may not be at all. So the best way to validate your assumptions is with data. Chances are you’ll already have access to applications and tools that are capturing the metrics you’ll need – use them!
   

2. Decide how to EXPLOIT the system's constraint
   ‍Once you have identified the constraint in your process, the next step is to find the quickest and most obvious ways to improve performance at the constraint. We’re not trying to reinvent the wheel at this step, this is about focusing on quick wins.
   

3. SUBORDINATE everything else to the above decision
   You’ve identified the quick wins at the constraint, now it’s time to look at your end-to-end process and find other ways to help the constraint. Is everything leading up to the constraint in the process running optimally? Do we have capacity after the constraint’s step that we can divert to earlier stages in the process?
   

4. ELEVATE the system's constraint
   ‍Now that we’ve taken steps to alleviate the constraint, what can be done to remove it altogether? This is the step where we design and implement long-term solutions intended to break the constraint entirely.
   

5. Prevent inertia from becoming the constraint
   ‍So you’ve broken the constraint using the steps above, congratulations!But uh, what happens next? That’s easy: go back to step 1, because your process will now have a new constraint!
   

You break it, you’ve fixed it - Theory of Constraints applied

Let’s revisit Trudy’s challenge using the Theory of Constraints.

1. IDENTIFY the system's constraint(s)
   Trudy reviews current work-in-progress in the team’s workflow management tool and sees that a number of new customer requirements are waiting on code reviews. She then runs a report and discovers that the lead time for code reviews has increased in the past couple of weeks, coinciding with Stephanie taking on additional work related to a separate project. The task with the highest lead-time – code review – is slowing down the entire process. The Tech Lead, Stephanie, is the only team member who performs this task. Therefore… Stephanie is the constraint!
   

2. Decide how to EXPLOIT the system's constraint(s)
   As Tech Lead, Stephanie has a number of responsibilities outside of performing code reviews. Trudy asks Stephanie to review her current workload and think of ways that she could increase her capacity to perform code reviews. Stephanie identifies some recurring tasks related to another project that can temporarily be put on hold. This action results in Stephanie being able to perform three additional code reviews per week.
   

3. SUBORDINATE everything else to the above decision
   Trudy has observed that Anders is the most senior developer in the team. She asks Stephanie if Anders could assist with performing code reviews. Stephanie agrees that he has the necessary experience, so it is decided that Anders will perform two code reviews per week with the other developers, Ying and Fatima.
   
   Trudy also asks Stephanie whether she can assist with any of her current responsibilities. Stephanie reviews her calendar and identifies a weekly planning meeting that Trudy could just as easily attend in her place. This frees up Stephanie to perform two additional code reviews per week.
   

4. ELEVATE the system's constraint(s)
   Trudy observes over the next week that the changes she implemented in steps 2 and 3 have resulted in a total of 17 check-ins, a significant increase from the 10 they would otherwise have expected:
   

   

   This result occurs without even decreasing the average handling time of the coding step!
   
   Trudy captures this data and provides a report to the CTO, George, along with a list of recommendations to permanently remove the constraint:
   

   • Permanently reassign some of Stephanie’s responsibilities to other teams / roles
     

   • Allow Anders to continue performing code reviews (and perhaps be put on track for a senior developer role)
     

   • Enlist senior developers / tech leads from other teams to perform code reviews
     

5. Prevent inertia from becoming the constraint
   ‍As Trudy patiently awaits George’s response, she imagines where she may find the next constraint in the process!
   

Subordinate everything else to the Theory of Constraints?

Some of the more evangelical practitioners of the Theory of Constraints argue that any process improvement not focused on breaking the constraint is a waste of time. I respectfully disagree.

Take our first example. Trudy implementing changes to improve her team’s requirement gathering capability would still have positive impacts:

• The developers spend less time seeking clarity and spend more time doing what they love (coding!). This gain in productivity could also be invested elsewhere in the process (e.g. improving the team’s testing capabilities to improve product quality)
  

• If the Product Owner, Lakshmi, removes ambiguity from new customer requirements, this may also lead to an increase in product quality overtime, thereby preventing a future constraint on new feature delivery (because we’re too busy working on defects!)
  

We should always be mindful of how any decision we make to break the constraint may impact our clients in the future, lest we create a new constraint! And at the same time, consider the long-term effects of passing up a process improvement opportunity because it doesn’t break our immediate constraint.

Final words

It is more important than ever that businesses and organisations find new ways to deliver products and services faster and with more certainty. The Theory of Constraints is a highly effective means of identifying process improvement efforts that deliver maximum output for your clients, enabling them to meet those demands.

It should not be viewed as a methodology unto itself, but as a powerful tool to deploy alongside your existing knowledge. Time to get focused and break some constraints!

Bonus feature

A fun demonstration of the Theory of Constraints using three identical bottles of water flowing at different rates, produced by TOC expert Arrie van Niekerk:

Further reading

Dr. Eliyahu M. Goldratt - The Goal (1984)
The business novel which introduced the Theory of Constraints. The manager of a failing manufacturing plant is given three months to return the operation to profitability, and he attempts to do so, with the help of an academic, by identifying constraints in their production line. The Phoenix Project is widely considered a spiritual successor to The Goal.

Dr. Eliyahu M. Goldratt - Necessary But Not Sufficient (2000)
A follow-up business novel which explores the Theory of Constraints through the lense of an Enterprise Resource Planning (ERP) software company. It is also a departure from The Goal in that itcentres on a successful technology company at the point of peak market saturation, and elaborates how a system can benefit from excess capacity at points outside of the constraint.