The Phoenix Project and Slash processes • Slash

Slash presents the highlights of the “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win” handbook. Written by Gene Kim, George Spafford, and Kevin Behr, this bestselling book tells the story of the rise of Dev-Ops and Agile development in the ashes of the Phoenix project.

There was a time in the early 2000s when the DevOps concept of “failing fast, learning fast” was one of the greatest fears for organizations. Firms could not understand the idea of pushing continuous code delivery to help develop software in short cycles to ensure reliability.

However, from 2020 and onwards, DevOps, Agile, and other sets of practices were widely accepted and implemented by all organizations – ranging from small start-ups to massive government establishments. And presently, most organizations are staunch followers of DevOps.

The book “The Phoenix Project” enlightens how extremely DevOps is advantageous for companies in numerous ways, such as:

Applying DevOps improves the software quality and helps the IT department to make fast deliveries
Allowing organizations to respond rapidly and productively to handle market pressures
Teaches patience and rectify the “overnight” success myth
Instilling DevOps mindset within the workforce and enabling them to do wonders

A company’s success depends on its ability to use tech solutions. A problematic connection between IT and the rest of the company is still prevalent in many firms. The writers use a narrative to demonstrate the complexities, interconnections, and dynamism of IT solutions. They also illustrate how CEOs may use IT to gain a significant edge in the marketplace.

This is a narrative about Parts Unlimited, a fictional automobile parts firm whose revenues and share prices have declined over the last several years. Former Vice President and Chief Information Officer Bill Palmer had been asked to depart, and he had recently been elevated to the position of Vice President of IT Operations. Bill unwillingly accepted the position, only to be confronted with a slew of issues and insurmountable ambitions.

A possible board member and IT whiz, Dr. Erik Reid, helped Bill gradually turn the situation around. He discovered how to use IT Ops process-engineering ideas to generate actual business value via the capabilities of IT in his journey, which the tale followed.

Even though the Phoenix project was designed to assist Parts Unlimited catch up to its competition, it cost $20 million and took three years to create. Bill’s primary objective was to guarantee that the current IT systems were working properly so that the team could concentrate on the successful implementation of Phoenix in a few weeks. As time went on, he began to understand how improbable this ambition was.

Bill was unable to get out of the vicious loop of IT outages, lack of adequate change management and ticketing systems, and insufficient assistance and resources to do so. There are conflicts inside IT functions such as Development versus Operations, IT and other business units such as Finance, Marketing, Sales, and Retail Ops, and the CEO’s challenges.

So, how did Bill manage to turn the situation around and eventually bring everything back under control? Let’s look at some of the essential ideas and principles from the book and how the team used them to alter Parts Unlimited.

It is a fallacy that IT work cannot be standardized like manufacturing processes. Even more so, because of its complexity, IT work demands an even more rigorous and disciplined approach.

The idea is to concentrate on the value stream or the flow of value through the manufacturing process. DevOps (Development + IT Operations) Value Flow must be examined in the context of IT. There are several of these ideas in Lean or Agile methodologies.

There are indeed distinct kinds of IT work:

New software or features that benefit customers are examples of business initiatives that bring in revenue or strategic value for the organization.
Maintaining and updating current systems, or introducing new security patches, are examples of internal initiatives that benefit the organization’s customers.
Stabilization and improvement of the initial output from the two categories above need scheduled adjustments, such as bug fixes, version updates, or feature refinement.

For this reason, unplanned labor (such as firefighting) is the most risky. Any unforeseen work (e.g., an environment outage or a database malfunction) necessitates the usage of a resource that may otherwise be employed for more important tasks. When you’re a firefighter, you don’t have time or energy to do any other kind of employment (nor to plan your work). A downward cycle of issues and unexpected work ensues as a result of this.

Begin by taking an honest inventory to see where you are and what your limitations are. Then remove as much unplanned work as possible so you can get back in charge of your situation.

It isn’t enough to prevent IT problems from occurring. Ultimately, the objective should be to use IT to help the company succeed.

Naturally, the modifications will not occur immediately. However, you can get a glimpse of how it can be achieved by following the progress of Parts Unlimited, from their initially-disastrous situation to the point where they achieved record-high sales and profitability. They were able to respond quickly to customer needs and had a content, cohesive, and productive workforce.

This book shows how these ideas may come together in the real world to form or fail a corporation from manufacturing principles, IT issues, workplace politics, opposing corporate objectives, and resource limits. The book provides a framework for understanding the interconnectedness of the many concerns and moving elements that makeup such a daunting task.

Our approach at Slash

At Slash we take pride in our tech craftsmanship and strongly believe in applying best-in-class engineering practices by embracing DevOps and Agile practices. Such ways of working ensure we can optimize for continuous integration, push code often, safely and fast.

As DevOps and Agile go hand in hand, we follow the “Three Ways” approach (System Thinking, Feedback, and Continuous Improvement) from the Phoenix Project to enable the Agile principles of fast and incremental delivery, including:

Optimize software with process automation to eliminate errors and deliver the product faster
Perform early test automation using the Shift Left approach with continuous integration and deployment of security and compliance controls
Receive quick feedback through observance, flow and application monitoring, telemetry, and deploying A/B testing
Promote a culture of learning, experimentation, and collaboration to save resources
Optimize value stream generation at both practice and project levels to turn a business hypothesis into a “digitally-enabled” solution