Book Review: The Phoenix Project

I recently completed 'The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win' and thought I would write a review.  I mainly wanted to capture notes and thoughts about the book for myself.

The Story

First off, hat's off to the authors (Gene Kim, Kevin Behr, and George Spafford) for turning the world of IT, operations and DevOps into a riveting story.  I could not tear myself away from the book and was genuinely interested.  It was definitely a page turner.  I found myself really hating certain characters which made the story that much better.  The book moves at a frantic pace as problems and issues pile upon each other.

The book tells the fictional story of Bill Palmer, an IT manager at Parts Unlimited (also fictional).  Bill is suddenly promoted to VP of IT Operations and the future of the company is quickly put on his shoulders.  Bill finds himself in production outage after outage, trying to keep the business operational.  His attempts to improve the operation's team success are filled with trials and challenges.   Bill is guided towards the path of righteousness by Erik Reid, a potential board member and lean expert.

I found myself drawing parallels between Bill Palmer's (the book's main character) plight and some of the challenges I was facing at Blackboard.  Now I have to admit that my situation is very different (not nearly as hectic), but I definitely took a lot from this book.

It's all about Culture

If you read enough about the DevOps movement, you will hear this slogan beat into your skull.  DevOps is not about a tool that you can install or a position on a team?  DevOps is about how well your company can work together to break down functional silos to collectively achieve business goals.  The Phoenix Project definitely stays true to this principle.  As I read through the early chapters, I was so captivated by the story that I didn't even notice that 'DevOps', 'continuous delivery', 'John Allspaw',  or 'deployment pipeline' didn't show up until page 294.  When I finally read that portion of the book, it hit me.  Everything Bill had done up to that point was slowly change the team's view of work and their role in the organization.  Cultural changes.

The Three Ways

Throughout the book, Erik squires Bill in the  "Three Ways".  The "Three Ways" are sprinkled throughout the book Bill tries to get a handle on his team's workload and figure out why they aren't producing work.  As the character Erik puts it,

The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that's what's between the business and the customer.  The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework.  And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are prerequisites to mastery.

If you have studied Agile or Lean, you will find these sound familiar.  It's my understanding that Kevin, Gene and George's other book, the Visible Ops Handbook goes into more depth on the "Three Ways".  I have been told it's a nice companion to the Phoenix Project, and I plan on reading it.

Realistic?

There were definitely times that the book felt more fiction than realistic.  When the sky was falling, Bill somehow stumbled upon the correct solution to the problem on the first go.  Yes the process of improving Parts Unlimited was iterative, but Bill never seemed to be offtrack.  And that was of course due to the help on his own personal Obi Wan Kenobi (aka Erik).  Erik played the role of the wise Jedi master beautifully, through his cryptic guidance of Bill towards the "Three Ways".  I looked at Erik's guidance of Bill as a great lesson for individuals trying to transform your team by yourself.  Seek help.  You can do it on your own, but employing an expert will make your life much easier.

I am also not sure that one can avoid studying the art of change management.  The book touches briefly on the topic indirectly, but it is much harder to change a culture than book leads you to believe.  That's not to say the lessons in the book aren't valuable, but the timeline should be taken with a grain of salt.  The book depicts a company on the edge of collapse.  Not everybody will find themselves with such a motivating catalyst for change.  More than likely you will find stern resistance to new ideas and approaches.  Be prepared to fight.

Conclusion

I thoroughly enjoyed the book and highly recommend it to anybody interested in DevOps, who works in IT, or works in an organization that has a dysfunctional IT shop.  It's a fast pace book that will leave with a long list of other books to read.  I also recommend you check out Jez Humble's review of The Phoenix Project.  (Note: I didn't read any other reviews until I had written my own, I am happy with the similarities) Go out and buy it now!

Share this:

Tweeter

---