Book Review: The Phoenix Project

A couple of weeks ago, my team leader dropped a book on my desk. “Read it,” he said. So I started reading The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win written by Gene Kim, Kevin Behr, and George Spafford. Now that I have finished my first reading of the book, I wanted to share some thoughts about it.

In Short

Essentially, the book is about how a company, Parts Unlimited, transforms into a DevOps culture. Not just because they are trying to be hip, but as a necessity for the survival of the company. The book is written as a novel and is therefore easy to read. During the story, it turns out that an IT project has a lot in common with manufacturing plant work. A lot of what happens to the company and the main characters is so recognizable that it is almost scary. I will not give an elaborate summary of the book; instead, I want to share some thoughts that came up to me when reading the book.

Some Thoughts

In this section, I cover some topics which I wrote down when reading the book. These are topics which were very recognizable to me or made me look differently to things. I hope these thoughts might be useful for you as a reader, too.

Dependency on Experts

Parts Unlimited has an IT expert named Brent. He is a very experienced expert and knows how to solve almost everything. This is widely-known in the company and therefore everyone demands Brent to do something in their project. As a consequence, Brent is very busy and because every project is demanding something from Brent, every project gets delayed because Brent has become the bottleneck. It is even getting worse because Brent is so busy with solving problems, he is not documenting his work and is increasing the dependency on his personal expertise. As a consequence, knowledge is not shared and it is difficult to help Brent with his work. The business always demands Brent because he is fast and knows about almost everything. This situation is mainly created by Brent himself, because he did not share his knowledge with his colleagues. You can probably name the Brents in your organization without hesitation. You shouldn’t have to get rid of them, of course, because these are your most valuable experts. But a culture of knowledge-sharing must be promoted and must be made easy. If you are a Brent yourself, if you leave the company tomorrow, can you simply show your colleagues where everything is documented (if they don’t already know) or do you have to make a brain dump of what is in your head?

Lack of Communication

A lack of communication between teams is a major problem in organizations, and I am not only talking about communication between the Dev and the Ops people. Communication failures also occur inside teams or teams which seem to cooperate closely together. Completing a task or User Story (or whatever you call it) is a joint effort. If you have developed something and someone else is testing it, it should be normal that one is helping the other one in order to accomplish a good result.

Continuously Improve

Continuously improving your processes is vital for your organization. The Retrospective in Scrum provides the tool for improvement, but most important is that you have embedded improvement into your process. And not just talking about it, but also doing something with the suggested improvements. Major problems will occur when your only focus is fixing bugs and implementing new features and do not create time for process improvements. Before you know it, you lag behind compared to the rest of your competitors. At some point in time, the gap you need to bridge is so big that it will take some huge amount of work. Besides that, not improving processes or tooling will make it more difficult to find applicants for your organization because they don’t have the skills anymore for working with outdated processes or tooling.

I am not stating here that old processes or tooling are bad by default. These processes often are introduced in order to solve problems and therefore contain a lot of value. It becomes different when you ask colleagues why a certain process needs to be followed and the answer is: "We have always done it this way." That’s when the alarm bells need to get off. This probably means that several years ago the process was altered to solve a problem, but we don’t know which problem we solved and whether the current way of working is not causing us even more problems.

Continuously improve your processes, be critical about why you are doing things, read about success stories of other organizations, and keep your knowledge up-to-date about new techniques. All of these things are vital to your organization.

Unplanned Work

One of the most important items in the book is how unplanned work influences the planned work. Creating a plan for work to be done is not very difficult. Maybe your estimates can be improved, but you learn this by doing. The unplanned work is more difficult. Unplanned work must be reduced to a minimum in order to have more control.

A major source of unplanned work is operational issues. Operational issues are very important because they impact the business and the business is creating the revenue for your organization. The unplanned work is also know as technical debt. You need to spend some time to reduce the technical debt which will reduce the number of operational issues which will create more time and predictability for your planned work. This means that the commitments you gave for the planned work can actually be achieved.

Another source of unplanned work is interruptions of the business (operational people, project managers, etc.) which bypass the established process in order to get their work done. They access the developers directly in order to get things done. This must not be allowed, and the developers should redirect them to a team leader or Product Owner or Scrum Master or whoever is in charge of the work to be done. Often the developer is already interrupted and the task is not so big, so he executes it right away. The requester is happy but an important precedent has been created. The requester now knows that accessing the developer directly gets his work done immediately. Although the developer had the best intentions, this will cause him to get interrupted even more in the near future. All of these small tasks will eventually have a great impact on the progress of the planned work.

How Do You Feel Today?

You work in a team. But how well do you know your colleagues? Knowing what is on someone’s mind can help in approaching someone. Every day is different and it might be possible that you are not feeling very well today (physically or mentally). Maybe you had an argument with your partner, your child is sick, your favorite team lost a game the day before, or maybe you just are having a bad day. Knowing that someone is not feeling OK today can help in getting a better understanding of how someone might react.

Conclusion

I can really recommend reading this book. The story of the company is very recognizable and the transformation the company is going through in a couple of months makes you think about the processes in your own organization. Moreover, a cultural change in an organization is probably the most important item to accomplish drastic changes. It is now time for me to go for a second reading of the book.