The Three Ways: The principles underpinning DevOps
Researcher, DevOps guru and former CTO Gene Kim recently co-authored The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. The novel, written with Kevin Behr and George Spafford, demonstrates just how bad enterprise IT can get—and how the right approach can save the entire business. The following guest post recently appeared in Kim’s IT Revolution newsletter.
(Discover Performance readers can download an extended 170-page excerpt of the book here.)
In The Phoenix Project, our protagonist, Bill Palmer, the acting VP of IT Operations has ninety days to figure out how to get the most critical projects deployed, increase their uptime, and get the auditors off their back!
Through the course of the book, Bill learns about “The Three Ways,” which are the principles that all DevOps patterns can be derived from. By putting The Three Ways into practice, Bill figures out how to replicate his own “good to great” transformation.
The Three Ways are as follows:
The First Way emphasizes the performance of the entire system, as opposed to the performance of a specific silo of work or department — this as can be as large a division (e.g., Development or IT Operations) or as small as an individual contributor (e.g., a developer, system administrator).
The focus is on all business value streams that are enabled by IT. In other words, it begins when requirements are identified (e.g., by the business or IT), are built in Development, and then transitioned into IT Operations, where the value is then delivered to the customer as a form of a service.
The outcomes of putting the First Way into practice include never passing a known defect to downstream work centers, never allowing local optimization to create global degradation, always seeking to increase flow, and always seeking to achieve profound understanding of the system (as per Deming).
The Second Way is about creating the right-to-left feedback loops. The goal of almost any process improvement initiative is to shorten and amplify feedback loops so necessary corrections can be continually made.
The outcomes of the Second Way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it.
The Third Way is about creating a culture that fosters two things: continual experimentation, taking risks and learning from failure; and understanding that repetition and practice is the prerequisite to mastery.
We need both of these equally. Experimentation and taking risks are what ensure that we keep pushing to improve, even if it means going deeper into the danger zone than we’ve ever gone. And we need mastery of the skills that can help us retreat out of the danger zone when we’ve gone too far.
The outcomes of the Third Way include allocating time for the improvement of daily work, creating rituals that reward the team for taking risks, and introducing faults into the system to increase resilience.
In “The Phoenix Project,” Bill uses all of the Three Ways to figure out what’s wrong, and create countermeasures to not only fix the problem, but help the business win. We’ve also been using the Three Ways to talk about why DevOps is needed, as well as framing the prescriptive patterns.
Next time, I’ll talk more about how DevOps affects the daily work of Dev, QA, IT Operations and
Infosec.
“The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” is available now from IT Revolution Press. Discover Performance readers can download an extended 170 page excerpt of the book. For more about HP’s approach to DevOps, visit hp.com/go/devops.
Read more in Discover Performance about DevOps and an interview with the authors of “The Phoenix Project.”
