The Phoenix Project by Gene Kim, Kevin Behr and George Spafford

A Novel about IT, DevOps, and Helping Your Business Win

Discover how DevOps can increase your company's value.







Parts Unlimited, an automobile manufacturing and retail company, has launched a new IT project. It's dubbed "The Phoenix Project," it's intended to seamlessly combine the company's retail and e-commerce platforms, giving Parts a competitive advantage and expanding its consumer base.


Phoenix is crucial to the company's success. It also needs to catch up to time and over budget. So, the CEO is searching for someone to clean up the mess. They'll have 90 days to turn things around, and the entire IT staff will lose their jobs if they don't.


While the scenario that follows is hypothetical, the issues and solutions it depicts are genuine, as anyone in IT will understand. These summaries describe how a fundamental, continuing disagreement between Development and IT Operations leads to failure for the IT department and the entire firm. And they demonstrate how a set of techniques known as DevOps can result in tremendous efficiency, cutting-edge performance, improved value, and a lot less headache.


In this summary, you will find

What does IT have to do with a manufacturing plant?

There are four sorts of IT work, and

why repeated failure is the key to success.



1. Chaos in the IT department means failure for the entire firm.


It's Tuesday morning, and Bill is running late to work. He's rushing down the highway when he receives the call; he's scheduled to see the CEO, Steve, as soon as he arrives.


Uh oh, he thinks. I'm going to get fired. It would not be a significant surprise. Bill, the head of Parts Unlimited's midrange technology division, has always been satisfied with doing his job correctly. He's earned a reputation for being dependable, efficient, and candid; he was a former Marine. However, Parts has been struggling significantly.


Bill looks around the nearly empty parking lot where he is driving in. Parts is lagging behind its competitors in terms of innovation. With so many layoffs in recent years, Bill's department has had to do more with fewer resources.


But Steve isn't firing him. He's granting Bill a "promotion." As the new VP of IT Operations, Bill will report directly to Steve and oversee the Phoenix Project's successful rollout. Steve claims that Phoenix is critical to the company's future; does Bill understand this? Customers must be able to shop online and in physical stores from Parts. Otherwise, there would soon be no consumers, and the company would cease to exist.


The main point is that the IT department's chaos means failure for the entire firm.


Bill wants to avoid the promotion; he would practically accept taking on the role of janitor, in charge of clearing up a massive IT plumbing problem. So he's shocked to find himself shaking Steve's hand in agreement.


Where should he start? The entire IT infrastructure is in complete disarray.


John from the Information Security department is constantly causing SEV1 outages - severe incidents that everyone has to race to resolve - by bypassing proper clearance procedures to push through Development modifications that he believes are vital for auditors. Of course, Operations will only be able to test these modifications after a test environment and a budget.


Meanwhile, Patty, the director of IT Service Support, advises Bill that changes are never documented; no one wants to spend time with the company's cumbersome change management systems. No one attends the weekly Change Advisory Board, or CAB, sessions.


How does anyone keep track of what's going on? Bill knows that they don't. No surprise things have become so bad.


Bill glances at his desk. His previous laptop exhibited the blue screen of death, so he recently obtained a replacement. It's at least ten years old, a giant, heavy dinosaur of a machine. Half of the writing has worn away, and the battery is taped.


He can't help but wonder whether the cosmos is trying to teach him something.



2. IT Operations, like Plant Operations, are guided by limits.


Phoenix is scheduled to deploy in ten days, but just three of the project's twelve final tasks have been completed because the IT department has been dealing with emergency situations.


Brent, the company's lead engineer, has handled them. Brent is a poor person. Bill needs to comprehend how one person benefits the entire organization. He has a gift for solving any challenge that comes his way. So he's been smacked with them all.


The main takeaway is that IT Operations, like Plant Operations, is guided by the principle of limits.


Just as Bill begins to take on his new responsibilities, he is told that he must meet with Erik, a prospective board member who appears to be a technical guru. But as he enters the conference room, the only person present is a donut delivery guy dressed in wrinkled jeans and a denim shirt. Bill thinks as he begins stacking the donuts high on his plate. Didn't realize they delivered.


Suddenly, the deliveryman turns around, extends his hand, and says, "I'm Erik." He then explained to Bill everything wrong with IT Operations at Parts. Erik believes there is a fallacy that IT is solely a knowledge-based profession. People think it is immune to standardization and documentation. However, IT may benefit significantly from Plant Operations. To demonstrate his point, Erik tells Bill to grab his belongings because they're going for a ride.


