The three ways of DevOps
December 14, 2016
In this blog post I want to talk to you about "The Three Ways" of a DevOps practice.
I first heard of The Three Ways in a very interesting DevOps introduction book called The Phoenix Project by Gene Kim, Kevin Behr and George Spafford. If you have not read it yet, I would highly recommend it. The book is written in a business parable style and it follows Bill, an IT manager, as he tries to deal with different IT issues at his company. Throughout the book, Bill relies heavily on a mysterious DevOps and Lean guru called Erik and their conversations help Bill learn the importance of DevOps and of optimizing workflow.
An important point of The Phoenix Project, and more specifically of Bill and Erik's conversations, is the realization that all the DevOps practices can be narrowed down to three principles: The Three Ways. Let us have a look into these principles in more detail.
The First Way
The main point behind this first principle is about having the work flowing from left to right as fast possible, from Business, through Development, to Operations, and ultimately to the Customer, where the value is actually created.
One way to speed up the flow is to lower the amount of Work in Process (WIP) which, by itself, does not provide any value: Much like raw materials in a warehouse, WIP only creates value as a finished product in the end of the flow. That is why we want to have smaller pieces of work going through the pipeline from left to right, resulting in a faster flow, which ultimately helps deliver value faster—and also enables faster feedback on that work (see The Second Way for more on this).
The First Way: Improving flow from left to right (inspired by http://itrevolution.com/the-three-ways-principles-underpinning-devops)
<<< Start >>>
<<< End >>>
Another important action to consider when focusing on this principle is the removal of constraints. Your flow will never be faster than your biggest constraint in that flow's path. If you have a node that is very busy, and if the flow you are considering needs to go through that node, then the speed of the work will be slowed down by that constraint. In The Phoenix Project, the node or the biggest constraint is a person, Brent.
Improving the flow throughput in your business might not "just" be about people or technology, it might also be related to the company's culture and processes. Could it be that your biggest constraint is a process that is being used by the company for a long time and that is worth revisiting? Maybe looking into the process is not as hot as looking into new technologies, but you could gain a lot from it if that is where your biggest constraint resides.
The Second Way
The Second Way focuses on increasing the feedback loops from right to left. Here, the focus is on increasing both the number of feedback loops that you have in your flow (are you only getting feedback from what you have in your production system?) and also on how fast you are getting that feedback (how long does it take for a faulty business requirement to be detected? Or for a bug introduced by a developer?). An important point here is that we want our flow to be stopped once errors are found and we want the feedback coming from that error to be transmitted as fast as possible to the source, so that it can be fixed.
A good way to achieve this is to have a continuous integration, build and deployment process working together with a fast, automated suite of tests. These two things together will enable you to provide quick feedback to your developers.
The Second Way: Enhancing the feedback loops (inspired by http://itrevolution.com/the-three-ways-principles-underpinning-devops)
Diminishing the amount of WIP in your system will also improve the speed of the feedback loop. With a smaller amount of WIP, work will move faster through the pipeline, enabling it to be tested sooner in the next node in the flow, which will allow for faster feedback. As Erik says to Bill in The Phoenix Project: "Now you must prove that you can master the Second Way, creating constant feedback loops from IT Operations back into Development, designing quality into the product at the earliest stages. To do that, you can't have nine-month-long releases. You need much faster feedback."
The Third Way
This principle is all about developing and fostering a culture where constant experimentation and learning is encouraged and where people acknowledge that the way to mastery is through repetition and practice. When it comes to Operations, one of the best things to aim for is probably boredom. You want to have well established processes and practice so much that your operation activities become boring and predictable. I know that might sound… well... boring, but you probably would like to avoid surprises in anything that has to do with Operations, wouldn't you?
The Third Way: Culture of continuous experimentation and learning (inspired by http://itrevolution.com/the-three-ways-principles-underpinning-devops)
As for continuous experimentation, it is not an easy thing to cultivate since it requires taking risks and learning from both successes and failures. Taking risks is usually something that the Business would like to avoid. But maybe you can take some risks in a somewhat controlled way? Focusing on the First and Second Ways will allow you to take some risks because you know that the risks will never be too big (given that you have small WIP) and you will also have fast feedback on the changes you are introducing in the system.
In the book, Erik tells Bill that "The Third Way is all about ensuring that we're continually putting tension into the system, so that we're continually reinforcing habits and improving something."
It would be great to hear your experience on this: Can you see these principles in your business? Is your business focusing on any of these ways? If not, can you think of some cases where the business should be focusing on these principles? Reach me on LinkedIn or on Twitter @josequaresma
Suggested reading
- The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford
- The Three Ways: The Principles Underpinning DevOps, an article by Gene Kim
- The DevOps Handbookby Gene Kim, Jez Humble, Patrick Debois and John Willis
- The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt and Jeff Cox further discusses the removal of constraints in order to improve flow
