The Phoenix Project - A DevOps Allegory

In 2016, I read The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.

Having recently applied for a role which (tongue-in-cheek) requires that applicants have read the book, I thought I’d (tongue still in cheek) publish my Kindle notes from my original first-pass.

TL;DR : It’s an allegory for DevOps - what it is, how it works, what the core principles are. The book is an easy read, and it hoodwinks you into learning the fundamentals of DevOps while following along with the misadventures of the protaganist, Bill, who gets “suckered” into taking the role of VP of IT Operations.

In refreshing myself for 2019, I read Claire Brooking’s review, and what struck me was this paragraph:

At its most raw, this book can easily feel like a lesson in humility.

It’s not the case that at the end of the book, DevOps and Agile approaches to working have magically evaporated all the challenges facing Parts Unlimited. Conflict, incidents and mistakes are inevitable – what counts is how Bill and other team members grow to manage and resolve them. By the end of the book, Bill, his team, and Parts Unlimited have structure, process, and a more open attitude to change and adaptation to stand them in good stead.

Specifically, humility strikes a chord for me. I think back on the companies I’ve worked for, and how the IT department is seemingly “at odds” with the rest of the business “for their own good”.

Original notes below:

‘change’ is any activity that is physical, logical, or virtual to applications, databases, operating systems, networks, or hardware that could impact services being delivered.”

“Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service.”

“Properly elevating preventive work is at the heart of programs like Total Productive Maintenance, which has been embraced by the Lean Community. TPM insists that we do whatever it takes to assure machine availability by elevating maintenance.

‘Improving daily work is even more important than doing daily work.’

Resilience engineering tells us that we should routinely inject faults into the system, doing them frequently, to make them less painful.

Erik continues, “Rother calls this the Improvement Kata,” he continues. “He used the word kata, because he understood that repetition creates habits, and habits are what enable mastery.

“When a resource is ninety-nine percent utilized, you have to wait ninety-nine times as long as if that resource is fifty percent utilized.”

“You’ve got to stop thinking like a work center supervisor. You need to think bigger, like a plant manager.

..that enable multiple deployments per day in their seminal book Continuous Delivery. Eric Ries then showed us how this capability can help the business learn and win in his Lean Startup work.”

..constantly elevating the improvement of daily work over daily work;

DevOps also requires shared goals and shared pain throughout the IT value stream.

..allocating at least twenty percent of Development and IT Operations cycles towards nonfunctional requirements, and constant reinforcement that improvements are encouraged and celebrated.

I think the graph serves that purpose, and it is the most effective way of communicating the catastrophic consequences of overloaded IT workers and the fallacies of using typical project management techniques for IT Operations.