I just finished a book called “The Phoenix Project” written by Gene Kim, Kevin Behr, and George Spafford. It is the first book published by IT Revolution Press. It seeks to instruct the reader in the rudiments and benefits of IT done “Devops Style”, or rather, IT done according to the tried and true methods of factory / plant management that have been explored for a few generations now. It does this through the telling of a fictional tale. Skeptics of the so-called DevOps movement, don’t be alarmed.
The TL;DR Review
The book is a fictional account of a director of IT at a large enterprise; an enterprise that has a deeply flawed IT organization that is dragging the company into destruction. He is quickly turned into acting VP of Operations after the sudden departure of the last VP. Bill has 90 days to turn the IT department around or face the dual threat of a total IT outsourcing and the failing company being split apart by an aggressive and impatient board of directors.
The storytelling is poor. The concepts themselves are great, however not explained to the depth that you would expect from a 300 page book. If you have a genuine interest in doing better as an IT person in general, pick the book up and see if it excites your interest in the various operational methods to getting things done for the business using IT. This is not a management book. This is not a developer book. This is not an operations, sysadmin, cloud, ITIL, infrastructure, or $buzzword book. This is about workflow management done from a factory background that can be applied to anyone’s work. If you’re skeptical of the so-called DevOps movement, don’t be afraid of this book.
I’d give it 3.5 out of five stars.
The Long Review
The story centers around Bill Palmer, a late-thirties ex-Marine (I know, I know – “no such thing as an ex-Marine!” – you know what I mean) with a wife and two kids. He starts the story as the Director of Midrange Technology Operations. Side note: I have no idea what “midrange technology operations” is, nor did I figure it out after some Googling.
He is quickly thrust into the position of VP of IT Operations to fill a sudden vacancy. He and his entire department is thrust under the intense scrutiny, skepticism and frustration of a hard nosed CEO, board of directors, and SVP of Retail Operations. It’s fix or fail time, and he’s got everyone working towards failure.
Before we go any further, let’s get the bad parts out of the way
The storytelling is awful. The book is not intended to weave a masterful tale, so I’m not terribly disappointed. However, there came a point about halfway into the book that the writing became grating to read and was an obstacle to the subject matter.
There is virtually no character development, and what little development can be seen is either banal (Bill Palmers, toughened Marine, fighting back tears while telling about his bad father at a team building session) or bizarre (late devops adopter, security-guy-John, disappearing for weeks in a drunken haze without being fired, then suddenly reappears with a shaved head and GQ clothes and now he “gets it”). Neither dramatic occurrence helped move the story along very much if at all, and in fact the sudden addition of drama looked garish standing in such obvious contrast to the rest of the vanilla story.
Adding to the lack of character development, is that each character reads like every other character. There were many times in the book when a character would be delivering two or three consecutive paragraphs of dialog and halfway through I would lose all notion of who was speaking. Was it Wes? Patty? Bill? John?
Each character is gruff, cold, worn out, and mildly bitter. I wanted to punch Erik, the supposedly sage-like purveyor of factory Zen, sometime around the book’s halfway point. By the end of the book I wanted to lock him in his precious heat-treat oven. I was genuinley surprised at some of the raw language. I don’t flinch much at cursing (I didn’t notice any of it in Reservoir Dogs), and certainly in the real world some meetings can have blue streaks pour out from under the doors. That’s life. However, I found the sheer number of “goddamn”s and “shit”s distracting to the book, not an addition of realism. Maybe if the writing had been better, it would have fit. Instead, the book seemed like it was trying too hard to be one of the cool kids, and as a result there are a not insignificant amount of people who will find the language to be a distracting irritant to the core of the book. Some people will not finish it at all.
The story is also a bit sing-songy at times with some meteor sized tropes that crash and burn in the midst of the text. Examples include total chaos being turned around in double time, skeptics are silenced at just the right time, the tough guys show their tender sides, and there is a self-seeking back stabber who gets their comeuppance (sort of?). Oh, and there’s an irreverent hippy who sticks it to the man! Want more? How about someone who has a hidden special forces background. To complete the cycle, the book just needed a dragon slain by a cowboy who gets the girl and rides off into the sunset singing a love song.
I think the storyline was unrealisticly biased in favor of the concepts. I do not think it is possible to have turned around such a large company as Parts Unlimited that was as deeply flawed in its operations, company structure, workflows, and personalities in the just over four months. I do not think it is realistic at all to have so many changed hearts and minds in so short a time. From years of bitterness, frustration and institutionalized failure to suddenly, in four months, most people “get it” well enough to be embracing, adopting, and successfully practising such drastic changes. Is it possible? Yes. Possible in that amount of time? No.
Keep in mind that the characters and storyline are mere vehicles to transport much larger concepts to the reader. It’s an overgrown parable that has been fattened too much to comfortably carry its heavy topics on such a brittle skeleton. You will gain the most if you can discard the storytelling and focus on the concepts.
Fortunately the parts of the book that could truly be called “bad” aren’t directly tied to what the book is actually about. The book is about how to get IT, from infrastructure to development, from management to security, to work closely together with eachother and the other business units while using workflow management methods that have been vetted on factory floors for generations.
What’s merely “okay” is that the book doesn’t do complete justice to the core concepts that it intends to teach. Seemingly every chapter introduces a new manufacturing term, plant management buzz phrase, or factory concept. From “takt time vs cycle time” to the difference between bill of goods and, I believe, “bill of resources.” Oh, and during one dialog, the book refers to “single-minute exchange of die” as a legendary concept. Okay – I’ll take their word for it. However, these concepts and terms are thrown at the reader in clusters that can be overwhelming. They are explained well enough to get you through that portion of dialog and whet your appetite, however at times they are dropped unceremoniously into the reader’s lap for them to stare at and grope for the full meaning.
Terms like “kanban”, “katas”, “The three ways” and references to Toyota’s manufacturing prowess are woven throughout the book, however they seem like mere allusions and foreshadowing to a future time in the book. However, the foreshadowing doesn’t blossom into an actual in-depth explanation of any of them. Certainly those concepts and tools are large and themselves need many books to be fully developed, however I think a few pages of focused explanation should have been given to them. I still don’t know what a “kata” is precisely and what “The Three Ways” are in any concrete way.
In spite of all the above, the book did excite an interest in these things. You instinctively understand that there are many large concepts that are being introduced, each of them mere tips to golden icebergs. That sensation offers a bit of forgiveness to the lack of clear explanations for some factory terms and processes. Even the main character Bill Palmer has to write down a few words and phrases for later review, which leads me to believe the authors knew what was happening with the flood of factory-think. However, it only works if you later mop up the mess you made, but instead you’re sometimes left cold and wet wondering what just happened. The deeper concepts that inspired the book seem near and dear to only one or two characters in the book, but kept at a distance from the reader.
I started this review with the negative so that I could end on a positive note. With all of the above said, you might think that I hated the book. I didn’t hate it. I didn’t love it either. I liked it – and want to like it more than I do. I think it deserves a re-read once I take in some of the works that represent the larger body of knowledge that this book rests on.
For example, I’m planning on reading Dr. Eliyahu Goldratt’s book, “The Goal: A Process Of Ongoing Improvement”. Apparently The Phoenix Project follows closely in the footsteps of “The Goal” in structure and topic. I want to learn more about “The Toyota Way” of manufacturing and look into Jez Humble and David Farley’s book “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.” I’m interested in the concepts behind agile and lean manufacturing as applied to software development, but also on a larger scale of IT project delivery.
To be fair, I was gaining more and more interest in those concepts before this book, however The Phoenix Project wrapped up many of these concepts, and in conjunction with the the book’s blog gave interesting backstory and history to them. As a result I think it does a good job of encapsulating very complex topics into a primer in the form of a fictional case study. I think the storytelling, being as poor as it is, gets in the way at times, but if you can ignore that, the book has a good chance at exciting you over the possibilities that an IT department has if monolithic thinking is let go in favor of a more holistic, business-centered approach that includes lean manufacturing concepts.
One of the most fantastic elements to the book is that it isn’t at all focused on the tactics involved. No specific technologies are talked about, no vendors, no task management styles, no ITIL. It seems that there was great effort spent on not mentioning any vendor for any reason. For a book over 300 pages long about IT, there are hardly any references to what they’re using to deliver the services. It’s mentioned briefly that one of the ops teams manages 1,000 Windows servers. Another time a reference is made to an Oracle database. That’s about it. No specific mention of any vendor is made. No language, no hardware, no software. The closest thing to an endorsement is a few references to the various IT teams using open source tools to quickly create a solution, and that’s about as specific as it gets. Literally, it’s just about three sentences scattered around the book that basically say “the team used some open source tools to create a solution for…”
The Phoenix Project is about the strategic understanding of work. Not just IT work. Not just project management. Not operations. Not development. Just work. The concepts can be applied to any work wether it’s making fences from driftwood on the shores of a Madagascar to the most complex operating environemnt in the most web 2.5 trendy-kewl devop shop you can imagine. It very wisely and deftly avoids any vendor bias.
It also avoids departmental bias. SysAdmins, security, development, management – they’re not intentionally pitted against eachother. Bill, the protagonist, comes from an infrastructure background and his character has the typical negative mindset towards developers as being only in the business of crashing production systems and the security guys as only wanting to halt all projects with inane restrictions. The mindset is eye-rollingly stereotypical, however it shows each department’s conversion to a belief in a larger concept than just their small team’s goals. If any team got short shrift in the book, it was security, but I’m willing to admit that my understanding of how and why security was treated like it was is a bit foggy. I think there are larger concepts and business processes that I’m not familiar with that would explain what happened and why. (I won’t spoil anything – read it for yourself and if you figure it out, let me know!)
On a more nuts-and-bolts level, the book is presented in a very clean fashion. There’s no table of contents. There are no chapter titles save for having a date printed beneath the chapter number. There are 35 chapters spread across 338 pages making the story flow in small, manageable chunks. I like this format for this book since it makes less of an emphasis on story development and more on getting the reader to consume concepts in small bites. Had I not been multitasking so hard for a week, it could have been finished in two evenings. One Saturday if you’ve got nothing to do on the weekend.
The Background and Foreground
This book is apparently the first fruits of the digestion and practice of an enormous body of work and decades of combined life/work experience among the authors. Much of the material that this book is founded upon is listed in the IT Revolution Press blog post “Where to Learn More About Concepts In The Phoenix Project”.
These four authors have worked together before with the books “The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps” and “Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps”.
There is a second book on the horizon for IT Revolution Press called “The Devops Cookbook.” In fact, there is a very transparent pitch for this book that is woven into the final pages of the story. (Side note: I found the setup for “The Devops Cookbook” to be the most gag inducing part of the book, but by the time I made it to the last few pages I had gained a startling ability to quickly suspend my distaste for the storytelling and take the bumbling attempts at using various literary devices out of the equation.)
Those that know me a little closer than just through the blog (say, through ServerFault, forums, IRC, IM, email or meatspace) know that I’m somewhat critical of devops on a broad scale. Or rather, what is passed off as devops. Devops itself is a nebulous term that is in its infancy and still has no strict definition, so anyone can call anything “devops” and be nearly as right as the next person. However with an author lineup like John Allspaw, Patrick Debois, Damon Edwards, Jes Humble, Gene Kim, Mike Orzen, and John Willis, you know this will be the real deal. Not “I know ruby, installed puppet and now know everything about network management” which is what much of “devops” appears to be these days.
It is interesting to note that while the book is, of course, fiction, it does have an interesting way of blending reality into the story here and there. Mostly to make mention of certain names and books like Rother, Ohno, “The Game” and references to Toyota in the 1950s. In chapter 30, the 2009 Velocity Conference where John Allspaw and Paul Hammond delivered their “Ten Deployments Per Day” talk is referenced and takes the focal point for a few chapters as characters are aghast at the thought of that many deployments.
On the back of the book’s dust jacket, Adrian Cockroft is quoted as saying the book is an “IT swamp draining manual for anyone who is neck deep in alligators.” It isn’t. It’s an introduction course on wetland management written by a few brilliant professors that didn’t earn stellar marks in literature class.
The book feels like someone has overturned a box full or Erector Set parts in front of you and provided a few wrenches and torn instructions. You have a great sense of potential at what you see laying before you. The instructions give opaque guidance on the ultimate value that could be created with them. But you know you need more resources to draw on and time to think in order to pull it together a high degree of skill and success.
(Note: Apparently the book had a name change from “When IT Failts” to “The Phoenix Project.” This can be a bit confusing when researching the book itself. Even in the acknowledgements section at the end of the book, one of the authors refers to the book as “When IT fails.” Thanks to whoever was the catalyst behind changing the title from what would have been one of the most ill conceived book titles in the history of publishing to something compelling and worthy of the book’s awesome cover art. Thank you.)
If you can get past the story telling, and ignore the tropes and unrealistic outcome (or rather, the unrealistic timetable that the outcome developed over) then I think you can be fired up to probe deeper into this realm of plant management, katas, kanbans, and other means of managing projects. I think anyone looking to learn more about what IT can bring to a business, not just geeking out on specific technologies, this book will be a good tool to get your feet wet in some pretty large topics and give you a diving board into much deeper waters.