They arrive at one of the Parts' manufacturing sites five minutes later. Inside, as they stare out over the plant floor, Erik discusses the constraints principle: In most factories, only a few resources - materials, machines, or people - determine the output. These are the bottlenecks or restrictions.


To maximize efficiency, first determine the limitation. You need to know where your constraint is to know where to improve. And any improvement made at the constraint is worthwhile. Consider it as a line: If an improvement is made after the constraint, it entails more waiting. If it occurs before the bottleneck, it simply results in inventory buildup.


The second step involves taking advantage of the constraint. Your constraint should never be idle or waiting for another resource - it should always address the highest priority obligation.


Finally, subordinate the constraint. The slowest Boy Scout determines the troop's marching pace, placing that Scout at the front. In other words, all work should be released according to how rapidly the constraint can handle it.


Brent, Bill realizes, is the engineer who ultimately solves everyone's problems. Of course. He is their restriction. That's why basic 30-minute fixes have taken Brent weeks to complete. He is always utilized at or above 100%. Thus, any work assigned to him simply sits in the queue unless there is an emergency.


Everything seems so logical. Bill needs to figure out how to match Brent's work pace. Who would have predicted that IT employment would resemble running a factory?



3. Understanding the four categories of IT work can help you keep your obligations.


It's a few days till Phoenix's deployment, and the project management meeting could be better. Despite Bill's request for extra time, Sarah from Retail Operations is pressing for the launch to go as scheduled. Bill takes a deep breath as she criticizes the IT Operations staff for being slow to respond.


He's watched the movie previously. A project's delivery must be completed on time due to promises made to clients or Wall Street. The developers take over the timeline, leaving no time for proper operational testing. As a result, ludicrous shortcuts are taken, and the finished software product could be more stable and valuable. Who must pull all-nighters, reboot servers, and apply metaphorical Band-Aids to compensate for faulty code? IT operations.


Bill sighed. He's been thinking about something Erik mentioned: the four forms of job. Erik explained that rigor and discipline will only go you so far. Bill could not successfully manage project deliverables, outages, and compliance until he understood what IT Operations "work" entailed.


The essential takeaway is that understanding the four categories of IT work will help you accomplish your obligations.


Bill had warned Erik that getting Phoenix deployed was an effort. But Erik needed to be addressed. He explained that official company initiatives, or business projects, were merely one type of activity.


So Bill is currently racking his brain. What may the other categories be? He suddenly realizes it.


The second sort of job involves internal IT projects. These are infrastructure or IT operations projects that business projects initiate; they can also be enhancement initiatives such as automating deployments or creating new environments. Internal projects need to be more centrally managed, making their process challenging.


Changes, the third category of work, are typically the product of business or internal projects; they are any action that may impact the services provided. Changes in IT Operations and Development are tracked in distinct systems, which leads to mistakes and wasted time, particularly during handoffs.


Last but certainly not least, there is unplanned work. Unplanned work resembles firefighting. It handles all the incidents or emergencies resulting from the other three types of labor. And it always gets in the way of planned work commitments, jeopardizing the Phoenix launch.


Unplanned work prevents you from reaching your goals. In that sense, it is "anti-work"; thus, do whatever it takes to eliminate it. Life is not perfect. Things go wrong, and unforeseen work always comes up. The trick is handling it efficiently, which begins with determining where it is coming from.


It is frequently the result of technical debt, which you accumulate by taking easy but ultimately unwise shortcuts. Like financial debt, technical debt accrues compound interest over time. If you don't pay down your debt, you'll spend all your energy paying interest, which takes the shape of unplanned work.



4. Trust, communication, commitment, accountability, and a shared goal are all hallmarks of great teams.


Bill tries to apply Erik's lessons. But Steve, the CEO, steps in; he insists on doing things the old way, according to an unachievable deadline. As predicted, the Phoenix launch fails spectacularly. Bill doesn't bat an eye.


Instead, he quits.


Without him, the project faces a much steeper dive. The several divisions - IT Operations, Development, and the business - are desperately trying to bring order out of chaos. But they're constantly at odds, passing blame around like a hot potato.


They need Bill. So, after some cajoling and a tempting incentive, he returns.


The main takeaway is that great teams value trust, communication, commitment, accountability, and a focus on shared success.


When Bill enters the conference room, Steve is discussing his childhood. His family was really destitute, he recalls. He spent summers picking cotton with his brothers and was the first to attend college.


Ugh, Bill thinks. I despise this touchy-feely bullshit. However, they must interrupt the dog-chasing-tail cycle, or Parts Unlimited will fail. So, all department heads are sitting down to discuss Steve's favorite book, The Five Dysfunctions of a Team.


