Thinking on Theory of Constraints

About a decade ago, a book called The Phoenix Project swept through the IT community. It is an incredibly relatable bit of fiction about a software shop that ultimately redeems itself.

Most people who read the book came away with the idea that DevOps would save them, but most missed that it was an adaptation of a different book called The Goal. That book was about the Theory of Constraints.

I want to talk about the Theory of Constraints and its application in technical groups.

Identify the Process Steps

The Theory of Constraints lets us significantly improve the flow of things, but we can’t do that unless we can see all the steps work takes.

Think about a software development group for a moment. The developers have a board that says To-do, Doing, Done. They don’t have things like design, testing, code review, deployment, etc., yet many groups do all those steps.

Consider the support processes and business processes too. Those are typically invisible or managed by someone else. An excellent example of this is a separate QA group.

So, as complicated as it is, map out each step in the process. Try not to bundle the steps together in the beginning. There will be dozens, if not over a hundred steps.

Track the Timing

Now we get to uncover the real issues going on. Each step in the process takes time, and the Theory of Constraints wants us to focus on where things get stuck. So we need to see the parts of the process where work slows down and bottlenecks.

One way to do this is by tracking the timing of each of the process steps.

There are two notes here, though. First, you need to collect actual timings and not what people think it takes. Second, you need to sample each step a few times. You’ll notice that there is often vast amounts of variability everywhere. It is not uncommon to find that coding takes between two hours and 20 days.

That variability makes this work very difficult, so you might as well see the challenge ahead.

Track Wait Time

We aren’t done with timing yet. Work doesn’t flow immediately from one step to another. It usually waits for some amount of time.

We need to track that wait time just like we did the processing time.

The wait time is often where we find the most improvement opportunity and signs of the bottlenecks.

Tracking this requires noticing when one step finishes and when the next step starts. What is challenging about this, though, is that there could be weeks or months between steps.

Find the Bottleneck

With the process steps and wait times mapped, look at what you’ve created.

I guarantee there will be things that will make your jaw drop.

Also, take a minute to compare what you’re seeing to what people claim about the bottlenecks. They rarely match.

Armed with this information, I’ll suggest you do one final step. Try to calculate the cost for the process and timings. I find that putting this data to cash helps make the point when you want to change how a process works.

Saving $105,000 a Month

The first time I did this was at a small company that wanted to cut costs very badly. I went through these steps and tracked our entire development and release process with the timings.

I also calculated a rough cost of the current process, which amounted to $120,000 per release per month.

While everyone else was looking at how to save on turning off old AWS instances, I went to work on the process.

After two weeks of automation efforts, I cut that $120,000 down to $15,000.

Where I saved $105,000 per release per month, my co-workers celebrated their few-hundred to few-thousand a year in savings from turning off old AWS services.

Final Thoughts

The Theory of Constraints is a powerful concept, but I find that many people don’t understand it very well, and fewer want to put the work into getting the benefits of its application.

If you are interested in it, do the detailed work, and become an expert. There are incredible benefits ahead.

One word of warning, though, variability messes all of this up, so you have also to find ways of reducing variability for the benefits to materialize. That’s a topic for a different article, though.