It’s always interesting to see how people interpret disciplines - we all bring our own perspectives to the topic. I know I get things wrong, but it’s not a reason to stop exploring. It’s an opportunity to learn, both to get deeper understanding of my own ways of thinking as well as understanding those of others. One of those areas where I think I have some expertise is Theory of Constraints (TOC), so when topics arise of people discussing how TOC applies or relates in their arena of knowledge, I like to investigate.
A recent examples is Do DevOps and the Theory of Constraints still relate by Will Kelly. The popular origins of DevOps came with The Phoenix Project (my review from 2013), a book that was heavily influenced by Goldratt’s The Goal, the starting point of TOC. Kelly focuses on the TOC five focusing steps and talks about how DevOps relates.
The Five Focusing Steps are
Identify the system’s constraint.
Decide how to exploit the system’s constraint.
Subordinate everything else to the above decision.
Elevate the system’s constraint.
If in any of the above the constraint has been removed, go back to Step 1. Do not let inertia become the constraint.
What does constraint mean in this context? It is the limiting factor - the thing that prevents you from getting more of the desired goal out of the system. (Often the goal here is money - what is the thing that limits us from getting more money from this system.) In this context, there is always a constraint in the system, otherwise we’d be able to get infinite amounts of our goal. These steps are a loop for system improvement.
Back to the article about DevOps and TOC, Will Kelly emphasizes “identify the constraint” and talks about some of the more challenging barriers to adoption of DevOps, like company politics and change management. But then he talks about “fixing the constraint”, rather than the TOC perspective of deciding how to exploit the constraint. This is not unusual. Many people see the constraint as something to remove or fix. It’s something bad. (The original language in The Goal used the term “bottleneck” which had even more connotations around “bottleneck busting.”) Notice step 5, however. In some cases, there is a current constraint in the system that really should not be the controlling constraint and can be easily removed. In that case, there is a new constraint, go back to step 1. Where is the constraint now? Is it in a place that makes sense for the whole system - is the constraint where we want it to be? As Will Kelly notes, iteration is key in going through this loop of the Five Focusing Steps.
Then go to step 2. Once we know where the system’s constraint is, how do we take advantage of that? How do we want to make the best use of that constraint to get more and more value out of the entire system. Usually this implies changing policies and practices, rather than spending a lot of money (which is typically step 4 - Elevate). Sometimes these steps can cause the constraint to shift. Go back to Step 1 again.
What about step 3, subordinating everything else to the decisions about how to exploit the constraint? Will Kelly seems to think this no longer applies in a DevOps environment - and it seems he’s shifted from adoption to application of DevOps. He talks about iteration being the key - ever improving. That said, I think this is exactly what the focusing steps are about. What is limiting our ability to grow now? How can we adjust our practices and policies now that we see that?
And step 4, Elevate? Many organizations discover that going through the five focusing steps they don’t need to “Elevate the constraint” right away - this often involves spending significant amount of money on people or equipment. Looping through the first steps often uncovers capacity that has been hidden by the ways of working in the system. When that elevate is required, the whole system has to be ready for it - increasing the capability / capacity at the constraint with a significant investment can easily shift the constraint to another part of the overall system. Are we ready for that?
My take is that with successful DevOps implementations the immediate “problem” that DevOps was meant to solve has been successful. That part of the business system is no longer slowing down the business. Looking at the larger business, something else is now the limiting factor - the constraint has shifted. This happens in The Goal where Alex Rogo realizes his plant is now operating faster than the demand from the market. So now the question is how to find ways to get more demand - decide how to exploit the new constraint and operate the plant according to this new way of working.
I’m happy to have a conversation on this one, as there are always many threads of discussion that I didn’t include here. And of course, there are many aspects of what Will Kelly described that may not have been included in the article that inspired this one.