- Home>
- book review>
- Reflections on ‘The Phoenix Project’: IT, Innovation, and the Path Forward”
Reflections on ‘The Phoenix Project’: IT, Innovation, and the Path Forward”
Published February 26, 2024
in book review
I recently finished reading “The Phoenix Project,” a novel that illustrates typical problems hindering the productivity and growth of organizations where software development plays a crucial role. I thoroughly enjoyed the book because it presents a compelling story with characters, a plot, protagonists, and antagonists, while also reinforcing important concepts to help IT professionals transform their organizations.
The novel vividly describes the challenges IT professionals face in organizations consisting of multiple departments and cross-functional teams with competing priorities. For example, one challenge is the difficulty in expressing opinions or admitting mistakes without being blamed or punished. This hinders the ability to surface issues sooner rather than later. Another challenge is the accumulated technical debt of the system, which slows down the team’s productivity due to the time spent fixing bugs rather than building features that bring business value. As team productivity declines, pressure from management to deploy Phoenix keeps building up, since executives are trying to save the company from losing business to competitors who seem to have better software and funding from investors who are getting worried about the company’s prospects. Yet another challenge is competing priorities. Although management states that the Phoenix project should take the highest priority, developers are being pulled in all directions. Specifically, Brent, the lead engineer who has the most knowledge about how everything works, finds himself constantly having to fix issues with little time to work on Phoenix. Moreover, most of what he does is not widely known or understood by others, illustrating the problem with knowledge sharing and inadequate documentation. Last but not least, the team also faces challenges with balancing work. For example, John, the Chief Information Security Officer, demands that the team fix security and audit issues. However, sometimes those security requirements get in the way of development instead of adding value, especially when the company is on the verge of going out of business.
As the story unfolds, important principles are introduced to address the challenges and turn things around. For instance, the principle of flow states that all work should be visible and suggests the best mechanism to surface work is through kanban boards. Making work visible helps identify unnecessary or unplanned work. In the book, unplanned work refers to technical debt or other issues like software failures, which prevent the team from doing actual work that brings forth business value. The goal is to increase the flow of work from inception to deployment.
“This is a critical part of the First Way, which is creating a fast flow of work through Development and IT Operations. Index cards on a kanban board are one of the best mechanisms for this because everyone can see work in progress (WIP)”. (Kim, Behr, & Spafford, “The Phoenix Project,” p. 161).
The story continues to unfold other principles related to improving the feedback loop between Development and IT Operations, building quality at the beginning of a software development process rather than at later stages. In the book, these principles are referred to as the Second Way. Achieving faster feedback requires faster release cycles, which in turn requires that quality be baked in at every step of the process, from development to production deployment.
“Now you must prove that you can master the Second Way, creating constant feedback loops from IT Operations back into Development, designing quality into the product at the earliest stages. To do that, you can’t have nine-month-long releases. You need much faster feedback.” (Kim, Behr, & Spafford, “The Phoenix Project,” p. 285)
The book introduces other principles and refers to them as the Third Way. These principles are about continuous learning and improvement. The book gives an example of what happens when the environment does not foster or set up for continuous learning and improvement. For example, Brent is the only engineer who possesses the knowledge to fix production issues. However, he cannot work on multiple issues simultaneously. As such, the team has the majority of work in a progress state and cannot move forward because they all require Brent’s attention, yet he is busy fixing issues that no other engineers seem to be able to help with. According to the Third Way, the team can find ways for Brent to share his knowledge freely with other engineers, set up post-mortems for team members to share knowledge, admit any mistakes and lessons learned from them, let engineers experiment and learn from one another. In the book, when the invoice system fails, understanding the Third Way, instead of letting Brent work on the issues immediately, Bill decides to have the team systematically analyze the issues, identifying the changes that have occurred in the production that may lead to the failure, and go from there. This way, Bill is trying to break the cycle where every time some issues occur, only Brent can address them.
The last part of the book leads to the introduction of “The Unicorn Project,” another novel that discusses DevOps principles that help organizations and teams deliver value faster and make work more enjoyable. I have really enjoyed reading “The Phoenix Project” as well as the other books in the series and gained a deeper understanding of the important principles that I think will serve me well in my job. I strongly recommend anyone who works in IT to check out “The Phoenix Project” and the other books in the series.
