I finished reading The Phoenix Project yesterday. Reading might be putting it lightly. I pretty much devoured it after starting it Monday night. I grabbed it off a colleague's shelf Monday after feeling a little beaten down about things. I knew a little bit about the book going in so my hope was that it was going to be a pick-me-up kind of read. Overall, it was a pick-me-up read, although I don't think I was the intended audience of the book.

The book follows the pattern many "leadership" books do of telling a fictitious story that injects the concepts that are central to the topic of the book into the story. It reminded me a bit of Monday Morning Mentoring. We follow the main character who gets a ton of responsibility shoved onto his shoulders in the midst of crisis after crisis. While trying to get a handle on it all, he meets a guru character well versed in Lean manufacturing methodologies. The guru slowly/painfully educates our hero and we learn as he does. Slowly but surely our hero learns and puts the guru's wisdom into practice and saves the company. I've certainly seen Lifetime Movies with worse plots.

The book is broken down into 3 parts, but I felt like topical division was slightly different that pure thirds.

• The first 5/8s of the book is really spent elaborating the problems of the organization and woes of our hero. (ZOMG End Of World)
• The next 1/4 of the book is spent discussing how the man character and his minions get all the work and problems under control. (Kanban, Theory of Constraints, and Lean)
• The last 1/8 of the book is about creating a deployment pipeline, treating infrastructure as code, using the cloud to scale. (DevOps and Continuous Deployment)

As a developer who is trying to get his organization to start on the path of Continuos Deployment and treating infrastructure as code, I was hoping for more meat than the last 1/8 of the book. That being said, I took several good things from the book.

• Most IT organizations have too much Work In Progress and no correlation between that work and the actual needs of the business.
• Lean concepts are interesting. Prior to reading this book, most of my lean knowledge was paired with Six Sigma training. Six Sigma was very worthless for software development and I tended to write Lean off with it.
• As a developer, asking why we are doing something is equally as important as understanding the how we will do something.
• Transparency and knowledge sharing are important to maintain good flow.
• We need to start making progress towards most of the DevOps stuff now.

I found this as a good reference about many of the concepts in the book.

Overall, I recommend the book. It's a fast read and it gets many of the concepts across. You won't use it as a reference book, but it might help win some hearts and minds.