Over the summer, a friend of mine (Andrew Schmitt) told me about The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim, Kevin Behr, and George Spafford. Since I’m running a software development shop these days, he thought I’d find it interesting, especially since it was written in the same format as The Goal and Critical Chain by Eliyahu M. Goldratt. For anyone not familiar with Goldratt’s work, this means the book is a fictional novel that contains relevant concepts, teachings and lessons that can be applied to business. In the case of The Phoenix Project, the story is about the IT division of an auto parts company . The business concepts are about how to more efficiently develop and release software projects.
The story within The Phoenix Project is OK, but not very strong. To put it bluntly, you’re won’t want to read it because of the plot. In it, the main character Bill Palmer is thrust into the role of VP of IT Operations after a reorganization at struggling auto parts company Parts Unlimited. The problems at Parts Unlimited are largely related to software development and deployment, and it’s Bill job to fix them before the Board forces a break-up or sale of the company.
The story begins with a seemingly endless string of software disasters. I understand that the authors create the large number of disasters in order to illustrate how to fix them, but it stretches your imagination to think things could be THAT bad. It just seems like Bill can’t catch a break until a business consultant who is considering a board role, Erik Reid, comes in to help Bill out of his predicament. Erik shows Bill how to apply concepts of lean manufacturing to software to improve the process. At this point, the book feels a lot like The Goal applied to software rather than manufacturing. However, I found the story surrounding The Goal to be a bit stronger than the one intertwined with The Phoenix Project.
As for the concepts, there are some great takeaways from the book. For example, I really like the way that they compare the development of software to manufacturing and use the Theory of Constraints concepts to run development. The book covers finding bottlenecks in your development process and how to smooth out the flow of work through the IT organization. It also spends a lot of time dealing with the flow of work and communication between development and operations (deployment) and how to optimize it.
Unfortunately, while the book covers a lot of great concepts, I felt that it was a little light on depth when it came to implementation. There are certain concepts covered that are applied between chapters with little explanation about how it was implemented. Also, the book definitely caters to a larger organization that contains larger development, IT and operations teams. I’m not saying that the concepts can’t be applied to smaller teams or start-ups, it’s just not as clear as to how these would get implemented on a much smaller scale.
Having said all of this, I’d still give The Phoenix Project strong marks overall. While I wouldn’t put it in my must read category, I’d highly recommend it to anyone who is in the software development field, particularly if you are managing the development and deployment of code. If you’re not in the field of managing software development and deployment, then you’ll want to pass on this book. The story is not strong enough to stand on its own.
By the way, if you are interested in learning more about the concepts behind the book, you should check out the DevOps blog on the IT Revolution website. There are a number of articles that go into more depth about concepts in the book as well as a link to additional resources for further reading. If you’re not sure you want to read the book, I’d suggest checking out the site first to get a feel for what The Phoenix Project covers.