According to Steve, trust is the cornerstone of teamwork and is essential for resolving any problematic business problem. Thus, the first team dysfunction is a lack of confidence. Leaders can become embroiled in conflict and persistent underperformance simply because there is no trust. There is also a trickle-down effect: when leaders do not trust one another, neither do teams.


So, how do you build trust? It all begins with vulnerability, which is why Steve is leading a personal history exercise. To model vulnerability, share your background and motivations. Then, ask each member of the group to do the same.


The second dysfunction is fear of conflict. Choosing false peace over constructive, impassioned debate is a lost cause. Candid discussions regarding contentious matters can be difficult. Leaders and teams must overcome ingrained behaviors, yet embracing disagreement can accelerate Development.


The third dysfunction is a failure to commit. Fake buy-in, particularly in collective choices, promotes ambiguity and disinterest in the workplace.


The fourth dysfunction is an avoidance of accountability. Not accepting responsibility and not calling out peers for counteractive behavior both set low expectations.


Finally, there needs to be more attention to results. It is never a win-win scenario when you prioritize your personal gains, position, or ego over the team's performance.



5. The First Way refers to the flow of work from Development to IT Operations to the client.


The leadership conference only resolves some things, but that is not the goal. Bill believes the team's capabilities are much better: a shared vision as they work toward a solution. It is time for everyone to work together. Erik thinks it's time for DevOps, a set of techniques that combines software development ("Dev") and IT operations ("Ops").


Today, DevOps is transforming IT in the same way that the industrial revolution transformed industry. Instead of optimizing the process of converting raw materials into completed items, DevOps demonstrates how to improve the IT value stream, which includes reducing time to market, creating more flexible and resilient systems, and integrating tests to swiftly test prospective innovations.


DevOps work patterns are based on business ideas similar to those of manufacturing. Erik refers to them as The Three Ways, with the first focusing on the process.


The main point here is that the First Way involves the flow of work from Development to IT operations and finally to the client.


A significant component of the First Way is to ensure a rapid flow of work between Development and IT Operations. Use a Kanban board instead of wasting time reducing to-do lists and reprioritizing commitments at weekly executive reviews.


Essentially, a kanban board depicts ongoing IT tasks. By consolidating all projects in one location, everyone on a team can immediately see how much is going on and what needs to be done at any moment; there is no need to sort through or keep track of fragmented emails, text messages, or phone calls.


Draw three columns on a wall to design a kanban board: Ready, Doing, and Done. Label index cards with all active work activities and arrange them in the appropriate columns. Here's the catch: you can only have four or five cards in progress at any given moment. The First Way emphasizes minimizing the amount of moving elements. This enables the team to concentrate on and finish a few jobs rapidly before moving on to the next. When a task is performed, relocate the card to its new location. For example, shift the card from Ready to Doing when you begin a task.


Erik's First Way prioritizes the success of the overall system over a specific department or silo of work. Kanban boards reduce WIP and help teams commit to the correct work - and the appropriate amount - by emphasizing what is most important to the company's overall performance. The bottom line is that value is generated once code is in production, so reducing unnecessary labor from the system is generally more important than adding more. And being able to say no to commitments is essential; remember, the less work in progress, the more productive you will be!



6. The Second Way addresses quality issues at the source to avoid rework.


Erik describes a 2007 Suzuki Hayabusa dragster motorcycle as beautiful. It can reach speeds of more than 230 mph. It features a six-gear constant mesh box and a #532 chain drive. It doesn't have a reverse gear.


He is trying to make a point. IT workflows, like high-speed motorcycles, should not contain reverse gear. Work that moves backward due to faults or uncertainty is literally waste. Ideally, the flow of work should be in one direction: forward.


To continue with the automobile analogy, the Second Way focuses on preventive oil changes and vehicle maintenance.


The essential point here is that the Second Way requires addressing quality issues at the source to avoid rework.


The Phoenix Project's release intervals are now nine months long. However, if Bill wants to incorporate quality into the product from the start and ensure onward flow, it is far too long a period. He needs considerably faster, amplified feedback loops from the client or IT Operations to return to Development.


Or, as Erik adds, "Stop thinking about Civil War-era cannons." Consider anti-aircraft guns.


The goal is single-piece flow, which means one product unit flows between the several operations. In other words, focus on one element at a time. Reducing the wait time between phases increases throughput, restricts W IP, and reduces mistakes.


