Book review: The Phoenix Project. A novel about IT, DevOps, and helping your business win

The book The Phoenix Project. A novel about IT, DevOps, and helping your business win written by Gene Kim, Kevin Behr, and George Spafford gives you great insights how to improve the success rate of your IT organization by transforming your organisation in a DevOps like organisation to deliver much faster (more than 10 deployments a day), still staying compliant and with less errors, the features your customers are asking for.

This heavy book, more than 380 pages is written in an entertaining, page-turning style. If you work in IT, you will definitely recognize many situations but also the typical characters in this novel.  It’s written in the same style as Dr. Eliyahu Goldratt’s book The Goal. Which was, as the authors mentioned one of their inspiration sources.

In the book we follow Bill who is an IT manager at Parts Unlimitted. Bill is asked to fix the mess of the Phoenix Project which is massively over budget and very late and will report directly tot he CEO. I fit can’t be fixed within ninety days Bill’s entire department will be outsourced.

Bill will get help from Erik, a prospective board member who teaches Bill that IT work has a lot in common with manufacturing plant work. Erik takes Bill several times to a manufacturing plant to show what he means.

We follow Bill and his team taking the five steps of the Theory of Constraints as described in The Goal.:

• Identify the constraint
• Exploit the constraint
• Subordinate all the other activities to the constraint
• Elevate the constraint to new level
• Find the next constraint

In this story it becomes clear that a developer Brent is the constraint. He is needed for every small or big change and the team puts all kind of measures in please like putting a Kanban board around his activities, prioritizing the work, reducing his workload et cetera.

During the journey we see Development, Quality Assurance, Compliancy, Operations working more and more together and becoming what we would call a DevOps organization.

Step be step Bill starts to understand that he has to create and integrate three ways of working:

• The first way is a left-to-right flow of work from Development to IT Operations to the customer. This flow needs to maximize by managing the Work In Progress (WIP) and have continuous build, integration, and deployment practices.
• The second way is about the constant flow of fast feedback from right-to-left at all stages of the value stream.
• The third way is about creating a culture that fosters two things: continual experimentation, which requires taking risks and learning from success and failure and understanding that repetition and practice is the prerequisite to mastery.

To understand the flow with the IT value stream Bill had to find out that there are four types of work: Business projects, Internal IT projects, Changes and Unplanned work or recovery work. See attached figure.

Following Bill we get, on one hand, a great story about his struggle to drastically improve the way the work within Parts Unlimitted and you, as reader, wants to know how he succeeds and on the other hand we get fantastic insight in the world of DevOps.

The final forty pages is called The Phoenix Project Resources Guide. Why do you want to implement DevOps and where DevOps came from? Explaining the three ways and the four types of work as well as a demystification of some of the top DevOps myths. The last chapter is a list of recommended reading and further resources to learn more about DevOps philosophies, tools, and techniques that were used in the book.

I would say a must for those who are entering the world of DevOps.