The Phoenix Project – a key to understanding DevOps

Every now and then you read a book that completely changes how you understand something. “The Phoenix Project” (Amazon) changed how I understand DevOps and driving positive transformations in companies. Keep reading to see why I think everyone working in the software industry should read this book.

The DevOps revolution

I believe that as of 2018 the whole software industry is going through a DevOps revolution, similar to the Agile revolution that already took place.

If your organization already embraces DevOps, then congratulations- you are ahead of the curve. As a consultant though, I am seeing a large number of our clients make their first steps on the DevOps journey. I have previously written an article titled An Organization’s Journey to a DevOps Mindset and Culture that talks about some of these experiences.

Based on the feedback from a number of organizations that already adopted DevOps, or are just starting, this is often the most beneficial IT transformation that they ever attempted. Some companies were so impressed that they even let Scott Logic publish a case study on the topic.

Despite all that success, excitement and the revolution going on, there are still many people who don’t really get it. Why is DevOps important, why is it so successful, why is it such a big deal? They don’t want a dry handbook, they want a good, engaging story explaining it all…

The Phoenix Project

The Phoenix Project is a novel. It is the first time that I saw a major technical idea presented as an engaging novel, rather than a handbook, a guide or a list of tutorials.

The book follows a story of Bill, an IT manager that has to save his company from a collapse. In the process, he gets in touch with other managers and together they embark (unknowingly) on a DevOps transformation journey.

The book succeeds in a few ways:

  • It is very readable, it is actually fun to read. I read it in a few short days as I found it difficult to put down. This is incredible when compared to most traditional manuals or guides.
  • This is a book about the journey, about the transformation. You can see the dire state the company is in the beginning (I am sure many readers will recognize their own issues there) and how it all ends. It brings hope, making it clear that most companies start from a pretty difficult place.
  • It is really good in illustrating common problems and people you are likely to deal with real life. It is actually quite scary how closely some of the characters matched to people I met during my career. That helps you relate and see how things can be fixed.
  • The core ideas are illustrated clearly and in details. You can see the principles and their applications. You also see how the main hero discovers the core concepts, making them more memorable.

This is a fun read for those working in Software and IT while teaching important lessons. What more can you ask for?

The core concepts explored in The Phoenix Project

The key concepts that really stood out in the book are The Three Ways and The Four Types of Work. I will mention these briefly here as I don’t think it will spoil your reading:

The Three Ways

  • Flow: This is the flow of work going from Development to Operations to the customer. Maximizing that flow is one of the keys to success. The practices included in Flow are continuous integration and deployment, limiting work in progress, creating environments on demand, automation etc.
  • Feedback: This is the flow of fast feedback. Identifying problems as quickly as possible. Creating quality and knowledge. Practices helping feedback are automated test suites, builds failing in the deployment pipeline, monitoring etc.
  • Continual Experimentation and Learning: This is about creating a culture that fosters continual experimentation and learning. This is required to get Flow and Feedback, but also to maintain them. Activities that can help here are: creating a culture of innovation, building trust, allocating at least 20% of Dev and Ops time to non-functional requirements etc.

There is more to each of these practices and the book does a great job at exploring them in depth.

I have published a blog post about making agile software teams more productive from the inside based on these ideas. I really like how The Three Ways apply both to individual teams and the way they co-operate.

The Four Types of Work

Making work visible is very important. Without transparency, it is difficult to get a grip on what is really happening and where the time is spent. The four types of IT work described in the book are:

  • Business Projects – Business initiatives, most of the development work.
  • Internal IT projects – Infrastructure and IT Operations. Creating new environments, automating things etc. Often not tracked properly. These create problems when Operations are already under stress.
  • Updates and Changes – Often generated from the two previous types of work. Updating and changing different systems.
  • Unplanned work or recovery work – Incidents and problems generated by other work. These make it harder to do the planned work.

The Phoenix Project explores these different kinds of works and investigates their impact on the Operations team and the wider organization.

Final Words

The Phoenix Project is a fascinating book and a great first step on your DevOps journey. I really recommend that you read it if you have not done that already and share it with the team. Once you get the ideas and you are in a need of a handbook rather than a novel- there is a highly recommended Devops Handbook (Amazon). Good luck on your DevOps journey.