I have worked in software development for several years. Early on, I realized the benefits of utilizing agile practices and have preached them ever since. Along the way, I educated myself on lean and also determined that many of those concepts also apply to software development. As I worked with many teams that began having success with agile, I found that most of them only achieved a certain amount of success until they became roadblocked. And they seemed to be roadblocked at the same point: IT Operations seemed to want the complete opposite of what agile teams wanted. Where agile teams wanted lightweight processes, IT Operations seemed to want heavyweight processes. Where agile teams wanted to release often, IT Operations seemed to want less frequent releases. Where agile teams worked together, IT Operations seemed to want to work through heavyweight tools.
A few years ago I first heard of the DevOps concept but never really explored it. After attending IBM’s Innovate 2013 conference, I realized I could no longer ignore DevOps. The 2 main focuses at the conference sessions were Agile & DevOps.
In looking around for books, there were some that seemed the standard “What is DevOps” books. I got the basics of DevOps from presentations, discussions and articles, but what I was really looking for was how to apply it in the real world alongside agile projects. Then I came across The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. It seemed to walk through an organization that was struggling with IT and how to turn it around.
As soon as I started reading, I was sold. The first page instroduced the executive team of Parts Unlimited, a fictional organization that sells auto parts. The second page is a press release announcing the chairman of the board has stepped down, the stock price has stumbled and the already years late Phoenix is expected to announce another delay.
Over the next few pages, we learn that Bill, an IT Operations manager is getting promoted to VP of IT Operations reporting directly to the CEO, even though he does not want the position. He is told that he has 90 days to fix the problems. What ensues is probably very close to home to most people that work in IT.
The book is broken into 3 parts.
Part 1 – Parts Unlimited Current State
Bill reluctantly accepts his new position but has not time to wait. Immediately he gets pulled into high severity issue after issue. These include employees not getting paid correctly because of an issue with the payroll system, a Sarbanes-Oxley audit with 952 issues and a variety of other problems between the various IT organizations. Oh, and his #1 priority is to deliver The Phoenix Project, the project that will save the company, is too big to fail, already is over budget and schedule and still has a large list of issues. After working in IT for several years, I can relate to each of these situations. It is obvious that the authors have had their share as well. After being forced into releasing The Phoenix Project with all the risks and issue, thing hit rock bottom when Bill is told he has 90 days to turn things around or IT will be outsources and the company will be split. No pressure.
Part 2 – Reborn from Phoenix Ashes
With the pressure on, Bill receives some guidance from Erik, an IT guru who is also a potential board member. Erik takes Bill under his wing and guides him on his journey. He teaches Bill about many concepts from lean, even taking him to the manufacturing plant and showing the implementations of lean concepts. He guides Bill in how this applies to IT, but leaves it up to Bill to make the link. Bill works with a few key members from other areas of the organization to start from the ground up to build IT to what it needs to be.
Part 3 – Phoenix Success! (IT/DevOps)
After 90 days of coaching from Erik, challenging his assumptions and working with various members of IT, Bill helps Parts Unlimited turn the ship around. There is still work to be done, but the reader can see that the state of the company and the overall culture of the company has changed. Many of the adjustments that have been made have helped bring people together and allow the company to respond to change quicker and with more confidence.
Summary
This book was just was I needed, and I recommend anyone in IT read it. It is a novel, so it is unlike most other IT books that you have read. In terms of writing, it is not top notch like you would expect from someone like Dan Brown, but it is effective enough to convey the message. I liked some of the different elements thrown in, such as press releases, emails, etc. They added a level of realism to it. I like seeing some of the challenges when they were up all night trying to get a system deployed and running into the point of no return. This brought me back to nights where I experienced the same, “been there, done that”. I also really enjoyed that Bill, the one telling the story, was from IT Operations. Being primarily from a software development background, it allowed me to gain more of an understanding of “the other side” and seeing how what we do in development impacts the other areas of IT. After spending several years working with agile teams and implementing lean concepts, I really confirmed for me that successful IT (and therefore successful business) goes beyond delivering software. We in IT need to focus on the entire life cycle to deliver a business solution. I also really liked the heavy focus on lean. The authors weaved in several lean concepts, but did so in such a way that someone who was not familiar with terms such as “value stream mapping” could understand what was meant. They did not dig into a lot of detail, but mentioned several other books (such as The Goal: A Process of Ongoing Improvement, Kanban andThe Five Dysfunctions of a Team: A Leadership Fable) that would allow the user to learn more about specific topics.
The one struggle that I had was the “ease” of implementing the changes. Obviously the novel is just to indicate the path and each organization will need to adopt it to their own situation. That said, I have not been at many organizations (right or wrong) that would just shut down a list of 100+ open projects to get the underlying process and infrastructure in order (right or wrong).
As mentioned, I recommend this book to anyone involved in IT. To me, it is basically a 300 page long case study into how to transform your IT organization to “help your business win”. I think this is an excellent book to get people started into understanding the high level of what needs to be done to transform IT departments that are in trouble, but you will definitely need to follow it up with more focused reading, such as on topics of lean, theory of constraints, kanban, etc.