Thoughts about the connection between DevOps and the Theory of Constraints

July 15, 2018
Contact Us
Weekly Shorts are topics we discuss in our weekly remote meeting related to recent work we have done with our customers
Thoughts about the connection between DevOps and the Theory of Constraints

Before I started working at ProdOps, 4 months ago, I never heard the terms “DevOps” or “Theory of Constraints”. 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 of time.
I was taught 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 basically 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 actually pretty straightforward, and yet, even I know that people don’t really practice this connection in real life.

Coming to think about it, ok it’s a clear 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” the comics edition and it says it all, both ToC and DevOps, but how to put it in words?
Not sure yet but I definitely love challenges.

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” (about the connection between these two sentences maybe I’ll talk some other time).

What I like about the Buddha's summary is that it is so simple.
Don’t 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 in order to try to 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, in order to do it we need to focus - really try. In order 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, 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 really 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 largest impact on the company’s bottom line.

I guess what I am trying to say is that I believe it’s very important to understand ToC in order 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 a great 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, 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 yet a lot to learn about both DevOps and ToC and writing this blog post was a way to challenge myself and checking my understanding so far. I would love to hear what you think about this topic and this blog in the comments.

Thoughts about the connection between DevOps and the Theory of Constraints
Sean Roisentul
Marketing Manager
With a broad knowledge of helping companies grow, Sean can learn a new field and find the right path to take. He has a self-awareness on where to focus and how to measure results to make sure you are not wasting time on activities that don’t add value. During his time off, Sean is a yoga teacher, scuba diving instructor, farmer, and also plays the guitar. His passions are learning and teaching, philosophy, and speaking with his plants all the time.