Title: The Phoenix Project
Authors: Gene Kim, Kevin Behr, George Spafford
Published: January 10th 2013
Print Length: 345 pages
I was first made aware of The Phoenix Project from a post reviewing it by Jez Humble on the Continuous Delivery Blog, to quote the Amazon description, “The Phoenix Project is a novel about IT, DevOps and helping your business win”. Being a DevOps engineer myself this immediately sparked my imagination so I recently got hold of a copy on the kindle and got reading. Note: If you’re both an Amazon Prime and Kindle owner you can borrow the Kindle version of The Phoenix Project at no extra cost; superb.
The book opens by immediately setting the scene of the ficticious US Parts Unlimited business, highlighting its recent struggles to maintain a competitive advantage over its competitors and describing a significant board level restructure with immediate effect, the analysts highlighting their lack of confidence in the departing chairman but continuing CEO Steve Masters. From this point we’re then introduced to our main character, Bill Palmer, the director of Midrange Technology Operations at Parts Unlimited. Bill’s day to day activities and relative stress levels will no doubt ring true with anyone that has worked in a monolithic slow to react business where IT is simply seen as a burden and another cost centre.
We follow Bill throughout the book as he is rapidly promoted against his will to VP of IT Operations, experiencing how the success of the IT department and Parts Unlimited itself soon becomes his responsibility, we are then introduced to the infamous Phoenix Project itself, an internal IT project within Parts Unlimited that has been promising to the board and share holders for the last 3 years that this will be the turning point for the business, allowing them to restore profitability.
“The company has long promised that its “Phoenix” program will restore profitability and close the gap by tightly integrating its retailing and e-commerce channels”
A catalogue of IT failures unfold from this point, described in detail and allowing us sometime to understand what bad IT looks like and to get to know Bill, a likeable, pragmatic ex-serviceman.
The story really takes a turn when Bill is introduced to Erik by his CEO Steve Masters, Erik quickly becomes Bill’s mentor and begins to advise him in his own, sometimes patronising manor of The Three Ways: The Principles Underpinning DevOps. The story continuous and follows Bill on his journey to understand and implement The Three Ways, ‘Systems thinking’, ‘Amplifying feedback loops’, and ‘Creating a culture of continual experimentation and learning’. This is the main purpose of the book and the authors do a very good job of likening IT scheduling to the process of satisfying customer demand in manufacturing.
“We’re doing what Manufacturing Production Control Departments do. They’re the people that schedule and oversee all of production to ensure they can meet customer demand. When they accept an order, they confirm there’s enough capacity and necessary inputs at each required work centre, expediting work when necessary. They work with the sales manager and plant manager to build a production schedule so they can deliver on all their commitments.”
The above is something Erik believes without question and is repeated and instilled in us as the reader throughout the book. Bill’s journey, although rather predictable at times is enjoyable and well portrayed, there are a number of constant characters throughout the book, some likeable, others much less so, yes you Sarah and of course the always present super-geek and single point of failure Brent, a techie who is identified early on as the unintentional cause of many a bottleneck.
Personally I found the mid part of the book the most interesting, this is where Bill is in full swing implementing the The Three Ways and there are some fantastic high-level case studies that it doesn’t take all too much imagination to apply to your own situation. In particular the discussion around reducing the amount of WIP (Work In Progress) rung very true with my experiences both within manufacturing and IT, pairing this with reducing batch sizes (size of changes) made for a very interesting read and I challenge anyone to put some of this in to practise and not experience an increase in IT delivery throughput. A quote I particulalry enjoy is when they are discussing the current once yearly deployments.
“You’ll never hit the target you’re aiming at if you can fire the cannon only once every nine months. Stop thinking about Civil War era cannons. Think antiaircraft guns.”
A slight gripe I had is in agreement with Jez’s comment in that there was I believe an uncaracteristic amount of success in implementing changes, timescales were also incredibly short, but hey, it’s a novel.
In summary The Phoenix Project is a great read, at times I couldn’t put it down and I blitzed through it within a fortnight, rather surprisingly for me as a slowish reader. The focus of the whole story around The Three Ways is clever, although I firmly believe that DevOps and agile success within IT can’t all be summed up with hard and fast principles alone, however it provides some excellent context to real world, I also enjoyed the analogies to manufacturing engineering. With well thought out characters and some good side plots that ensure you don’t feel like it’s becoming a lesson, I would highly recommend The Phoenix Project to any business professional, not just those working within IT.