An Easy Read and Good Introduction to DevOps
Bill Hoberecht - This email address is being protected from spambots. You need JavaScript enabled to view it.
PMO leaders, don't be left in the dust. While agile teams are justifiably proud of transitioning from twice a year big-bang releases to bi-monthly releases, others are already releasing multiple times per day! Introduce yourself to DevOps with this book, The Phoenix Project, and get excited about the possibilities of ultra-effective cross-functional teamwork and short release cycles.
The Phoenix Project is an eye opener for those interested in understanding your team's capacity and how effective teamwork can create an ultra-agile organization. If you are in a PMO or lead a PMO, your strategic planning and considerations for your organization's future can benefit by understanding the breadth of topics covered in The Phoenix Project.
This book is a must read for anyone in IT who has responsibilities for delivering technology solutions to a user base. While ostensibly about DevOps, it weaves in concepts from many established quality methods. The three authors have created a linear, easy to read story, that feels like a description of our own challenging IT experiences. At the same time, they demonstrate how some key concepts from the Theory of Constraints, Toyota Takt, The Improvement Kata, Deming's Plan-Do-Check-Act, Continuous Delivery, Lean, Kanban, Teamwork/The Five Dysfunctions of a Team can apply to the problems we face daily. In short, they've distilled a large number of quality concepts to highlight the practical application of a few key quality methods.
Our protagonist, Bill Palmer, just can't catch a break. He unexpectedly gets promoted to VP of Operations and is now responsible for handling a nightmare of constant systems failures that are causing significant business issues. The backlog of work is beyond overwhelming, the incessant business demand for delivery greatly exceeds capacity, executives subvert the intake process and go directly to developers to get their pet projects started, no one even knows how many projects are in progress, no one has ever thought to understand IT's capacity, deployments into production always fail, compliance has a crushing list of mandatory controls that must be implemented, a critical new project must be deployed to enable the company to meet financial targets yet the project is running very late, and executives are constantly making decisions to resolve the immediate crisis with no time left for strategic thinking. Sound anything like your experiences?
Erik, the wise yet quirky (and sometimes caustic) mentor, helps Bill, through a series of conversations on a factory floor, understand the real problems he is facing and how to apply quality principles in making hard decisions and improving the organizational capability. In short, Erik is our guide in sorting through the plethora of management fads and quality concepts to find those few nuggets that can really help. The final 30 pages of the book contain a guide to the many quality methods that are mentioned throughout the book.
Once you read this book, you'll know more about:
- The Three Ways
- The Four Types of Work (business projects, internal IT projects, changes, unplanned work)
- What DevOps is really about (part of it is teamwork: product management, development, IT operations and information security all working together and supporting one another)
Some situations or dialog in the book directly, and quite pointedly, challenge the status quo:
- (Pg 162) ". . .if we're going to talk about your next steps, you definitely need to know about constraints because you need to increase flow. Right now, nothing is more important." (This is Erik's means of introducing the Theory of Constraints into Bill's thinking. The landmark book "The Goal" introduced that theory to us a few decades ago.)
- (Pg 212) "Improving daily work is even more important than doing daily work." (This is Erik's introduction of The Third Way)
- (Pg 296) Erik: "I think your target should be ten deployments a day." Bill Palmer: My jaw drops. "That's impossible." (This is Erik getting to the real possibilities of DevOps. His proposal seems crazy in a traditional IT world, yet several in Silicon Valley have indeed figured out how to execute flawless deployments with incredible frequency. The notes at the end of the book show some examples from 2012: Twitter: 3 deployments/week. Facebook: 1/day. Google: 5,500/day. Amazon: 23,000/day. These are all widely used, high availability, high capacity platforms. Here's the 2009 45-minute talk by Allspaw & Hammond on 10 deployments/day. You can quickly scroll through the slides here.)
- (Pg 298) "You think IT Operations is rocket-science compared to manufacturing . . . From where I am sitting the people in this building [the factory] have been far more creative and courageous than anything I've seen come from you IT guys so far." (Erik is pushing Bill to really think outside the box and consider possibilities that break established boundaries for delivering technology solutions, pointing out that innovation is pervasive on the factory floor and needs to be more present in IT operations.)
A few reviews on Amazon criticize the book as a fairy tale; that it describes decisions and solutions that no organization could ever implement in the real world. One point of this book is that very hard decisions (e.g., halting most new work, focusing only on completing the most critical projects, and decreasing work in progress) are not easy, yet can yield tremendous benefits to the business, employees and customers. Businesses and IT groups that seek to maintain the status quo are missing an opportunity to make big improvements.
This book does ignore the complex topics of transformation and organizational change management. Not a big deal, as these are covered more than sufficiently elsewhere in a plethora of books and articles by others.
While you are reading the book, try to predict how Erik will next guide Bill in addressing a situation or problem. It's hard. I predicted Erik's recommended approach only about half of the time, and in the process learned quite a bit.
What was your reaction to the book and your key take-aways? Who is your Erik, available to guide and be your sounding board?