The Phoenix Project is a novelization of an agile transformation at an autoparts company. It is written to show how the transformation helps the whole company and not just the IT department. There is also a resource guide to provide additional details for those inspired to implement agile after having read the book. The novel itself is about Bill, an IT manager who gets promoted up the chain during a series of crises.
Over the course of the novel, Bill learns – through a series of interactions with a guru who had previously helped the company resolve issues with their production lines – how to deal with a failing software development project, a complex system outage, and mundane day-to-day IT tasks like replacing a dead laptop, and he thereby gains control over his work life. Being a novel rather than a normal technical or business book allows it to introduce concepts and show how they are applied. This is beneficial too in breaking a major concept into digestible pieces, since if you look at the entire set of agile practices being suggested, some of them are designed to solve problems that the reader hasn’t necessarily seen yet. The book goes through the learning and rollout processes in a company that was very close to having a complete IT meltdown.
Showing the concepts in action seems to be a powerful way to assist in visualizing for those who have been exposed to the concepts but not necessarily put together what they mean in practice. I found the depiction of the work in progress lesson particularly intriguing since it is always somewhat difficult to understand in the abstract. The work in progress situation was shown through Bill finding that there was one person who was involved in almost everything going on even though most of those things don’t seem related to what the team was doing. Most of the examples are made in a physical production analogy rather than directly discussing the ideas in the software context. It seems to me that the structure was to keep the book from being a single monologue from the guru who is mentoring Bill, but I also think it makes the story more interesting by letting Bill discover the steps on his own. The author shows a bit of self-aware humor, as Bill gripes about the guru’s oblique descriptions in the text.
The target audience seems to be upper management, which makes the story more about leading the change and telling people to do it rather than how the change works for the actual developers. This makes sense to a certain degree, since a bottom-up agile transition is more difficult to do. The management perspective is especially enlightening in the section discussing change control; the company is looking at all of the scheduled changes that aren’t getting done. Bill then asks the insightful question: if we are failing to make hundreds of supposedly important changes a day, why isn’t it causing a problem? It helped them recognize there was a lot of work being considered that, while useful, was not resolving their major issues.
If you are already up on agile stuff from an individual contributor role I would probably pass on the book in favor of something else more immediately relevant. As an agile coach, scrum master, or executive it seems like a useful perspective to add to your portfolio. As a standalone novel it is somewhat dry, since other than Bill and the CEO the characters lack depth and there isn’t much dramatic tension.