When a co-worker handed me a copy of The Phoenix Project, the 8-bit art on the cover looked fun. But the tagline — ‘A Novel About IT, DevOps and Helping your Business Win’ — sounded a bit like the usual buzzword management lingo. But I was clearly wrong, I loved this book!
It is unlike anything I’ve read before and it really spoke to me because the situations were so incredibly recognizable. The book tells a fictionalized story where the main character, Bill, gets promoted — more or less against his will — to VP IT Operations and subsequently inherits a bit of a mess. Things keeps breaking and escalating, causing SEV-1 outages all while the billion dollar company is having a bad couple of quarters and put all their hope on Project Phoenix. An IT project that is supposed to solve anything and everything; already three years in the making and nowhere close to be finished.
The story revolves around Bill and his struggle of how to turn things around. On his path to discovery he is mentored by an eccentric figure called Eric (who is such a great and funny character).
I feel like Bill and I have a lot in common, mainly because the book is really spot on when describing situations IT departments can find themselves in. Some scenes were a literal copy of things I have experienced. As if the writers were there and took notes. It made me laugh out loud or raise my eyebrows on more than one occasion. The reliance on certain key-figures, the disruption of self-involved Marketing/Sales people, the office politics, the lack of trust in teams, the weight of technical debt, the difference between requirements and customer needs. It was all too familiar. So for me the power of the book is the true-to-life examples, because those provide the basis for arguing the successful application of the theory.
Because the book is in fact the theory of DevOps compiled into an exciting story. Which is a lot more fun than it sounds.
Actually the book could be seen as a modern day version of The Goal by Dr. Goldratt — a book that handles the Theory of Constraints — which I had of course heard of, but never read. The writers of The Phoenix Project make no secret of their admiration for Goldratts’ theory. But DevOps is of course a thing of its own. A relatively new paradigm, borrowing from TOC, Lean and Agile principles among other things. Its goal is ‘to aim at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives’. And where The Three Ways theory is a central aspect, unifying culture with production flow. The book shows how those theoretic mechanics work in practice. And that IT is closer to manufacturing than you might think; by breaking down the four different types of work there are in IT. That was actually an eye-opener for me. But I won’t go into too much detail about DevOps, I just wanted to point you in the right direction. If you work with different people to create anything in IT, you are probably going to like this book, and are bound to learn something.