Thoughts about the connection between DevOps and the Theory of Constraints
Before I started working at ProdOps, four months ago, I never heard the terms “DevOps” or “Theory of Constraints” (ToC). I don’t have a technical background, and I was recruited to help with the company’s marketing, so I had a lot of catching up to do in a short period. I was told that “DevOps” is hard to define, it was explained to me in many different ways by various team members.
I have to say it made sense to me. I could see the value in applying DevOps and using it as a working methodology, I could also see why this value is often missing as Omer wrote in his article “There’s no such thing as a DevOps engineer”, but I was convinced, if I had a tech company I would have implemented DevOps. DevOps was not a bunch of cool technical tools in my eyes, because I don’t understand “technical”, for me, it meant a work philosophy and methodology, a best-practice approach for tech companies.
Soon after I started working and figuring out this “DevOps” thing my company is doing, I was referenced to the Goldratt’s “Theory of Constraints”. Just talking about it was incredible. I was telling my colleagues about changes I failed to implement at previous workplaces and they gave me the core reason why I failed straight away like they were in the process with me. Moreover, still trying to wrap my head around DevOps, I hear this amazing concept of ToC and they looked exactly the same to me, DevOps sounded to me like taking all of ToC and “squeezing” it into a tech box.
That had caught my interest even more.
Having been exposed to ToC several months ago I am afraid I am becoming one of those ToC addicts who talk about it all the time, I already do. I started reading books, watching lectures and everything I can get my hands on, limited by the mother of all limitations — time, reading time in my case.
By this time I learned a little bit more about ToC and DevOps, not much but enough to learn I was just stating the most obvious thing — These things are connected! So it’s not just me, it’s pretty straightforward, and yet, even I know that people don’t practice this connection in real life.
Coming to think about it, ok it’s a definite connection and all…but wait, no! It isn’t! If we need to explain something, again and again, writing books, blog posts and lecturing about it, then it’s not that clear after all.
- - Hey, dude, learn about baking to improve the way you make bread
- Sure thing man, on it - - Hey, dude, learn about ToC to improve the way you do DevOps
- What the…?!
I knew I was challenging myself when I chose to write about this topic. The people I see talking about it have years of experience and an amount of knowledge I don’t think I will ever have. I am staring at the cover of “The Goal”: A Business Graphic Novel and it says it all, both ToC and DevOps, but how to put it in words?
Not sure yet, but I love a challenge.
It is said that the Buddha was once asked if he could summarize all of his theory in one sentence, he answered:
“Avoid all evil, Try to do good and Cleanse one’s mind”
When Dr. Goldratt was asked the same question about 2500 years later, he answered:
“Why use a whole sentence, I’ll give it to you in one word — “FOCUS”
What I like about the Buddha’s summary is that it is so simple. Do not even succeed, of course, that’s the goal(!), but just try to do good and not evil. Goldratt’s answer is the key of how to do it — you’ve got to focus to try and do things, they don’t just happen by mistake or by hoping they do.
We are not talking about Goldratt’s life teachings but business teachings. We want to do good with our business and avoid harming it, to do it we need to focus — really try. To improve your systems and make a great product or service, you need to want that, focus and try to achieve it!
A great idea is not enough, and great developers are not enough either, the only thing that matters is the complete picture, how everything works together. What does ToC say if not to take a look at the larger picture and try to improve it? What does DevOps say if not to take a look at the larger picture and try to improve it?
We’ve found the connection.
Both ToC and DevOps are methods to improve a whole system — a.k.a System Thinking. They are both holistic approaches that aim to improve a whole process, a whole company. The idea is to find the things we can improve, and while doing so, it will improve the whole system. The things we can improve that have no impact are a waste of time and effort.
“Any improvements made anywhere besides the bottleneck are an illusion.”
-Dr. Elihau Goldratt
If you don’t improve you get left behind, in nature — if you don’t adapt and evolve you die. What should you improve? The things that will improve the whole thing. Simple.
I was taught that DevOps was forged in the space between the Development and Operations which is like a black hole where things break down and get lost forever. Breaking and losing things does not help us deliver a great product so stop, take a look at the whole system, and focus really hard on finding the things that cause you trouble.
Now that you have found the things that caused you trouble you can fix them. If needed — stop all the other things you’re doing and concentrate on fixing the problems. Those things don’t help anyway if they don’t improve the system as a whole.
I recently read Clarke Ching’s “The Bottleneck Rules” which explains how to identify bottlenecks — constraints. Since I read it I have been looking for bottlenecks everywhere (restaurants, traffic, shops…), the cool thing about it is that quite quickly it gets easy to identify the constraint. So you move on to think — “What should be the constraint? What is the thing that I want to be the master of my system?”.
ToCers talk about having a single, known, constraint that stays with you so you don’t need to shift your whole system every few months to satisfy a new constraint. They tell us to choose where it is best to have your constraint and then make it your constraint.
Thinking about the ultimate IT company, if I had an IT company, I would like the bottleneck to be my developers. I want everything in my company to be limited by the time it takes my developers to type code on their computer. Everything in my system should work in a way that allows my developers to release high-quality features quickly and is bounded only by their coding time. I wish.
ToC and DevOps guide you to make a “simple” change that creates a great impact. This “simple” change might be hard to find and changing it is even harder. The resistance to change is noticeable in ourselves, our colleagues and our competition. It’s hard to make this change because we are asked to change deeply rooted policies — changing them will create the most significant impact on the company’s bottom line.
I guess what I am trying to say is that I believe it’s essential to understand ToC to do (better) DevOps. I know it’s a big statement, coming from a guy who never did and will probably never do “DevOps”. I think ToC is an excellent tool for learning system thinking and from my understanding of DevOps to this day — that’s a very important thing. Automation and all that is awesome — but it feels from here like it’s missing its purpose and soul.
I read in social media groups and forums to see how people talk about DevOps. There are some who do it just for the money, and they didn’t really change anything but their title. There are those who are in it for the technology, mastering the tools and processes. And they are those who are enthusiastic about the philosophy, I don’t see many of them but they are there, people who understand what it means to be DevOps and try to implement it.
Of course, we need all three types, but I think that the greatest DevOps impact and achievements will arrive from the “philosophers” with the help of the tech experts. These two groups can create harmony by following the Philosophers deep-understanding with the high-level mastery of the technology.
I believe ToC is a giant DevOps “philosophers” should stand on.
“If I have seen further it is by standing on the shoulders of Giants.”
- Sir Isaac Newton
I highly recommend reading Evgeny’s post “DevOps Transformation Using Theory of Constraints” And Omer’s post “There’s no such thing as a DevOps engineer”. They go more in-depth about the connection between ToC and DevOps.
I know I have a lot yet to learn about both DevOps and ToC and writing this blog post was a way to challenge myself and to check my understanding so far. I would love to hear what you think about this topic and this blog in the comments.
Originally published at www.prodops.io.
