The Phoenix Project and The Three Ways: An exploration into the three ways of DevOps

The Phoenix Project is a book that is based on the DevOps handbook and how IT operations interacts with the rest of a business. It chronicles the pains of an auto parts company that is having issues with its IT Department. We follow Bill who just got promoted to Director of IT operations and we get to see a wide variety of challenges that Bill faces. One of the most fascinating things about the book is how it tells about the Three Ways of DevOps and relates it to the challenges that Bill faces.

The First Way:

In a nutshell, the first way just talks about the flow of work. In the book, there is an eccentric potential board member that helps Bill understand the three ways. To help him understand the first way, he took Bill to a warehouse where Bill got to see how things went from raw materials, to Work in Progress, to finally an end product to be shipped to consumers. When it comes to DevOps, workflow is incredibly important. For example, if the capacity for WIP is full and more projects keep getting accepted, it would be impossible to effectively manage it or even complete the projects that are already WIP. One way that Bill used the First Way was utilizing a Kanban board. This helped visualize the flow of IT work within the company. The First Way can help a company drowning in IT projects become more efficient and increase the amount of workflow.

The Second Way:
The Second Way emphasizes the importance of the feedback loop. But we must remember that the
feedback loop is unimportant without following the principles that create the first way. Now that the first way established a solid overall understanding of the system and never passed a known defect to downstream work centers we are able to begin analyze conditions and make corrections. The second
way goes from right to left which means the process comes full circle and operations is able to feed
information back to the development team. This creates unity between the two ways and forces them to have shared goals and shared pains. This feedback information is powerful when we’re able to make it into an iterative process. Through this loop the operations team looks for key learnings through the process. This is crucial when we learn from a production outage or a service impairment or a security breach. When defects and problems are spotted we have the opportunity to identify how to correct this and return these corrective measures back to the beginning of the line (right to left). The second way creates value at the source and enables understanding of the more complex parts of a system and allows for corrective actions to be taken.


The Third Way:
The Third way is all about developing and fostering a culture where consistent experimentation and learning is encouraged. The goal is to build a routine that becomes so ingrained in the process that it is almost boring, like you know exactly what you’ll be doing so that there are not any surprises. The problem with continuous/consistent experimentation, is that it is risky and that is not part of the normal operation for most businesses. However, what you receive when you consistently test is the ability to learn from both failures and successes. However, there is the ability to take risks in a controlled way. Using the First and Second ways we can tell that the risks will never become too large to handle ensure and that the feedback on 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."

Only once you master the three ways you can hit DevOps nirvana.