Take, for example, Toyota's infamous single-minute die exchange. This term indicates how the company achieved single-piece flow through a series of advancements and reduced its hood-stamping changeover time from three days to less than ten minutes.


In IT, single-piece flow can be achieved via the continuous delivery method, which focuses on three things. The first is a modest batch size. Working in smaller batches lets you quickly implement feedback loops and course-correct if necessary.


The second step is to stop the production line when difficulties arise. This includes not taking on new work when builds, tests or deployments fail.


Third, develop rapid, automated test suites to ensure that code is always available for deployment. Remember, code isn't "done" when Development finishes coding; it's when it's tested and works as intended.


Erik offers a slight adjustment to Phoenix's release intervals. Instead of one deployment every nine months, Bill could aim for ten deployments a day.


Impossible, Bill believes.


But that's precisely what Flickr accomplished in 2009. At the time, most IT businesses conducted quarterly or annual deployments. Flickr established a one-step environment design-and-deploy approach by collaborating with the company and adopting the Second Way's principles, resulting in 10 daily deployments! That's a thousand times faster than any of its competitors.


Today, that figure is significantly higher. Amazon, Netflix, and Google are just a handful of the enterprises that have adopted DevOps procedures and cultural practices. They can release thousands of production changes daily, maintaining remarkable stability and Security.



7. The Third Way entails cultivating a culture of continuous experimentation, failure, and Development.


Bill is looking at his bright new laptop. His applications and data are all present, his email is operational, and every component is intact; it works flawlessly. If Bill's previous laptop represented all that was wrong with Parts Unlimited, his new laptop reflects everything his team has done together over the last few months.


SEV1 outages have been reduced by two-thirds, with incident recovery time lowered in half. The ticketing system has been cleared of needless tasks. A consistent environment generation process, often known as a build method, is in place to keep Development and Operations in sync and eliminate variance.


Developers collaborate with Security to construct preventive projects rather than safeguard things after release. They've appeased the auditors while reducing security-related work by 75 percent, allowing efforts to be directed elsewhere.


All of this indicates that the project flow has accelerated. Phoenix is running smoothly. People understand their responsibilities; they feel content and happy because they can execute their work. And, thanks to the Third Way, they are innovating more than ever.


The main lesson here is that the Third Way fosters a culture of continuous experimentation, failure, and Development.


According to the Third Way, you're getting worse if you're not improving. There are three components to this. The first involves experimentation. To outperform competitors, you must out-experiment them. Therefore, it is critical to foster innovation and risk-taking.


Parts has a new project called "Unicorn," which focuses on innovation. Using data and environments copied from Phoenix, engineers created an identical but completely separate database to continuously develop and test customer-targeted promotions without disrupting the live application.


The second part is about failure. To that goal, Parts established the "Simian Army Chaos Monkey" project. What is its task? Create severe bugs that can kill processes or entire servers. At first, there was chaos; the test infrastructure continually crashed. However, when Development and IT Operations collaborated to improve the code and infrastructure, IT services grew more resilient to failure.


The third factor is prioritizing improving everyday work over daily work. Every two weeks, all managers at Parts must improve something—anything. These so-called improvement kata cycles put the system under constant pressure, forcing it to advance.


In martial arts, kata is the practice of a pattern until it becomes second nature. Habits lead to mastery. According to studies, five minutes of daily practice is more effective than three hours once a week; the more regularly a habit is exercised, the better.


It is more than just a department in today's technologically advanced world. It is a skill similar to the ability to read and write. Business managers must be able to take measured risks to outperform competition. The entire organization benefits when business and IT recognize they are essentially intertwined and adopt DevOps ideas and practices.



Final Summary


In today's technology-driven world, the IT department is frequently the backbone of a corporation. So when communication and workflow between the Development and IT Operations teams are misaligned, the consequences reach all the way to the top. However, internal chaos does not have to be the norm. DevOps is a unified IT approach based on the "Three Ways." These business concepts prioritize fast feedback loops, efficient communication, and a culture of experimentation, repetition, and practice. Using these practices may propel your IT organization and the entire company to new heights.



Create a personalized kanban board.


Kanban boards can promote efficiency on a more personal level by assisting you in committing to the appropriate amount of work and visualizing your progress. So ditch the comprehensive, contextual to-do lists in favor of a blank wall and some Post-its. Divide the job you need to accomplish into three columns: ready, doing, and completed. Limit your work in progress to four or five items at a time, then get going! As you continue, those cards will shift from left to right, and you will reach your objectives faster than ever before.

Book Summary

Post a Comment

Previous Post Next Post