Review – The Phoenix Project, by Gene Kim, Kevin Behr and George Spafford

image

I have to admit something, I love case studies. When a software development book starts throwing out “examples” of the methodologies being discussed, I tend to get interested in the story. I start paying closer attention. If they’re well-written, I get very interested. Generally, I find myself wanting more. Naturally, I don’t get this – the book is a dry technical reference on software development practices and not a novel. The fiction interspersed within is meant to keep you interested.

The Phoenix Project takes this idea to the somewhat strange conclusion. Instead of being an exploration of IT topics with fiction within it, this is a piece of fiction that is an exploration of IT topics. A particular IT topic, in this case – lean development and DevOps. For those not in the know – lean software development is an evolution of agile software development that attempts to take lessons learned from the factory line (especially Toyota and just-in-time management) and apply them to IT and development. Its been around a whilso; I recall attending a session at a conference about it at least five or seven years ago. DevOps is a much more recent concept that, I think, emphasizes a focus on all pieces of an application – not just the code, but its exeuting environment, its network, its process for being changed. Its a really new concept, and one st ill being explored (note that “The Visible Ops Handbook” is not actually a book, at this point).

The book follows the “adventures” of Bill, a newly promoted head of IT for an ailing automotive parts/retail corporation. The company’s IT department has a history of failing to meeting obligations and having a revolving door management. This is particularly problematic given that it is also responsible for delivering “Project Phoenix”, a massive undertaking to revolutionize the company. It is not going well, and it is made clear to Bill that delivering Phoenix is vital to the future of his career. Bill himself seems like a nice guy, and is definitely the “reluctant hero” of this tale; he had no particular interest in advancing in his career and had to be cajoled by the CEO of the company.

He quickly regrets this – the IT organization is an underfunded disaster, with failing infrastructure, absolutely no process or change management, and a single employee (Brent) who knows everything about everything. Bill’s first day is spent running into a crisis involving the company’s payroll, caused by the company’s over-zealous head of IT security and leaving the company unable to print paychecks. It does not get better; Phoenix is quickly and clearly failing to meet a deadline pushed by a politicing SVP, whom has the power to push the CEO to demand its release on the unreasonable schedule of one week. No one working in the IT field will be surprised when this deadline proves a disaster, though in this case one of rather excessive scope. I will say at this point that it is clear the authors have been in one or more combinations of these disasters before – they write them vividly enough that I think anyone who has worked for a large IT organization will find themselves sympathizing with their plight and remembering past IT disasters of their own.

Bill is mentored in his “quest” by Erik. A quirky potential board member with a history in the technology industry. Erik completely serves as the sagely master in this novel. Most of his lessons take place at a local factory, where he illustrates his points about the four kinds of work and how to deal with constraints and how to move work through the system. His quirky personality works extremely well – picturing him as the Yoda of the novel wouldn’t be entirely far off.

The book winds down to its conclusion through very interesting portrayals of corporate betrayals, triumphs, and even a character whom entirely changes their conception of their job and life. The end is, inevitably, triumphant – this probably wouldn’t be an effective illustration of the principles the author wants to get across otherwise.

As a piece of fiction, I’m a fan of this novel. It manages to make a dramatic, interesting story about a bunch of employees in a corporation learning about a new IT methodology. It, mostly, avoids stereotypes – the characters are well-defined and have actual motivations. Even the aforementioned Brent is presented reasonably, as a helpful person who has simply been around forever. He’s a problem, but more in the way his job has developed than any particular maliciousness. The weakest characters here are probably John, the head of IT security, and Sarah, the villain of the piece. I get the impression that the authors have no particular respect for the way IT security runs at most orgs, and Sarah is mostly here to be a pushy, political executive. It works, for the story, mostly because the actual villain is the IT process – Sarah is simply there show the failings and stomp on them until they break. The other flaw is that the characters, especially Erik, are prone to exposition – this is probably unavoidable given the goals of the novel.

In terms of this book’s value as a work illustrating a new IT process, this is more mixed. They definitely explain all the points; I can’t say I don’t have an understanding of the four kinds of work at this point. The problem is that the book has limited value as the kind of reference guide that would be needed to put these thoughts into actual practice. This is one of the few novels I’ve ever read that could strongly benefit from an index. It could also strongly benefit from a companion volume that goes through all this in the more traditional manner. I suspect the “IT Ops Handbook” was meant to be that, but its impossible to say since that book does not yet exist.

Overall, I recommend this book. Its both a good read with an interesting, if unusual, story to tell, and certainly capable of getting one to think about the right ways to approach IT management.