phoenix project book review

Register for Simple Talk

Get the latest Opinion, Podcasts, Webinars, and Events, delivered straight to your inbox.

Book Review: The Phoenix Project

Share to social media

DevOps, Continuous Delivery & Database Lifecycle Management Culture and Organization

As often found in novels, there are a number of characters to keep track of. To help follow the review, we have bolded the character’s name when first mentioned.

A Brief Synopsis

This is mainly because the future of the company appears to hang almost entirely on Project Phoenix. The political storm brewing behind the project, led by Sarah the marketing manager, adds further tension. Faced with the conflict of Project Phoenix requirements against firefighting and competing projects, Bill and his team enter a spiral of problems, mistakes, gloom and despair. Thanks to a growing insight into Lean, Agile and DevOps concepts, Bill and his team gradually evolve their way of working. By the time Project Unicorn arrives later in the story, they’re able to release and support the project reliably, efficiently, and emerge with strengthening morale out the other side.

A Confession

I’m not an IT practitioner. I’m from the “dark side”, or at least the same one as the irrepressible plotter and marketing manager Sarah. So why did I want to read a novel about IT and DevOps? For one thing, I’ve worked with various technology companies and I was curious to find out more about concepts I’ve seen developing. I’m also part of a research group in the database lifecycle management team at Red Gate and I wanted to better understand how Agile and DevOps work out in a deeper context. If you’ve read about Sarah’s Machiavellian tendencies, you’ll know that the book wouldn’t make comfortable reading for anyone in marketing.

I hope my admission of sharing the same profession won’t put you off reading further, if only because I feel that the book also encourages us to look beyond preconceptions of teams and roles in an effort to persuade us to work much more openly across an organi zation . This level of communicating, cooperating and, sometimes, making compromises together to solve IT and business challenges completely bypasses Sarah, but other characters in the novel get it.

IT Becomes an Organization-Wide Capability

In the book’s message of business and IT teams working better together on IT projects, the authors also draw out practical examples of ways of working that, in my opinion, are useful parallels for professions beyond IT. For one thing, I’ve been thinking differently about WIP (work in progress) on my Kanban board of activities ever since.

At both the detailed level of insight into leaner, more efficient ways of working and at the wider level of an organization evolving its approach towards IT, I believe everyone with an IT requirement has something to gain from reading The Phoenix Project. It’s true that there’s a fair amount of technical detail on the challenges that the IT team face, which may be daunting for some business team readers. It’s also true that the novel describes a big adjustment in behaviour and ways of working between the development and operations teams specifically, and it’s this that lays many of the foundations for better collaboration.

But it’s when both the IT and business arms of Parts Unlimited reconsider their biases, share responsibility and better understand each other’s challenges (yes, that also means the business teams working harder to understand the technical risks facing the organization) that the cogs become better oiled. That’s not in any way to suggest that sales, marketing, finance, and other business teams are somehow the secret sauce in the success of IT. They’re not . The point is that in the book we see IT growing from an isolated function to an integral capability across the organization, and everyone has a shared part to play in this.

Overturning Preconceptions

I’ve spoken with others about The Phoenix Project and the way it puts the DevOps philosophy into sharp definition. Yes, it’s a novel about this and other IT themes – and for some this seems to raise an eyebrow at first – but those I’ve spoken with agree that its status as a novel doesn’t translate into “DevOps lite”. W. Edwards Deming’s manufacturing philosophies, in addition to Lean and Agile development methodologies, feature heavily; concepts that sit at the roots of the DevOps philosophy.

In essence, the authors of the novel – Kevin Behr, Gene Kim, and George Spafford – have written a DevOps parable, and strive to make it recognisable at every turn of the page. Indeed, having all worked in organizations of varying sizes, maturity and sectors, they’ve also taken pains to place characters in an easily identifiable setting, and embrace the human elements of the story. So, quite apart from the technical challenges (such as the hauntingly familiar server outages and lagging database performance), you’ll find certain home truths: donuts sweeten meetings and pizza sustains chaotic all-nighters. The evolution Bill and his team undergo is pretty amazing – but then this is also DevOps in fast motion. Like many novels, it takes the reader on an unrelenting journey with the underdog, Bill, as he is thrown into battle, meets a (sort of) wizard also known as Erik , and finally triumphs with the organization at his side.

The setting, the IT challenges and the characters at times feel caricatured, but to dwell on the realism of this journey and its existence as a novel for too long feels like it risks missing two of the other key points of the book – that this is a parable with an enterprising spirit at its heart. Via the medium of fiction based on reality, it unconventionally presents DevOps concepts, and it feels like it also wants to dare the reader to be open-minded. Being a fictionalised depiction, it’s easy for the book to ask you to consider turning accepted practices and attitudes on their head in the search for progress.

Evolution Rather than Transformation

In the movement of IT from an isolated function to a central capability – both metaphorically and physically, almost all teams are challenged to look beyond their department walls.

This isn’t just about the dev and ops teams turning around an unhealthy relationship that’s damaged by (a) what Jez Humble would perhaps describe as ‘risk management theatre ‘ and, (b) throwing, as one character describes it, “the pig over the wall” for the next team to tackle. This is also about an evolution of attitudes and approaches across the business.

In the book, Bill tries a range of processes to bring his dev and ops teams closer together, including the use of Kanban boards to prioritize and manage work. As these efforts bring results, he and his teams’ focus starts to shift to the rest of the organization. In fact, one of the book’s surprises is the transformation of the CISO, John , outcast and ‘political commissar’, into a team member who is instrumental in bringing the business teams and organization objectives closer to IT. As Deming would describe it, John is essential in helping the various teams gain ‘an appreciation for the system’ that IT works within.

DevOps Across the Organization

For me, John’s series of actions at his point of transformation also raises one of the most important practical examples in the book of DevOps reaching throughout the organization.

Bill and John meet with managers in the business teams, from sales to finance, to understand performance measures across the organization, how they rely on IT, and the business risks IT brings for each measure. At first this approach feels worryingly like we’re headed down a one-way street. Several business team members, for example, are antagonistic towards the open approach Bill and his IT co-workers encourage.

Yet by the end of the book Maggie , part of the business team in charge of promotions and pricing roadmaps, is attending stand-ups for the IT project linked to her objectives. She’s even demoing results to the team at the sprint retrospective in the kind of cross-functional approach to projects that really sings when everyone has a shared goal. There’s a sense of energy in the team again, similar to the kind of morale Steve Thair talks about when comparing one of the tenets of DevOps with the satisfaction of craftsmanship.

Early Feedback Loop

This approach of shared responsibility and ensuring projects are clearly linked with the organization’s objectives also highlights another interesting DevOps message in the book – that an early feedback loop in the lifecycle, involving all stakeholders and project members, feeds efficiency and quality.

As Bill and his team adopt a more Agile approach to prioritizing their backlog of projects and gathering requirements, they avoid the shifting goalposts of requirements and timelines that they suffer earlier in the story when releasing Project Phoenix.

Automate (What You Can) and Review

By the time Project Unicorn arrives, Bill and his team are ready to run shorter, iterative development lifecycles that mean they can identify issues earlier, get results out to the business, and move WIP off the line sooner. They also set in place a series of automated practices to standardize deployment processes and build up a release pipeline that eliminates the majority of variance that caused the teams grief previously. Cycle times shorten and any fixes can be developed, tested, reviewed and released much quicker than they were with Project Phoenix.

Quite beyond being a series of examples for how to run an IT project with Agile and DevOps practices, this is also a lesson generally in PDCA (Plan, Do, Check Act) . Essentially, larger projects run better when:

• they’re broken down into manageable chunks
• we make the effort to check back with others across different teams,
• we check results,
• we make adjustments to the project as needed,
• we learn how to standardize (even automate processes for repeatability and greater accuracy if possible), improve for next time, and communicate that experience.

Avoiding Isolation

This willingness to open up a project much earlier for feedback touches on another example of DevOps in the book that also carries parallels for the wider organization. In the closing chapters of the book, John’s security team works closely with the development team, integrating security tests into the build procedures, testing and reviewing them earlier in the cycle. As a result, we see a radical shift in approach from earlier chapters, when John and his team were viewed as a disruption to be avoided.

As John and his team make efforts to integrate with other teams, they even start to use the same testing process that the QA team uses. For me, this example of the teams’ turnaround in approach and results comes very close to the point David Poole makes in his article on developer and DBA relations when he discusses the idea that ‘functional silos create more problems than they solve.’

As the security and QA teams open themselves up jointly to the potential of exposing errors, so they have a greater ability to resolve any issues found head on. John no longer needs to parachute in at the last minute with his dreaded black ringbinder of problems to register project shortcomings. Fundamentally, John’s team are no longer ‘special’ or exempt from agreed practices, nor are they isolated and overspecialized in their own departmental universe.

Concluding Thoughts

At its most raw, this book can easily feel like a lesson in humility. It’s not the case that at the end of the book, DevOps and Agile approaches to working have magically evaporated all the challenges facing Parts Unlimited. Conflict, incidents and mistakes are inevitable – what counts is how Bill and other team members grow to manage and resolve them . By the end of the book, Bill, his team, and Parts Unlimited have structure, process, and a more open attitude to change and adaptation to stand them in good stead.

At its most practical, The Phoenix Project is an illustrative series of examples and suggestions for ways to evolve IT from a function that’s viewed as a bottleneck to one that’s widely agreed to be an indispensable capability. And at both levels, The Phoenix Project makes it clear – DevOps includes the wider organization, and the wider organization can learn a lot from DevOps.

DevOps, Continuous Delivery & Database Lifecycle Management Go to the Simple Talk library to find more articles, or visit www.red-gate.com/solutions for more information on the benefits of extending DevOps practices to SQL Server databases.

Load comments

Recommended for you

Why Every Project Needs a CI/CD Pipeline No Matter How Small

Have you ever experienced a scenario as a developer when a seemingly simple weekend bug fix throws your entire project...

Business value of lean software development and DevOps

Lean software development means delivering applications efficiently and fast. Robert Sheldon discussions the business value of lean software development. …

Ten tips for building a collaborative DevOps culture

There is more to DevOps than tools and automation. In this article, Robert Sheldon explains how to create a DevOps...

About the author

Claire Brooking

Claire is part of the database lifecycle management team at Red Gate, researching continuous delivery, DevOps and working with others in the community on a learning program for database delivery. Claire can also be found on twitter @Claire_Brooking .

Claire Brooking's contributions

• T-SQL Programming
• Database Administration

Claire Brooking's latest contributions:

In search of database delivery practitioners and enthusiasts.

We know from speaking with many of you at tradeshows and user groups that database delivery is not a factory production line. During planning, evaluation,...

Free eBook with SQL Server performance tips and nuggets

I’ve often found that the kind of tips that turn out to be helpful are the ones that encourage me to make a small step...

The Simple-Talk Cookbook

Written by geeks, for geeks, the Simple-Talk Cookbook is a quirky culinary collection of recipes by SQL Server and .NET MVPs and experts, who would...

• Project management

The Phoenix Project

• TechTarget Contributor

The Phoenix Project is a best-selling novel about DevOps . The book's characters reveal through their actions why it's so important for organizations to put security first and tear down the silos that have traditionally existed between development and operations teams. The Phoenix Project’s subtitle is "A Novel About IT, DevOps, and Helping Your Business Win." The book, which was written collaboratively by Gene Kim, George Spafford and Kevin Behr, is widely regarded as the DevOps "bible." 

Apart from being a rare genre of literature (a work of fiction about IT), The Phoenix Project is often used as a guide for helping IT managers change the way employees think about the way they plan, schedule and complete work. The book introduces concrete strategies for building a DevOps culture to improve organizational agility and shares technical information in a way that's very easy to understand. A downloadable PDF excerpt from the book   is available from the publisher, IT Revolution Press. 

The Phoenix Project was inspired by Eliyahu M. Goldratt's seminal business book, " The Goal: A Process of Ongoing Improvement ." Like The Phoenix Project, The Goal also uses a narrative approach. Both books teach the reader about the importance of breaking down silos at the organizational level in order to  identify and manage constraints  that negatively affect production. Both books also teach the value of building collaborative corporate cultures and use relatable characters to illustrate why fostering a  blameless organizational culture is so important.

The protagonist of The Phoenix Project is Bill Palmer, the director of IT operations for a large auto parts company that has both manufacturing and retail business divisions. When the company's stock suddenly goes down, Bill finds himself promoted to Vice President of Operations and is tasked with rolling out an important business initiative called the Phoenix Project.

Historically, a phoenix is a creature from Greek mythology that is commonly used as a metaphor for rebirth. In this book, the Phoenix is a complicated waterfall software development project that is viewed as a major 'project management fail' by the press. 

Bill is tasked with moving the project out of development and into production in a matter of weeks. When Bill takes over, it's with the knowledge that if the Phoenix release is not successful, there's a strong chance the company will be split up and the IT department's work will be outsourced.

Book review

The Phoenix Project has reached #1 bestseller in its related categories on Amazon several times over the years. The novel has appeared in countless  What Corporate America is Reading  lists since its release and has been called a must-read for anyone working in IT.

The book's novel format (pun intended) allows rather dry information to be explained in context through character-driven conversations. While the strategies Bill's team learns for managing change are useful, it's really the interpersonal conflicts in the book that keep the reader's interest.

Readers will recognize a lot of the imaginary characters in the book from their real-life workplace counterparts. That's part of what makes this book so fun to read. 

Over the years, the Phoenix Project has received criticism for being a fairy tale that oversimplifies the way change typically occurs in a corporate culture. Proponents of the book are quick to point out that the book is not meant to be a case study, and the WhatIs.com team agrees.

We loved this book and recommend it as an excellent teaching tool for anyone who wants to understand how their IT department works. This includes those employees who actually work in IT -- as well as the line of business ( LOB ) folks who rely on IT services to do their work. 

We knew from past experience that the Phoenix Project's original hardcover edition is perfect for self-guided, individual study. What hit home during the pandemic, however, is that the book's Kindle and Audible versions are also an inexpensive (but extremely valuable) vehicle for staff development.

Editor's note: This is one of those rare business books that benefits from being re-read periodically. There's a lot of information packed in this story -- and as with all good books, it's likely the reader will gain new insights with each reading. BTW, Gene Kim's follow-up book is entitled  The Unicorn Project . It retells the same story from a developer's point of view, and it brilliantly uses many of the same characters to create continuity and allow for even more complex technical  information to quickly be shared in an entertaining manner.

Using this book for staff development

During the recent pandemic lockdown, it was challenging for WhatIs.com writers to stay close to our audience but this book helped fill the gap. We started out by reading a new chapter of The Phoenix Project each workday and met for 15 minutes each day after our daily status meetings on Microsoft Teams to discuss what we learned.

Before the end of the first week, it was crystal clear that our "virtual book club" minutes were a valuable use of time. In fact, the book club quickly became everyone's favorite part of the day. What we discovered was that even though the book is marketed towards audience members who want to learn about DevOps , the book is actually a great learning tool for any team that is responsible for producing work of any type.

Take the WhatIs.com production team, for example.  We produce learning content, not software applications, but it turns out we have a lot of the same pain points as the characters in the Phoenix Project. We decided to mirror how the book characters used kanban  to manage workflow and tried out the Microsoft Teams Planner app to see if kanban helped us manage our own production workflow.  (Spoiler alert: It did!) 

Just like Bill's team in the book, we also reached out to ask colleagues from various business silos within our organization what a good day looks like and what a bad day looks like.

The Phoenix Project Pandemic Book Club

Reading this book together, as a team, reinforced the value of  failing fast and experimenting with new ways to meet business goals. And just like Bill's team in the book -- we continually learned more about the competing priorities and unknown dependencies in our own company. This led us to the idea of creating a podcast by recording the virtual book club sessions we ran during the pandemic and posting a transcript to go with it . The first two recordings are posted below as videos.

Book Club discussion: Chapters 1 and 2

Book club discussion: Chapters 3 and 4

Book club discussion: Chapters 5, 6 & 7

Professional development resources

When reading the book, WhatIs.com team members began to take notes and share them in a Teams wiki that turned into a Lessons Learned from reading The Phoenix Project article.

Another team member volunteered to keep track of the book's characters as they were introduced. And someone else volunteered to create chapter summaries that could function as SparkNotes or CliffNotes for the book. 

Another team member volunteered to create a glossary and keep track of terms mentioned in the book that we should update or add as new definitions and it wasn't long before it became clear that if we found these resources to be useful, someone else might too.

Right now we are gathering the resources our self-directed team created and preparing them for publication. Please reach out to mrouse @ techtarget.com if you'd like to share ideas for how to use The Phoenix Project to train new employees, build a DevOps culture that encourages self-directed learning or simply join our virtual book club!  

Continue Reading About The Phoenix Project

• What the DevOps movement has done for -- and to -- developers
• If 'The Phoenix Project' inspired you to adopt DevOps, 'The DevOps Handbook' is here to guide you through the complex process.
• Gene Kim Q&A: DevOps transformation is not just for devs and unicorns
• IT Revolution Press' page for The Phoenix Project
• Top 15 DevOps blogs to read and follow

Related Terms

A URL (Uniform Resource Locator) is a unique identifier used to locate a resource on the internet.

File Transfer Protocol (FTP) is a network protocol for transmitting files between computers over TCP/IP connections.

A virtual private network (VPN) is a service that creates a safe, encrypted online connection.

Cloud computing requires a security approach that is different than traditional protections. Where does cloud detection and ...

An endpoint protection platform (EPP) is a security technology that safeguards endpoint devices.

Endpoint security is the protection of endpoint devices against cybersecurity threats.

Data monetization is the process of measuring the economic benefit of corporate data.

C-level, also called the C-suite, is a term used to describe high-ranking executive titles in an organization.

Value-sensitive design is a concept that advocates the consideration of human principles and standards when planning technology.

Employee self-service (ESS) is a widely used human resources technology that enables employees to perform many job-related ...

Diversity, equity and inclusion is a term used to describe policies and programs that promote the representation and ...

Payroll software automates the process of paying salaried, hourly and contingent employees.

Customer segmentation is the practice of dividing a customer base into groups of individuals that have similar characteristics ...

Customer experience (CX) is the sum total of customers' perceptions and feelings resulting from interactions with a brand's ...

A buyer persona is a composite representation of a specific type of customer in a market segment.

Filter by Keywords

Book Summaries

The phoenix project summary: how solid devops principles can transform business projects.

Sudarshan Somanathan

Head of Content

February 28, 2024

Start using ClickUp today

• Manage all your work in one place
• Collaborate with your team
• Use ClickUp for FREE—forever

Failure can happen to even the best of companies—it’s how they bounce back that matters.

The book The Phoenix Project follows the journey of a fictional company struggling with delays, unplanned work, and fewer resources. It also showcases its return to profitability thanks to revamped IT operations.

The company leverages the best DevOps principles to discover optimal ways to plan, execute, and improve processes within the IT department. All this culminates in the company’s remarkable resurgence in the style of the mythical phoenix. 🔥

While you should read the book to grasp all of its merits, this The Phoenix Project summary will highlight some of its most noteworthy lessons. We’ll dive into the plot, the main takeaways, standout quotes, and tips for applying the book’s concepts in real life.

1. Identify the four types of (IT) work 

2. limit work in process or progress (wip), 3. leverage kanban boards, 4. manage changes with the theory of constraints, 5. optimize the deployment pipeline, 6. use the three ways model to power devops, there is no limit to what can be accomplished when nobody cares about who gets the credit, a process is only as fast as its slowest bottleneck, it doesn’t matter how much we plan. what matters is how well we refine the plan as new information arises, there is no secret that will allow you to skip the hard work, a smooth sea never made a skilled sailor, 1. set up optimized workflows with task management and scheduling tools, 2. build situational awareness by monitoring sprints and other it operations, 3. win with continuous collaboration and feedback.

Book Summary: The Phoenix Project at a Glance

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win is written by Gene Kim, Kevin Behr, and George Spafford. This 432-page book was first published in 2013 and takes about 7–10 hours to read.

What we adore about The Phoenix Project is that it uses relatable characters and business scenarios to define the common problems in IT operations and delivery, all while steering the reader toward solutions that work. It’s also a must-read if you’re looking to unravel the relationship between manufacturing plant operations and IT. 🍀

This business and information technology book relies on expert novelization to present the battle-tested concepts of DevOps in an easy-to-follow manner .

The story’s main protagonist is Bill Palmer, a newly appointed Vice President of Information Technology working for an automotive parts manufacturing company, Parts Unlimited. Even as an experienced IT director, Bill has a difficult task ahead of him— to prevent the company from going under .

So, what went wrong?

For starters, the entire organization is plagued with problems—from payroll failures and scheduling delays to budget overruns. A lot of these failures are related to the company’s misguided IT department and, particularly, the team’s inability to complete a vital software development initiative, the titular Phoenix Project .

The issues had permeated other business functions, and Bill is left to pick things up after setbacks like security breaches and violations of state regulations. And if he fails and the company continues losing its market share, the CEO of Parts Unlimited plans to outsource IT operations. So yes, the stakes are high. 🌋

Throughout his efforts to revamp the IT department and, by extension, the entire company, Bill collaborates with several departmental and tech leads. Some central roles include:

• Brent Geller: Lead Engineer
• Steve Masters: Chief Executive Officer (CEO)
• John Pesche: Chief Information Security Officer (CISO)
• Wes Davis: Director of Distributed Technology Operations
• Sarah Moulton: Senior Vice President of Retail Operations
• Chris Allers: Vice President of Application Development
• Kirsten Fingle: The levelheaded leader of the Project Management Office (PMO)
• Dr. Erik Reid: A potential board member and IT process engineering expert

Among the characters listed above, Erik stands out as one of the narrative’s most influential figures. As Bill Palmer and his coworkers try to mend what’s broken, Erik guides them through the process, introducing them to crucial concepts of DevOps and IT governance . If you have worked in software development or IT operations, you’ll likely find the interactions between the characters pretty familiar.

Key Takeaways from The Phoenix Project

The challenges this book presents are quite common if you look at what most software developers and IT professionals deal with today. Since the three co-authors of The Phoenix Project are prominent thought leaders in the IT industry, they’re able to pinpoint effective strategies to address these challenges, helping your business win in the long run. 🧑‍💻

Let’s discuss five of the most impactful lessons and takeaways from this book.

Erik explains that it’s easier to plan and monitor work in IT when you categorize it into four divisions:

• Business projects : This type of work includes new project initiatives and processes that take up a massive chunk of your business functions. They are individually monitored by the Project Management Office under a program governance framework
• Internal projects : These include regular tasks, such as system maintenance, upgrades, and security patches, that keep companies like Parts Unlimited running
• Changes : These are routine tasks, much like internal projects, but include small-scale modifications like bug fixes and version updates. Typically, you have to establish a ticketing system to track issues, changes, and resolution
• Unplanned work : While the other categories of work are agreed upon beforehand, this one isn’t. It can be anything from recovery tasks after a system failure to extra work because a team member failed to communicate issues on time. This leads to scheduling conflicts and process inefficiencies , which snowball into more significant issues. To prevent unplanned work, Bill and his team agree to review team capacity before approving work on change requests

This multi-level work-based monitoring system ensures there’s a proper accountability flow that the team can rely on.

According to the book, you should have as few ongoing tasks as possible at a time. 

Bill finds that when your attention is split across multiple tasks, you’re overwhelmed and prone to making errors due to scattered focus. The more mistakes you make, the more effort and company resources you invest toward resolution. Since the original work wasn’t fruitful, it will be considered a waste of resources that could’ve been employed toward new tasks.

The book recommends aligning your strategies with agile or Lean methodologies to ensure your planned tasks are resource-optimized.

Bonus read: Expand your knowledge with our guides for:

• Agile project management
• Lean project management

One of the ways Bill Palmer and his team were able to overcome WIP build-up for Parts Unlimited is with Kanban boards . Kanban, which means “ signboard ” in Japanese, allows the team to visualize work. The board is divided into columns depicting the phases of the workflow, typically moving from left to right. Each task is represented by a card.

In the book, Bill’s team builds a Kanban board with the tags Ready , Doing (for WIP tasks), and Done . Each card has an assignee and is placed on the left side of the board. It’s repositioned to the right as the work progresses. With such a system, all work is monitored, organized, and prioritized to maximize productivity , enabling complete visibility of team tasks and minimizing unplanned work.

Pro tip: Use the Board view in ClickUp to build scalable and informative Kanban boards. Create multi-step workflows in a few clicks and access statuses, assignees, and priorities in one view. You can easily drag and drop tasks across columns and even use the built-in toolbar to make bulk status updates. 💪

Erik informs Bill about how the Theory of Constraints plays into large organizations. Most businesses have bottlenecks or constraints within their IT and plant operations that can be disruptive and lead to unplanned work. Erik explains that to provide a stable, predictable, and secure IT service , you must plan your human or non-human resources to address these constraints and facilitate an uninterrupted workflow.

In the case of Parts Unlimited, the impact of its many constraints hit Brent, the lead operations engineer and an IT prodigy. Brent was neck-deep in unplanned work, usually trivialities and fixes, which caused crucial planned tasks to suffer.

To solve this problem, Bill formed a group that would deal with escalations instead of Brent. Moreover, Brent, who had previously kept his methods to himself, would now train the group to transfer his knowledge. This allowed the team to map out the process for future reference and freed up Brent’s time (or, as Bill says— freed up Brent from firefighting ) so he could invest his expertise into higher-value tasks.

Bonus: Try the ClickUp Processes Map Whiteboard Template to visualize bottlenecks and build a foolproof inter-departmental workflow aligned with the Theory of Constraints.

The Phoenix Project was date-driven, so there was little time to test and deploy the application. 

However, throughout the book, Bill’s team became more efficient and pumped out more releases than in the previous quarter. This was partly due to their new approach of delivering smaller bits of work more frequently , reducing WIP and buffer time without taking outrageous shortcuts.

Erik’s coaching revolves around The Three Ways model, which is the basis of many DevOps concepts. The model offers guidelines for companies to provide consistent product value and customer service support through steady, efficient, and high-quality work.

The First Way: Optimization

When assessing a company’s success, we evaluate the outcome, not the process. The First Way explores how the process affects the outcome and the delivery times. To maximize your profitability, you should optimize your value stream , i.e., the flow of work that starts with software development and ends with delivery to the customer. 

According to the book, it’s essential to consider the bigger picture when creating an optimization plan. What are the main business objectives ? What type of regulatory compliance and security standards should you never compromise on?

Keeping up with technological advancements is also important. For example, exploring new software like AI DevOps , scheduling-friendly Gantt Chart makers , and IT operations management tools can generously speed up planning and production.

The Second Way: Using a feedback loop to avoid rework

The Second Way deals with the internal flow of information. With fast and constant feedback loops, companies can learn to detect quality issues at the source and fix them promptly to ensure they don’t impact the production line further. Problems noticed in the later stages will be trickier to resolve and will cause significant delays. ⚠️

The Third Way: Continuous improvement and service support

The Third Way talks about continuous improvement, which occurs as a result of the following:

• Learning by scrutinizing past experiences
• Practicing a skill repeatedly —according to Erik, it’s better to practice five minutes every day than three hours once a week. Even the repetition of mistakes helps build resilience and confidence to try something new
• Taking risks and experimenting with different methods, DevOps tools , and other customer support strategies, you can reach never-before-seen levels of efficiency and quality

The Phoenix Project Quotes That We Love

The Phoenix Project is a highly quotable book, but these five excerpts stuck with us the most:

This quote points out that we can achieve remarkable results by setting aside personal gain and focusing on collaboration. Without the pressure to be the best, team creativity and knowledge can shine through. ⛅

From the perspective of constraints, underperformance at one stage can hinder the whole process, even if the rest of the stages run fine.

Our planning efforts will be futile if we don’t adapt to ongoing challenges, which are inevitable. The same goes for favorable developments. They represent opportunities to achieve even greater outcomes.

Sometimes, efficiency looks like finding shortcuts and eliminating steps of the process that aren’t necessary. The actual grind and determination can’t be skimped on if you want to succeed, though. 

Although they can be frustrating and slow you down, mistakes and challenges help build resilience and contribute to personal and professional growth. 🌱

Apply The Phoenix Project Learnings with ClickUp

The DevOps lessons in this book form the bedrock of operations for any IT team. Still, the million-dollar question is: How do we adopt these teachings from a practical viewpoint?

The answer is by using ClickUp —a project management hub with tailored solutions for software teams. Whether you want to implement The Three Ways of DevOps or establish a WIP monitoring system, ClickUp is highly flexible and can be configured to support any workflow.

ClickUp offers numerous features specifically crafted for software development and operations teams. It also integrates with many of your go-to tools, such as GitHub, GitLab, and Bitbucket, so you can plan, collaborate on, and execute tasks productively from one centralized platform.

With ClickUp, the principles from The Phoenix Project can easily become a part of your daily routine—let’s explore how.

In his journey to get Parts Unlimited back on track, Bill Palmer goes out of his way to implement the best DevOps task planning and management practices. But with ClickUp, any scheduling and workflow planning task is effortless.

Use ClickUp Tasks to customize workflows for all your projects—track assignees, subtasks, task comments, dependencies, and priority labels, all from one place. The platform offers multiple visualization options through views . For example:

• Gantt Chart view : Create intricate roadmaps toward goals and limit WIP by getting a real-time overview of dependencies, delivery milestones, and constraints. You can also jump on pre-designed Gantt Chart templates to map out project timelines faster
• Calendar view : A drag-and-drop scheduler for date-driven projects
• Workload view : Use it to assess team capacity and redistribute creative or backlog workload among underworked and overworked team members
• Form view : Collect bug and feature requests using native ClickUp forms and quickly transform them into actual tasks with tags and priority labels

For further efficiency, automate repetitive and admin actions with ClickUp Automations and reduce your team’s busy work.

After setting up workflows, you can closely monitor all your operations on ClickUp—from sprints and deployment tasks to raw materials and requests. With Sprints in ClickUp , you can:

• Copy Sprint views to get started quickly
• Set dates and customize your point structure
• Sync your team’s work with Git repositories
• Automatically transfer incomplete tasks into the next Sprint

The platform features burnup, burndown, and cumulative flow charts to help you track progress toward goals and identify constraints and improvement opportunities faster.

ClickUp simplifies release management with its integrated Git pipeline, go-live checklists, and release trains. You can also set up Dashboard cards in your Workspace to access live team metrics like average deployment duration and time tracked.

In the book, Erik explains the importance of being transparent with teams about developments that impact the wait time or delivery date. Luckily, ClickUp offers a whole set of communication and collaboration tools to support you here. Some of the standout features include:

• ClickUp Docs to store all product requirements, feedback, rework history, and process documentation in one place
• ClickUp AI serves as an AI writing assistant, as well as a neural network connecting your Tasks, Docs, and People
• Assigned Comments , Proofing, and Chat view for updates, internal communication , handoffs, and high-speed feedback cycles
• Custom Fields to add information about new bugs and feature updates
• ClickUp Whiteboards and Mind Maps for brainstorming and process mapping

Don’t know where to start? Take advantage of the platform’s numerous ready-made templates for various business objectives. Options like the ClickUp Ultimate Software Development Template , ClickUp Bug and Issue Tracking Template , and ClickUp Release Notes Template are staples for any IT department.

Reap the Benefits of DevOps and Score Your Next Business Win with ClickUp

The Phoenix Project teaches us that it’s possible to aim for efficiency, product quality, and client satisfaction all at the same time. By applying the principles from the book with a top-rated work management solution like ClickUp, your business can not only steer successful release plans but also satisfy stakeholders.

Try ClickUp for free and discover all the ways it can streamline your IT operations and boost team productivity. ⬆️

Questions? Comments? Visit our Help Center for support.

Receive the latest WriteClick Newsletter updates.

Thanks for subscribing to our blog!

Please enter a valid email

• Free training & 24-hour support
• Serious about security & privacy
• 99.99% uptime the last 12 months

Gregg Borodaty

Software developer by day baker, writer, software developer by night.

Book review: The Phoenix Project

The story within The Phoenix Project is OK, but not very strong. To put it bluntly, you’re won’t want to read it because of the plot. In it, the main character Bill Palmer is thrust into the role of VP of IT Operations after a reorganization at struggling auto parts company Parts Unlimited. The problems at Parts Unlimited are largely related to software development and deployment, and it’s Bill job to fix them before the Board forces a break-up or sale of the company.

The story begins with a seemingly endless string of software disasters. I understand that the authors create the large number of disasters in order to illustrate how to fix them, but it stretches your imagination to think things could be THAT bad. It just seems like Bill can’t catch a break until a business consultant who is considering a board role, Erik Reid, comes in to help Bill out of his predicament. Erik shows Bill how to apply concepts of lean manufacturing to software to improve the process. At this point, the book feels a lot like The Goal applied to software rather than manufacturing. However, I found the story surrounding The Goal to be a bit stronger than the one intertwined with The Phoenix Project.

As for the concepts, there are some great takeaways from the book. For example, I really like the way that they compare the development of software to manufacturing and use the Theory of Constraints concepts to run development. The book covers finding bottlenecks in your development process and how to smooth out the flow of work through the IT organization. It also spends a lot of time dealing with the flow of work and communication between development and operations (deployment) and how to optimize it.

Unfortunately, while the book covers a lot of great concepts, I felt that it was a little light on depth when it came to implementation. There are certain concepts covered that are applied between chapters with little explanation about how it was implemented. Also, the book definitely caters to a larger organization that contains larger development, IT and operations teams. I’m not saying that the concepts can’t be applied to smaller teams or start-ups, it’s just not as clear as to how these would get implemented on a much smaller scale.

Having said all of this, I’d still give The Phoenix Project strong marks overall. While I wouldn’t put it in my must read category , I’d highly recommend it to anyone who is in the software development field, particularly if you are managing the development and deployment of code. If you’re not in the field of managing software development and deployment, then you’ll want to pass on this book. The story is not strong enough to stand on its own.

By the way, if you are interested in learning more about the concepts behind the book, you should check out the DevOps blog on the  IT Revolution website . There are a number of articles that go into more depth about concepts in the book as well as a link to additional resources for further reading . If you’re not sure you want to read the book, I’d suggest checking out the site first to get a feel for what The Phoenix Project covers.

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Book review: The Phoenix Project

The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford has been out for about 10 years now, and most people I’ve spoken to about it have read it. I, however, have just gotten around to reading it, after it was recommended to me quite some time ago by Huw Bristow .

The sub-title of the book is

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

This is an accurate summation, but it also does the book an injustice. DevOps is ubiquitous now, but when the book was first published it wasn’t as well-established a discipline, and many IT organisations (internal and external) suffered the pain of rigid, Waterfall style project management (rather than product management), and the friction between operations (governed predominantly through ITIL) and development - and, in many ways, the rest of the business, or clients - was a constant source of stress. In many organisations this is still true.

The book has an interesting and unique style; it’s told from a first-person perspective, but also in present tense. The story progresses through a high-stress and high-stakes scenario, and this approach helps lend a sense of immediacy and urgency to the narrative.

The purpose of the book was to evangelise the discipline of DevOps and help business understand how it can lead to lower stress and increased value through automation, allowing workers to focus on important tasks. But it does a lot more than this - it also espouses the relevance and value of management theory and principles originating in the automotive industry for IT and development teams and organisations.

In this review, I’ll look at the core lessons from the book in terms of management principles, and then give my overall impression and takeaways.

This review contains minor spoilers. If you haven’t read the book and are intending to, I think it’s unlikely these would impact you, but it seems fair to provide warning.

Management Principles

One of the key inspirations for the book is The Goal by Eliyahu M. Goldratt and Jeff Cox. Like The Phoenix Project , The Goal is a novel that is used to convey a management principle; in this case, Goldratt’s theory of constraints . Originally published in 1984, it illustrates the principle that all work in the pipeline is dictated by a single constraint or bottleneck. I haven’t read this book yet, but it’s now on my list.

Another key inspiration for the book are the Lean Manufacturing Principles originating in the Toyota Production System . In the book, the protagonist Bill Palmer encounters a mentor called Erik, who coaches Bill through his struggles in his now role as VP of IT Operations at Parts Unlimited, a fictional (yet all-too-real feeling, as we will see) automotive parts manufacturer (and retailer, one of the sources of tension in the book). Erik tries to impart to Bill his wisdom and knowledge of manufacturing management, and how these principles apply to IT management as well. Erik’s knowledge is distilled down to two main areas: the Four Types of Work, and the Three Ways.

Four Types of Work:

The three ways:.

Works of fiction depicting a particular industry or profession are usually criticised for their sensationalised or overly-dramatic representations of the working life of professionals, with little representation of the true mundaneness of the field. Some prominent examples that come to mind would be hacking/cybersecurity, medicine, and politics.

The Phoenix Project masterfully weaves a compelling narrative that resonates with the realities of IT department life. Many readers, including myself, have found its portrayal strikingly authentic, as if the authors had a window into our professional experiences.

The tension and drama in the story arises from the protagonist and his colleagues contending with an overwhelming situation which threatens the future of their company, while contending with competing internal and external priorities, amid a maelstrom of corporate politics and self-interest. While there is definitely drama there, the characters and scenarios are incredibly realistic, and you will feel like you recognise these people and these situations. Even the technology and processes, and descriptions of the work being done, are realistic representations. They certainly don’t go into technical depth, but they also don’t embellish or alter what really happens.

As I mentioned, it’s unusual and refreshing to see a dramatic representation of a profession that remains faithful while simultaneously delivering a compelling narrative. It’s certainly far removed from the movie Hackers (although I do still love that movie, silly as it is).

…and Fantasy

While the characters and scenarios are grounded in reality, some solutions presented come across as streamlined or idealized, which might not always reflect the complexities of real-world scenarios. To be fair, while this is a common criticism, I personally don’t mind it. When you read any text book on business or technology processes, the solutions are always presented in a similar way (see, for example Adaptive Code via C# by Gary McLean Hall, a non-fictional book covering similar topics, recommended to me by Michael Ridland , which is also very good).

While the portrayal of the DevOps practices were idealised and simplistic, it’s the resolution of the political and character-driven tension that I found most unrealistic. It was this that broke my suspension of disbelief (minimally required as it was), and made me stop thinking of this book as the most realistic representation of a profession I had ever encountered, and instead consider it pure fantasy.

This is no doubt tied to my own experiences - prior to becoming a software developer, I had a career in IT Management and management consulting where I encountered many people and scenarios that were startlingly mirrored by those in the book. It’s rare in the corporate world to see a CEO or executive publicly apologize to a subordinate or take full accountability. Similarly, characters like Sarah Paulson, while familiar, often navigate the corporate landscape without facing significant consequences. In fact, they tend to flourish in these environments and be very successful.

Towards the end, the protagonist’s offer of a three-year fast-track program with “15 specific performance targets” for a COO role felt a bit idealised, as real-world promotions often come with more ambiguous criteria.

These are observations, not criticisms. In my opinion they in no ways undermine the value of the book; but in their stark contrast to the sometimes alarmingly realistic nature of the rest of the book, I found them somewhat jarring.

You might notice the absence of an in-depth discussion on the DevOps principles the book strongly advocates. This could be attributed to the evolving landscape of IT, where these practices have become more commonplace. While I certainly found the accounts of them in the book valuable, they weren’t new to me, which is probably why I didn’t focus on them.

Instead, I found the other aspects of the book more compelling. And also perhaps like many people who have read it, got swept up in how amazed I was at how frankly it captured and mirrored my own experiences.

In any case, I enjoyed the book, and I found the lessons to be valuable. I certainly wish I’d read it 10 years ago when it was first published!

Overall, The Phoenix Project is fun, entertaining, lightweight, and easy to read. At the same time it provides valuable business lessons. It would be incredibly hard not to recommend it - and, in fact, I think that anyone with even a passing interest in IT, development, DevOps, or management, should add it to their reading list.

Further Reading

The right tool for the job: beyond the golden hammer.

Introduction to cognitive biases in decision making Most of us aim to use the right tool for the job, navigating the balance between tried and trusted methods and the allure of new solutions. This...

The Status Quo Bias and Overcorrection

In my last post I discussed cognitive biases in decision making and introduced the concept of the platinum hammer. An extension of the well-known golden hammer, the platinum hammer is a predilectio...

Passthrough Behavior: Attaching things where they don't belong

Introduction I spent some time over the last year helping TrashMob build their mobile app. TrashMob is an initiative designed to allow people to self-organise community cleanup events - it’s a won...

Testing Sign-in with Apple in your local development environment

Unexpected Exceptions in EF Core 7+ Migrations

A new version of content is available.

InfoQ Software Architects' Newsletter

A monthly overview of things you need to know as an architect or aspiring architect.

View an example

We protect your privacy.

Live Webinar and Q&A: The Architect’s Guide to Elasticity (Sept 26, 2024) Save Your Seat

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

• English edition
• Chinese edition
• Japanese edition
• French edition

Back to login

Login with:

Don't have an infoq account, helpful links.

• About InfoQ
• InfoQ Editors

Write for InfoQ

• About C4Media

Choose your language

Get clarity from senior software practitioners on today's critical dev priorities. Register Now.

Level up your software skills by uncovering the emerging trends you should focus on. Register now.

Discover emerging trends, insights, and real-world best practices in software development & tech leadership. Join now.

Your monthly guide to all the topics, technologies and techniques that every professional needs to know about. Subscribe for free.

InfoQ Homepage Articles Interview & Book Review: “The Phoenix Project, A Novel About IT, DevOps & Helping Your Business Win”

Interview & Book Review: “The Phoenix Project, A Novel About IT, DevOps & Helping Your Business Win”

Feb 28, 2013 8 min read

Manuel Pais

This book  will resonate at one point or another with anyone who's ever worked in IT. And it will resonate deeply with most. For some it will seem a plagiarism of their own professional story.

The growth of an organization naturally leads to separation of people and responsibilities into teams, sections, departments, units, which brings with it local specialization, work handovers across teams and formal change control procedures. Inevitably this will slow down the pace of IT changes in favour of the stability required for a medium to large enterprise. But is this really inevitable? And most importantly can business survive in the long term if it can’t make full use of IT’s capacity to enable business changes fast and reliably? This book answers these questions by showing that a truly collaborative approach between IT and business is possible.

We follow the story of Bill Palmer, unwillingly forced to take over the VP of IT Operations role at Parts Unlimited, a car parts company on the verge of financial meltdown. A company unable to cope with the advances their competitors are pulling out in the market. Even worse, they're having a hard time to comply with basic competences such as securing employees payments or keeping their inventory.

Related Sponsored Content

How to end the confusion in cloud transformations: insights from mckinsey & company, related sponsor.

Building digital futures. Together.

All too common problems the company is suffering from include lack of collaboration between teams, a blame culture, over dependency on individual heroes, imposing tools over collaboration, power games and pushing for individual goals/projects.

Granted, the novel draws an initial dark picture which is slightly overdramatized as are the ensuing 180 degrees turnaround (fueled by a mysterious khaki pants guru) to a rosy scenario filled with collaboration between all teams, continuous delivery and sky-rocketing sales increase. But this doesn't take away any of its value, instead highlights in a clear and compelling way the problems many organizations face today as their IT fails to support their business needs. And it shows another way is possible by promoting system thinking (over local optimization), feedback loops and a continuous learning culture .

Despite the DevOps reference in the title, breaking the divide between dev and ops is really just a small part of the overall cultural shift the book puts forward. The book addresses the divide between security compliance and IT, between dev and qa, between marketing and IT and finally the divide between business goals and IT delivery. DevOps on steroids one might call it.

By the end of the novel we’re reminded that DevOps doesn’t mean everything will work flawlessly with frequent deliveries, stable platforms and business-IT alignment. Instead it shows that with genuine collaboration in place everybody can give their best contribution to resolve problems and support the business in an agile and controlled fashion without resorting to the blame game.

InfoQ spoke with Gene Kim, one of the book co-authors, about the main motivation for this book, the state of IT in the industry, and other topics. We’re also sharing an excerpt from the book (first 170 pages) made available by the book authors. Gene has also posted about further related reading .

InfoQ: Your book expands the DevOps notion of Dev and Ops teams collaboration to include also business, marketing, QA and security teams, all working together to enable quick business decisions and implementation. In your experience how far are most organizations from realizing the need and/or benefits of this modus operandi? How important is the awareness of the DevOps movement in the enterprise IT world in order to go that extra mile and involve the business side in amplifying the feedback loops?

Gene : Regretfully, I think 5% or fewer of the organizations I've seen have reached the level of collaboration that are typified by the DevOps culture, where Dev and IT Operations, as well as Product Management, QA, Infosec and the rest of the business.  The ones most widely cited are the famous examples of Netflix, Etsy, Facebook, Google and Amazon, where they've relentlessly examining how to improve flow through the product value stream to help the business win.  The hallmarks are easy to spot:  they have Hack Days where they experiment, innovate, automate and help pay down technical debt; they are constantly innovating and automating work that impede flow or cause unplanned work; they attract talented people and empower them to take risks and go beyond the status quo. All of these characteristics are equally applicable for any organization that needs to compete in the marketplace to win new customers and delight their existing ones.  Arguably, organizations such as Facebook, Google and Amazon are "enterprises" in their own right.  But, increasingly, we're seeing these types of success stories in financial services, higher education and retailing, such as BNY Mellon, World Bank, Paychex, Bank of America, The Gap, and Seton Hill University. My genuine belief is that when these practices are widely adopted, we will see a surge in productivity that we haven't seen since the manufacturing revolution in the 1980s.  The numbers we calculated show that there's nearly $3 trillion of value on the table that we could capture, if we could halve the amount of IT waste that could be mitigated with DevOps-style -- that's more than the entire economic output of Germany! How important is this?  When I think about the world my kids will inherit, and what this could do to standards of living, as well as quality of life in IT, I think this is incredibly, incredibly important.

InfoQ: The book suggests that successfully increasing collaboration and breaking silos is more likely to be driven by IT-focused bottom-up initiatives than a top-down business-focused understanding that IT needs to be agile enough to support quickly changing business needs. Would you agree?

Gene: I think widespread adoption of DevOps requires both bottom-up and top-down.  My experiences with ITIL, IT operational process improvement and information security proved to me that bottom-up initiatives aren't often not enough.  Process improvement must be explicitly and viscerally linked to helping achieve the highest organizational objectives.  If it doesn't, the illusions of "faster time to market" and "ship more crappy stuff faster" will always win the day. The core, chronic conflict that every IT leader faces is the need to simultaneously enable faster time to market (i.e., make as many changes as you can), while providing stable, secure and reliable IT services (i.e., make as few changes as you can).  Until the seminal 2009 Velocity talk that John Allspaw and Paul Hammond did on doing "10+ Deploys Per Day: Dev and Ops Cooperation at Flickr," we thought that we had to choose one or the other.  Allspaw and Hammond showed that we could actually get both, and get performance orders of magnitude better than we ever thought possible! That's what every business and IT leader needs to know.  That by doing this, they can get fast flow of features into the marketplace, while providing world-class stability and reliability, and this is how we help the business win.

InfoQ: What was the inspiration and the goal for writing this book? Is it based on the authors' experiences in IT?

Gene: Without a doubt, the inspiration for us has been Dr. Eliyahu Goldratt's seminal book, “The Goal: A Process Of Ongoing Improvement,” which he wrote in 1984.  It’s a novel about Alex Rogo, a plant manager who must fix his cost and due date issues in ninety days, or his plant will be shut down.  This book has been incorporated into many MBA curriculums and has influenced multiple generations of business leaders, and has sold over 6 million copies to date. My co-authors and I studied this book for nearly a decade, getting ready to write “The Phoenix Project.”  In many ways, I view our book as an homage to “The Goal.” We attempted to mirror most of the book structure and plot elements, using it as a vehicle to show the downward spiral that we've seen countless times over our careers. We constructed "The Phoenix Project" in a way that would help enable a shared understanding of the problem that affects all the silos, which inevitably leads to a downward spiral where Development and IT Operations can't meet their objectives and become locked in inter-tribal warfare.  In fact, the first 170 pages of the book is really designed to create the response of "holy cow, this is me that they're describing in the book,"  regardless of your role in the organization.  Why?  It's because it happens everywhere where DevOps practices and culture isn't embraced.  Why a novel?  Studies have repeatedly shown that story-telling is the most effective mode of communications, and story-telling is what allows people to evangelize the concepts across and up the organization.  One of my favorite reviews of the book came from Jeremiah Shirk from Kansas State University:  "Some books you give to friends, for the joy of sharing a great novel. Some books you recommend to your colleagues and employees, to create common ground. Some books you share with your boss, to plant the seeds of a big idea. The Phoenix Project is all three.”

InfoQ: How would you sum up the book's message with a one-liner?

Gene: "The Phoenix Project" is a novel that first describes the problems that almost every IT organization is faced with, and then shows the practices of how to solve the problems, improves the lives of those who work in IT and be recognized for helping the business win.

InfoQ: You are working on the DevOps Cookbook with several other high profile practitioners in the field (John Allspaw, Patrick Debois, Damon Edwards, Jez Humble, Mike Orzen and John Willis). Is that meant to be a definitive hands-on book on how to go about solving the questions raised in "The Phoenix Project"? Do you have an estimated publishing date?

Gene: Let's say "Late 2013."  :)

About the Book Authors

Rate this Article

This content is in the infrastructure topic, related topics:.

• Infrastructure

Related Editorial

Popular across infoq, why a hedge fund built its own database, university researchers create new type of interpretable neural network, jdk 23 and jdk 24: what we know so far, microsoft releases .net 9 preview 7 with new features and updates, java news roundup: spring 6.2-m7, project loom, payara platform, gradle 8.10, helidon 4.1, the state of engineering management in 2024, related content, the infoq newsletter.

A round-up of last week’s content on InfoQ sent out every Tuesday. Join a community of over 250,000 senior developers. View an example

Thomas Henson

The Phoenix Project Book Review

September 14, 2016 by Thomas Henson Leave a Comment

Where do I start with DevOps?

Working in IT Operations is hard like really hard. Most of you who have been doing for years already know this. Technical debt seems to pile up and developer/operations are constantly being asked to more with less. Most companies are now an IT organization which puts more pressure from the business to help generate revenue.

DevOps is the key to helping IT operations transform from a fragile chaos ridden teams into agile disciplined teams. Sounds like another absurd promise from the buzzword of the day. I’d probably think that way, however, my back ground as a  Scrum Master  tells me it’s true. In the the developer realm we have been using agile frameworks since the Agile Manifesto was written in 2001. Yes we have a Manifesto!

Phoenix Project Book?

Before jumping in head first I recommend reading The Phoenix Project. It’s a fictional account of a company where everything that can go wrong does go wrong. Of course the problems all fall on IT operations. The book walks through how a company can transform from a traditional IT organization that is seen as a cost center into a revenue generating part of the company.

Find out more by watching my review of The Phoenix Project and DevOps.

Be sure to subscribe to my YouTube channel to get my latest videos.

Thomas Henson here with thomashenson.com. Today, we’re going to do a book review on the Phoenix Project. If you’re interested in DevOps, stay tuned.

Book Review

The Phoenix Project is a fictional account of an IT organization. You’re probably saying, “Hey, that sounds kind of boring. Why would I want to read a fictional account of an IT organization?” But it’s actually a really good read. It goes through a fictional account of Parts Unlimited, which is an aging company that’s in a very competitive environment. The IT organization just can’t seem to get everything together with all the requirements that’s being put on them. They have a CEO that’s on CNBC a lot promising this new application. The application has been in development for quite a long time and they just can’t seem to get it to market. You follow around the VP of IT, as he’s new into the role, been with the company for a while, and you see a lot of the challenges that they have.

My Perspective

From my perspective, it’s a really good book, because I just came in from the application development side and started working with IT operations people. For me, I’ve started seeing some of the challenges that they have. Coming from the Agile environment and doing Scrum, I realized hey, we can get our requirements out; we can test things; we can push new features out very quickly, but a lot of our challenges come from testing with the operations side. I remember sitting in a meeting one time, and the customer was asking about all the things that we were doing. He was really happy about them, but then he switched to questions about, “Hey, how is this going to be maintained from an operational perspective?” I was like, “I’m not really sure why you’re asking me. We’ve got all these cool features. It’s going to be an awesome project. It’s meeting all the requirements that you have. Here’s the requirements that we need to support that. Now, in the out years, I’m not sure how big the project is going to grow, because it’s just going to be awesome.” I really got beat up in that meeting about those questions. It’s like okay, you’re creating this application, but what’s it going to do in the future? How is it going to balloon up? What’s the cost to maintain an application? How complex is it? One of the things I was thinking when we were working through it is, “Yeah, there are some challenges, and it’s a new system that the operations people have to learn, but everybody wants to learn Linux.” The question was, “Well, we’re going to have to hire somebody. We’re going to have to pay for training.” Those are the things I really didn’t think about. This book puts it into perspective.

Book Examples

One of the examples that they use in it is that a lot of times, developers take a pig, and they throw the pig over the wall. They high five each other, because everything is done. But that pig is given to the operations side with little or no instructions. It’s something that they have to maintain for years on end, where application developers, we get to go to the next project. I thought it was a really interesting read. I thought it was really good, especially for somebody that’s done Agile development on the development side but never really thought about it from a DevOps perspective of how is this going to be used in operations?

Would I Recommend It?

I would recommend this book for anybody, whether you’re a developer, work in IT operations, or even just curious about how IT should work in your organization. It’s a really good book. It’s a really quick read, too. I think you can probably do it… I think it did it over in a weekend. It’s a really good book. You should check it out. For more updates, stay tuned to thomashenson.com.

The Ohio State University

• BuckeyeLink
• Search Ohio State

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

Book Review by  Canon Committee Member, Rick Howard :  The Phoenix P roject: A Novel About IT, DevOps, and Helping Your Business Win  (2013)   by Gene Kim, Kevin Behr, and George Spafford

Executive Summary

DevOps is perhaps the most important innovation that has happened to the IT sector since the invention of the personal computer back in the early 1980s. It is the idea that organizations would use the same Agile methodology they use today with their software development teams but expand it across all organizations in the deployment cycle: product managers, marketing professionals, developers, quality assurance practitioners, systems engineers, system administrators, operations staff, database administrators, network engineers and security professionals. The specific concept behind  The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win , as well as the DevOps philosophy in general, is that the development, quality assurance, deployment, maintenance and end-of-life of IT systems, to include security updates, is very similar to maintaining a production line of any other product. The best practice that has emerged since WWII to manage production lines is the Toyota Production System. DevOps is the IT version of that system. In it, DevOps practitioners try to reduce technical debt by limiting work in progress in order to control the flow of the entire system. I predict that, in 10 years, we will all be immersed in the DevOps philosophy. Because of the way the authors of  The Phoenix Project  explain DevOps through the novel form, the ideas are much more accessible to non-IT people: CEOs, CFOs and, yes, CSOs. Because of that quality, it is a must-read book for all C-level executives, including security professionals, and you should have read it by now. 

Introduction

One of the constant problems I hear about in my travels is the tension between network managers, security personnel and the information technology staff. In the best cases, even when the teams get along, the passage of workflow from one team to the next is always cumbersome and inefficient. In the worst cases, one or more of the main groups acts as the Minister of “No” within the organization and hinders the other groups’ desire to upgrade their internal systems. To fix these issues, information technology and security professionals have proposed different organizational schemes to equalize the power dynamic:

• The Chief Information Security Officer (CISO) should report to the Chief Information Officer (CIO).
• The CISO should be a peer to the CIO.
• The CIO should report to the Chief Security Officer (CSO).
• The CSO and the CIO should report to the Chief Executive Officer (CEO) or at least the Chief Operating Officer (COO).

I have been known to partake in those debates myself. [1] But those discussions tend to argue for the idea that one group should be in charge of the other or that they should all be peers. In each case, at least one group is never going to be happy. It seems there should be another way.

The relatively new notion of DevOps (development and operations) emerged out of three converging ideas sometime in late 2009: The Agile Development Method [2]; the 2009 Velocity Conference talk;  10+ Deploys per Day,  by John Allspaw and Paul Hammond [3]; and Eric Ries' book,  Lean Startup  [4] which influenced many Silicon Valley companies between 2007 and 2010. [5] DevOps is the idea that there needs to be a much tighter integration between software developers and information technology operations (IT Ops); that once the developers, the quality assurance teams, and the security analysts pass any new code or maintenance updates to IT Ops for deployment, their jobs are not done. Instead of creating artificial black boxes where updates come in, get worked on, and then are passed to the next black box, DevOps is the recognition that update creation, deployment and maintenance is one big system of systems that needs to be managed that way. It is the idea that organizations would use the same Agile methodology they use today with their software development teams but expand it across all organizations in the deployment cycle: product managers, marketing professionals, developers, quality assurance practitioners, systems engineers, system administrators, operations staff, database administrators, network engineers and security professionals. In other words, DevOps uses the Agile philosophy across the entire lifecycle of deployed systems from design, to development, to testing, to deployment, to maintenance, and finally to end-of-life. [7] This idea elevates IT Operations and Security Operations from being mere support organizations to core competencies within the business.

Some big and successful organizations have adopted DevOps: Google, Amazon, Netflix, Facebook, Microsoft, BNY Mellon, The Gap, Nordstrom, and Northrop Grumman just to name a few.  Experts in the field say that adoption is a key part of their achievement. [8]

DevOps is such a new idea though that defining it precisely is not easy and explaining the potential benefits of this change-of-perspective to executive management and other IT professionals is challenging. Enter  The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win.  [9] You read that right. The authors wrote a novel to explain the intricacies of DevOps. They got the idea from another iconic book written in the early 1980s, called  The Goal: A Process of Ongoing Improvement , where the authors used the novel form to explain the Theory of Constraints. [10]

Parts Unlimited  is an automotive parts manufacturer and online retailer that used to be the market leader. In recent times though, the competition has taken the lead in growth and profitability. The company leadership has long promised that a new online program, code-named “Phoenix,” will restore  Parts Unlimited  to its former glory, but the project is years behind. Investors are pushing for significant leadership changes to right the ship. The company’s board of directors has stripped the chairmanship from the CEO, Steve Masters, and given him six months to show dramatic improvement, or they will take other more strategic and drastic measures, such as splitting up the company. In response, the CEO fired the existing CIO and VP of IT Operations and promoted the hero of the story, Bill Palmer, to interim CIO. That’s the setup.

The story revolves around how Bill, the interim CIO, learns about DevOps from an Obi-Wan-like board member candidate, Erik Reid, and incrementally deploys the philosophy across the company to save it in the nick of time. Through the process, the VP of Application Development, the lead engineer, the Director of Distributed Technology Operations, the CISO, the Director of IT Service Support, the Senior Director of Retail Program Management, the interim CIO, the Chief Financal Officer (CFO) and, ultimately, the CEO, come to realize that DevOps is the most important function of the company. At the end, when Bill succeeds as interim CIO, the CEO decides to groom him to become the company’s COO. In other words, the COO’s main job in  Parts Unlimited  is to oversee the DevOps function within the organization.

Of course, this book could have been a non-fiction description of DevOps, but that would have been dry and uninteresting to most people. By putting the key elements into novel form, the authors make the technical concepts accessible to a larger audience, not just the technicians of the world but every kind of business leader. The entire C-suite has a part to play in the story as well as all the technical leaders. The authors are trying to teach a wide audience about some fundamental issues that DevOps addresses.

DevOps: Key Concepts

During the story, our Obi-Wan-like board member candidate, Erik Reid, keeps dragging our interim CIO down to the parts manufacturing plant to give him the lesson of the day. Obi-Wan is a parts manufacturing guru and, throughout the story, he keeps trying to explain to the interim CIO that the management of IT Operations should be very similar to streamlining plant manufacturing. Many of the concepts are similar and the problem-solving solutions used in plant manufacturing can and should be applied to IT Operations.

Toyota Kata

The Toyota Car Company has been a profit leader in the auto industry for many years. Several researchers believe that Toyota’s success can be attributed to the Toyota Production System (TPS) that Toyota leaders instituted immediately after World War II. The basic idea is to eliminate waste in every nook and cranny within the company. [11] That is easier said than done, but the TPS way boils down to two katas: one for improvement and one for coaching. The thing about katas is that they are not processes, or information flows, or checklists, or management frameworks. The word “kata” is a martial arts term that describes movement patterns. The martial artist practices them so much that they are second nature; so much so that, when they get into real situations, they do not have to think about what to do. Their muscle memory automatically kicks in. [12]

Researchers and business leaders have studied the TPS for over 40 years. Many books have been published discussing the philosophy, and yet, Toyota continues to innovate and stay ahead of its competitors. [11] One attribution to that consistency is that Toyota thinks about innovation differently from its western competitors. Many in the West think that innovation is a bold new idea that takes the industry in a different direction. Toyota believes that innovation occurs in the score of little improvements made every day by its employees. The company makes millions of them a year because their Improvement Kata and Coaching Kata are second nature to the employees and part of their culture. Not all the improvements work. How could they? But the idea is to try new things, fail fast, and move on to the next.  The Phoenix Project  borrows heavily from Mike Rother’s book,  Toyota Kata , [13] and the idea of continuous improvement is a key concept that our Obi-Wan imparts to our interim CIO. The story begins with  Parts Unlimited  years behind on the  Project Phoenix: an automation upgrade for their service and support. At the end of the story,  Parts Unlimited  is rolling out code changes to Project Phoenix ten times a day.

Technical Debt

When you consider that IT Operations is similar to manufacturing plant operations, you start to look at where your employees are spending their time. For instance, you may wonder why the security team can never get all the patches installed. That task seems pretty straightforward. Why is it so hard? One contributing factor is the unintentional deployment of fragile artifacts or systems. Because these systems tend to break down, more and more of the technical staff have to spend time bringing them back online or keeping them online. This effort is called “technical debt.” For every system an organization deploys, the IT Ops staff gets some amount of technical debt that they have to plan for and accommodate. The Toyota Production System attacks technical debt at every opportunity by vigorously trying to reduce it; ruthlessly making their systems less fragile. This activity is the cornerstone of DevOps. The story begins with  Parts Unlimited  swimming in technical debt. IT Ops can’t get any “real” work done because the team is constantly reacting to emergencies around failing systems.

WIP stands for Work in Progress. In the Toyota Production System, everything from the start of the car production line to the end when a brand-new Toyota rolls out into the world is WIP. According to Stephen Franklin, WIP “refers to all materials and partly finished products that are at various stages of the process.” “Essentially, it’s an investment that has had zero return and depreciates in value over time.” [13]

Everything within WIP represents potential value that has not yet materialized for the customer. It is the same idea with IT Ops. The more things an organization has within WIP, the more things will happen to impede the workflow. It follows, then, that reducing WIP is essential to any organization. Limiting WIP, therefore, makes IT leaders consider the system as a whole. They need to understand how any new work started will affect the capacity of the system. In other words, if they introduce new work at the beginning of the product line, how might that cause bottlenecks in the capacity of the system to continue delivering constant flow?

This idea is a key piece to the DevOps mantra. Instead of applying the Agile software development methodology to the company’s programmers, DevOps applies similar ideas to the entire system: development, quality assurance, deployment, maintenance and end-of-life. This kind of thinking allows IT leadership to discover constraints in the system; things that, because of resource limits, cause bottlenecks in the system’s flow.

In the story, the key constraint that affected everything wasa   Parts Unlimited’s  key engineer, Brent Geller. We all have had a “Brent” on our staff. This is the one person who is the go-to engineer for everything. When we need something new, give it to Brent. When something breaks, give it to Brent. When we need to install the latest security patch, give it to Brent. Even though  Parts Unlimited  had many engineers on staff, Brent always got things done faster. The IT team grew to rely on him for everything and the company’s leadership would cherry-pick him for their pet projects. The more work the company gave Brent, the more WIP they created because he was that one person and everything relied on him to push the workflow. He was the constraint that hindered workflow.

Kanban boards

A Kanban board is a visualization tool to help teams reduce WIP. [14] Toyota invented the tool back when it started developing the Toyota Production System. [15] In order to seek continuous improvement by limiting WIP, Toyota discovered that the task became easier if they could “see” the data and discover where the bottlenecks were. The generic Kanban has three columns: To Do, Doing and Done. Kanban practitioners place various kinds of work on the chart: user stories, defects, tasks, and features. Today, DevOps organizations expand the Doing column into plan, develop, test, and deploy in order to view the entire system. Reducing WIP means that leadership is controlling the amount of work flowing through the system so that it never exceeds capacity. The Kanban board allows leadership to quickly see what is flowing through the system. [15]

There is a subtle difference between this Kanban board idea and the Agile development method’s Scrum idea. A Scrum has regular fixed length sprints. A Kanban board shows continuous flow. A Scrum releases new code every two weeks while the Kanban board emphasized continuous delivery. In a Scrum, no changes occur during a sprint. In a Kanban board, changes happen at any time.

In the story, before the IT Ops leadership team adopted the DevOps strategy, they tried to manage all the work in a system by tracking deadlines. Years before, they paid for and deployed a very expensive ITIL (Information Technology Infrastructure Library) tracking system and relied on project managers to keep the system updated with detailed analysis of each of their projects. They never had the time to do that so the system failed miserably. By adopting the Kanban board system, the entire team could visualize the work moving through the system and make decisions about restricting or increasing the flow.

The Five Dysfunctions of a Team

The authors borrow heavily from Patrick Lencioni’s book,  The Five Dysfunctions of a Team: A Leadership Fable . [16] In that book, Lencioni says one of the major reasons that a team fails is lack of trust between team members. He says there are five indicators of this team problem: unwillingness to be vulnerable within the group, cosmetic discussions versus passionate and constructive debate, no accountability, publicly supporting a decision while privately undermining it, and focusing on individual success versus team success. [16] In the story, when the team is days from utter failure, the CEO gathers the team together and walks his way through these indicators. He tells a very personal story about the status of the company; has a pointed discussion about what is really going on; explains to the group that he is accountable for the success or failure of Project Phoenix and will hold his subordinates responsible for their parts; and, finally, he imparts that the team’s success, not individual contributors, will be the thing that keeps the company solvent.

Every time the Obi-Wan-like board member drags the interim CIO down to the production plant, he imparts a new concept of  The Way .  The Way  is a metaphor for continuous delivery. As the story opens, the Phoenix Project is years behind schedule. After the interim CEO adopts  The Way , he is able to continuously deploy new code and updates as often as is needed, every day, multiple times a day.  The Way  consists of three ideas [17]:

• The Flow:  Understand how work moves through the system and know that changes will have random effects. Always try to increase the flow but never pass defects downstream.
• Feedback:  Understand needs from both internal and external customers. Shorten feedback loops whenever possible.
• Continual Learning:  Encourage experimentation and learn from failure. Recognize that the kata will build mastery.

I think that the concept of DevOps is perhaps the most important innovation that has happened to the IT sector since the invention of the personal computer back in the early 1980s. By forcing IT leadership and network defenders alike to consider the production system as a whole, to get us out of our stovepipe concerns for our individual projects, and to make collective decisions for the good of the organization that we work for, the community has invented  The Way  of continuous improvement for all parties involved. IT practitioners are most likely aware of the concept but my guess is that many security practitioners are not.  The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win  is an introduction to the subject. I predict that, in 10 years, we will all be immersed in the DevOps philosophy. Because of the way that  The Phoenix Project  authors explain DevOps through the novel form, the ideas are much more accessible to non-IT people: CEOs, CFOs and, yes, CSOs. Because of that quality, it is a must-read book for all security professionals, and you should have read it by now.

[1] " The Evolution of the Cybersecurity Executive Trifecta: The CSO/CIO/CISO ," by Rick Howard, RSA Conference, 21 April 2015, Last Visited 24 September 2016,

[2] " To agility and beyond: The history—and legacy—of agile development ," by Peter Varhol, TechBeacon, 26 August 2015, Last Visited 24 September 2016,

[3]" 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ," by John Allspaw and Paul Hammond, Velocity 09, 25 July 2009, Last Visited 23 September 2016,

[4]" The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses ," by

Eric Ries, Published January 1st 2011 by Crown Business, Last Visited 23 September 2016,

[5] " The Convergence of DevOps ," by John Willis, IT Revolution Press: Helping Spark the Cambrian Explosion, Last Visited 11 August 2016,

[6] Deleted

[7] " What is DevOps? " by Ernest Mueller, the agile admin, 2 August 2010,  Revised 16 January 2016, Last Visited 11 August 2016,

[8] " Keynote PuppetCon 2014: The Phoenix Project: Lessons Learned - Gene Kim, IT Revolution Press (Vimeo repost) " by Gene Kim, YouTube, 9 October 2014, Last Visited 10 August 2016,

[9] " The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ," by Gene Kim, Kevin Behr, and George Spafford, Published  by IT Revolution Press, 10 January 2013, Last Visited 28 July 2016,

[10] " The Goal: A Process of Ongoing Improvement ," by by Eliyahu M. Goldratt, and Jeff Cox, Published 1982 by North River, Last Visited 23 September 2016,

[11] " THE OPEN SECRET OF SUCCESS: Toyota Production System ," by James Surowiecki, The New Yorker, THE FINANCIAL PAGE, 12 MAY 2008, Last Visited 24 September 2016,

[12] " Toyota Kata: the 'how; of 'engaged leadership ,' " by Mark Rosenthal, The Lean Thinker: Thoughts and insights from the shop floor, 28 June 2010, Last Visited 24 September 2016,

[13] " Toyota Kata: M anaging People for Improvement, Adaptiveness and Superior Results," by Mike Rother, Published by McGraw-Hill Education, 1 September 2009 (first published 2009)

[14] " What is A Kanban Board? " by Leant, Last Visited 11 August 2016,

[15] " A brief introduction to kanban: What software makers can learn from Japanese manufacturing ," by Atlassian, Last Visited 11 August 2016,

[16] " The Five Dysfunctions of a Team: A Leadership Fable ," by Patrick Lencioni, Published by Jossey-Bass, 11 April 2002 (first published January 1st 2002), Last Visited 10 August 2016

[17] " Limited WIP Meeting presentation - The Phoenix Project book review ," by Rudiger Wolf,  LinkedIn SlideShare, 26 November 2013, Last Visited 10 August 2016,

" Book review: the Phoenix Project. " by skeptic, The IT Skeptic, 22 January 2013, Last Visited 10 August 2016,

" Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Martin Fowler Signature Book) ," by Jez Humble and David Farley, Published by Addison-Wesley Professional, 27  July 2010, Last Visited 11 August 2016,

" Itil Service Support ," by Central Computer, Published by Stationery Office Books (TSO), 1 March 2000, Last Visited 11 August 2016,

" Kanban 101: How to Use Kanban Boards to Manage Your Next Project ," BY DANNY SCHREIBER, zapier, Last Visited 11 August 2016,

" Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) ," by Michael T. Nygard, Published by  Pragmatic Bookshelf, 30 March 2007, Last Visited 11 August 2016

" The Visible Ops Handbook: Implementing Itil in 4 Practical and Auditable Steps ," by Kevin Behr, Gene Kim, and George Spafford, Published by Information Technology Process Institute, 2004, Last Visited 11 August 2016

" Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps ," by Gene Kim , Paul Love, and George Spafford, Published by It Process Institute, 17 March 2008, Last Visited 11 August 2016,

" Where To Learn More About Concepts In “The Phoenix Project ” (Part 1)," by Gene Kim, IT Revolution Press, Last Visited 10 August 2016

" WIP Limits: How to Journey Safely Into the Unknown (Part 1 of 3) ," by  Stephen Franklin, leankit, 18 March 2014, Last Visited 25 September 2016,

• Share via Facebook (link opens in new window)
• Share via Twitter (link opens in new window)
• Share via LinkedIn (link opens in new window)

From Chaos to Success: Key Takeaways from ‘The Phoenix Project’ for Improving Software Delivery

Image generated by DALL·E 2

Do you feel like you’re constantly putting out fires on your software development project? Are you struggling to meet unrealistic deadlines while dealing with a never-ending stream of urgent emails or tickets? If so, you may be working on a “Phoenix Project”. These are high-stakes, high-pressure situations where everything seems to be going wrong, and it can feel like your project is on the brink of collapse.

But fear not! There is a way to unleash the phoenix from the flames and build a stable, continuously evolving software project where coding makes fun again. The secret to success involves following key principles of DevOps, a set of practices emphasizing collaboration, automation, and a focus on delivering value to the end user.

One great way to learn these principles is by reading the book “ The Phoenix Project ” by   Gene Kim ,   Kevin Behr , and   George Spafford . In this post, I’d like to share my key takeaways from the book and some crucial learnings I’ve gained throughout my journey as a software developer and project manager in several small to enterprise projects working for start-ups, as a freelancer, and now at &amp. So, whether you’re a product owner looking to boost your company’s software delivery or a software developer seeking to enhance your skills, grab a cup of coffee (or tea!) and join me as we explore my take on “The Phoenix Project.”

What is the Phoenix project, and why is it essential to adopt a DevOps approach?

The Phoenix Project is a novel that tells the story of an IT organization that transforms from a company with a chaotic and struggling IT landscape to a well-oiled machine using the principles of   Lean Manufacturing . The Phoenix Project emphasizes the importance of aligning business strategy with IT operations and automation. By embracing DevOps principles, organizations can create a streamlined and efficient development process that delivers high-quality software products that meet customers’ needs. In today’s fast-paced, digital world, where software development and delivery can make or break a business, “The Phoenix Project” serves as a valuable guide for product owners and software delivery teams seeking to transform their organizations and improve product delivery.

Agile is dead — build a code factory!

Agile is dead — isn’t it? — At least the word agile is overused, and everybody thinks differently about what Agile actually is. Rather than trying to explain the meaning of agile, you should apply clear imaginable principles to your product team. The book compares software development to a plant factory and suggests that software development should be approached similarly. Build a code factory! This means dividing the development process into different work centers, including business analysis, design, development, testing, quality assurance, deployment, and operations which does not mean building silos in separate teams. Work centers should help you structure your team and improve your product team’s efficiency. By doing this, you can ensure that each stage of development is properly executed, leading to more efficient and effective software delivery. It also helps to improve collaboration and communication among team members, which is essential for any successful project.

Reduce handovers

When defining your work centers, it’s important to group people together who usually work together — obvious but unfortunately still not the state of the art in every company. People who often pass over tasks should work together whenever possible to reduce handovers between work centers and ensure optimal product delivery. This enables faster knowledge transfer and reduces the chances of mistakes due to miscommunication or missing documentation. So, it’s important to focus on reducing handovers between work centers and encourage collaboration among team members.

While work centers are well-defined groups, it’s essential to remember that they are part of a larger product team, and collaboration between different work centers is crucial for the project’s success. The product delivery pipeline of your project is only as strong as the weakest link, and all work centers need to work together towards the common goal — delivering a great product!

Software development is virtual work — visualize it, make it real

Software development is a virtual process, unlike, for example, the tangible work of a mechanical engineer, and for many people, hard to grasp. Therefore, it’s essential to be clear and precise about the type of work you’re doing in order that you can plan and prioritize tasks. Visualizing your work can make it more tangible and real. One effective way to do this is by using a Kanban board to keep track of tasks and their status. Ensuring all work is represented on the Kanban board is important. No work should be done without a representative task on the Kanban board.

When all tasks are visualized, you can adequately track them and see if they get stuck. The least productive tasks are those which move the Kanban board backward. To prevent this, you should define a “Definition of Done” for each stage of the development process and implement quality gates to reduce pushback of tasks. By implementing these practices, you can better visualize and manage your software development process.

Reduce work in progress

A quote from another must-read DevOps book:

“Queue theory in math tells us that as utilization approaches 100%, lead times approach infinity-in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done.”

—   Accelerate: Building and Scaling High Performing Technology Organizations   by   Nicole Forsgren PhD ,   Jez Humble ,   Gene Kim

So find your bottlenecks and optimize your production pipeline to   not   run at a utilization rate of 100%. You can easily spot bottlenecks on your Kanban board — Your biggest bottleneck is the work center with the most “work in progress”. Why? The reason is simple — the more tasks are in progress at a particular work center, the slower the pace of work. Each task requires a certain amount of time and attention, and if there are too many tasks in progress, the work center may become overwhelmed and unable to complete any of them efficiently. Most of the tasks will be waiting in an idle state anyway, as there are not enough people or resources to process these tasks.

Therefore, measuring the time tasks spend in an idle state is essential. Idle time is unproductive lost time, and it’s important to minimize it as much as possible. For example, if a developer has to wait 1–2 days for a merge request review, she will start working on another task and forget about the context of the first task. Once the review is done, she has to stop her current task, regain the context of the old task, fix the review comments, and submit them again for a second review. Meanwhile, the reviewer may have already moved on to another task, causing further delays in the pipeline. This can lead to an unnecessary back-and-forth between tasks and increase idle time. By reducing handovers between work centers and keeping tasks moving efficiently through the pipeline, you can increase productivity and reduce idle time.

Types of work and the spiral of death

To effectively manage your team’s workload and the amount of work in progress, it’s important to understand the different types of work involved in a software development project. The answer is not as complex as it seems and is quite simple.

So, can you name the different types of work we are doing in software development?

“Yes, I think I can,” I say. “At the plant, I gave you one category, which was business projects, like Phoenix,” I say. “Later, I realized that I didn’t mention internal IT projects. A week after that, I realized that changes are another category of work. But it was only after the Phoenix fiasco that I saw the last one, because of how it prevented all other work from getting completed, and that’s the last category, isn’t it? Firefighting. Unplanned work.” — “Precisely!” I hear Erik say.

— The Phoenix Project

If you break that down from running an IT department to managing a single software project, there are four types of work:

• features (create new business value)
• changes (e.g. comply with regulations or update to a new API version)
• (technical) improvements (e.g., reduce technical dept, improve test setup)

Knowing these types of work helps to improve utilization and increases the quality of the software product, stability, and pace of the team.   Focusing solely on one type of work, such as feature development, will increase the backlog of all other types of work, slowing down the general project.   For instance, ignoring technical debt will lead to bugs, slowing down feature development and changes. To not miss important deadlines, you will eventually decide to take shortcuts that add technical debt, which leads to even more bugs,… — welcome to the spiral of death where the team’s productivity and the software’s quality decline over time. Therefore, it’s essential to give attention to all types of work and balance them properly.

Allocating time for specific types of work can be an effective way to manage your team’s workload. For example, you could spend 60% of your time on feature development, 10% on changes, 20% on technical improvements, and 10% on fixing bugs. While this may sound simple, the hard part is sticking to your plan. Do you know the — WE HAVE AN EMERGENCY — guy who sets everything on fire if he discovers a bug? If you have such a person in your team, it’s even more important to have a structured process where you properly prioritize your bugs just as you prioritize the rest of your work.

Sometimes, a bug may require immediate attention, such as a failing login that affects all customers. On the other hand, a missing frontend input validation for a rarely used feature may be less critical and can be addressed later. By prioritizing your work effectively, you can ensure that your team focuses their time and energy on the most critical tasks and ultimately achieve better results.

Automate repetitive tasks

Automating repetitive tasks is an essential part of modern software development. Human beings are not very good at performing repetitive tasks. When we have to do something more than once, the excitement and attention to detail tend to decrease, making us prone to mistakes. In contrast, computers excel at performing the same task over and over again without altering the output or getting tired, angry, or bored. This is why automating tasks such as testing, building, and releasing software is crucial. For instance, automated tests can help you find bugs reliably on every run, and building a continuous integration (CI) pipeline can streamline the process of executing tests. Similarly, creating a continuous delivery (CD) pipeline can automate the process of releasing software. By automating repetitive tasks, you can free up time and resources to concentrate on adding new value to the project instead of being bogged down with error-prone and boring repetitive work.

Fail fast, release often

Once you have automated repetitive tasks, you can focus on failing fast, getting feedback, and bringing value to your customers. But why is it so important to fail fast? Not knowing it is the worst thing that can happen if you are on the wrong track. Imagine going on a hiking trip and starting in the wrong direction. After six hours of walking, you realize you went in the wrong direction — your day is over. However, if you had asked for directions right away, you would have had a wonderful day in the mountains. The same applies to software development. Fail fast means getting feedback fast and adapting fast, leading to quicker success. One way to fail or succeed fast is to bring small, incremental changes to your customers to evaluate instead of investing months in development and releasing a big feature only to find out that your customers don’t like it.

By failing fast, releasing often, and getting feedback, you can bring value to your customers even faster.   Releases should be a routine, unexciting event, rather than a long-awaited milestone that takes months to prepare for.   We should be releasing code multiple times a day — at least ten deploys a day (according to the book). This sounds impossible? Well, maybe releasing 10 times a day is hard because you have to change not only your technical setup but also the way your team or company is working. However, keep in mind that any increase in your release frequency improves the status quo. We can’t wait months to deliver new features to our customers, especially when we don’t know if they’ll work.

It’s important to note that failing fast does not mean shipping untested products or letting your customers test the application. Rather, it’s about ensuring that you are building a feature that is useful and will be used by your customers. It’s also about testing whether you meet the expectations and fulfill all requirements correctly. So, while failing fast is important, it’s equally important to do so in a way that maintains the quality of your product and meets your customers’ needs.

What’s next?

There is still so much more to learn from the book, and I highly recommend reading it. However, simply gaining knowledge about these improvements is just the first step. Applying them in real-life projects can be quite challenging, but pushing through these challenges and implementing these strategies is important, as the rewards will undoubtedly pay off. Any improvement is better than none, or as Sensei Mike Rother says:

“…that it almost doesn’t matter what you improve, as long as you’re improving something. Why? Because if not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors, zero work-related accidents, and zero loss.” Erik continues, “Sensei Rother calls this the Improvement Kata, he continues. “He used the word kata, because he understood that repetition creates habits, and habits are what enable mastery.””

It’s time to build

At &amp, we are dedicated to delivering high-quality software with our cloud-native development teams. We constantly strive to improve our daily work by applying well-known DevOps principles and other best practices. We’re happy to help you deliver your software projects fast. If you have any questions about our approach or how we can help you, please feel free to reach out to me.

Journey to Conviction: Lessons Learned from ‘Clean Architecture’ for Full-Stack Engineers

From Classroom to Boardroom: Lessons from My Summer Internship

Reflecting on Front-End Architecture Trends: A Journey from Past to Future

• Manage Email Subscriptions
• How to Post to DZone
• Article Submission Guidelines
• Manage My Drafts

A Decade of Kubernetes: Tell us how K8s has impacted your dev journey (and enter for a chance to win $$).

Database Systems: In 2024, the focus around databases is on their ability to scale and perform in modern data architectures. See why.

Data Pipeline Essentials: Dive into the fundamentals of data pipelines and the problems they solve for modern enterprises.

Natural Language Processing: Learn all of the cutting-edge NLP techniques! * Affiliate

• Variance: The Heartbeat of Agile Metrics
• How a Project Manager Can Increase Software Quality With Agile Practices
• Books To Start Your Career in Cloud, DevOps, or SRE in 2024
• Demystifying Agile Development Methodologies: Scrum vs. Kanban
• Evolution of Governance Framework With AI
• Preventing and Fixing Bad Data in Event Streams (Part 1)
• Architectural Patterns for Enterprise Generative AI Apps: DSFT, RAG, RAFT, and GraphRAG
• DORA Metrics: Tracking and Observability With Jenkins, Prometheus, and Observe
• Culture and Methodologies

Book Review: The Phoenix Project

See where you can see some parallels between the work done in the devops transformation of parts unlimited and your own experience..

Join the DZone community and get the full member experience.

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.

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.

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.

Published at DZone with permission of Gunter Rotsaert , DZone MVB . See the original article here.

Opinions expressed by DZone contributors are their own.

Partner Resources

• About DZone
• Send feedback
• Community research
• Advertise with DZone

CONTRIBUTE ON DZONE

• Become a Contributor
• Core Program
• Visit the Writers' Zone
• Terms of Service
• Privacy Policy
• 3343 Perimeter Hill Drive
• Nashville, TN 37211
• [email protected]

Let's be friends:

Continuous Delivery

Book review: the phoenix project.

I am not going to do a ton of book reviews on this blog (I have one more planned for next month). I’ll only bother posting reviews of books that I believe are both excellent and relevant to Continuous Delivery . This book easily satisfies both criteria. Full disclosure: Gene gave me a draft of this book for free for reviewing purposes.

You’ve probably heard of Gene Kim, Kevin Behr and George Spafford before. They are the three amigos responsible for The Visible Ops Handbook , which can be found in the book pile of every good IT operator. Their new book, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win , follows the format of Eliyahu Goldratt’s classic, The Goal .

Told from the perspective of newly-minted VP of IT Operations Bill Palmer, it describes the turnaround of failing auto parts company Parts Unlimited. This is to be achieved through the delivery of the eponymous Phoenix Project, a classic “too big to fail” software project designed to build a system which will revive the fortunes of the company.

To quote (p51):

The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date. The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it’s not worth shipping. And it’s always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just how bad things really are.

Part One of the book describes in loving detail the enormous clusterfuck pie that is baked from these ingredients. The pie is spiced with an internal Sarbanes-Oxley audit which reveals 952 control deficiencies, an outage of the payroll processing system, and various other problems that conspire to deepen the woe of the operations group, all of which are clearly drawn from the deep well of the authors’ real-life experiences.

Apart from the main characters - our hero Bill, his boss Steve, and the evil villain Sarah - The Phoenix Project features a delightful rogues’ gallery which anyone working in an enterprise will recognize:

• Brent Geller, the boy wonder whose encyclopedic knowledge of the company’s Byzantine IT systems means that his involvement is necessary to get anything done.
• Patty McKee, the Director of Support who runs a change management process so bureaucratic that everybody bypasses it.
• John Pesche, the black binder wielding Chief Information Security Officer whose constant meddling under the guise of improving security has turned him into a pariah.

The second part of the book details how the IT group is reborn from the ashes of the Phoenix Project into a high-performing organization that is a strategic partner to the business. This is achieved through the application of a heavy dose of lean thinking (including continuous delivery ) administered by Erik, a mercurial IT and manufacturing guru Steve is courting to join the board. The book does an excellent job of showing - as well as telling - how to apply the concepts (and the effect of doing so) in an enterprise with plenty of technical debt. Perhaps the most eyebrow-raising part of this section is the way in which John has his soul mercilessly crushed to the point where he goes on a multi-day drinking spree before he is rehabilitated towards the end of the book (he is a phoenix too).

John’s narrative arc is just one example of how the book also succeeds as a novel. It’s gripping, with moments of drama and high emotion, as well as some great one-liners. There was even one point when I teared up (bear in mind that I also cried during Forrest Gump - unlike the book’s central characters, I did not serve in the armed forces).

Nobody who has read The Goal will miss The Phoenix Project ’s similarity in terms of style and plot. Perhaps my favourite thing about the book’s pedagogical style is the way Erik (like Jonah in The Goal ) uses the Socratic Method to give Bill the tools to solve his problems by himself. Of course this learning process is fictional, but it means you get to see Bill struggling with the questions and trying things out.

It remains to be seen whether readers of the book will be able to apply these techniques as successfully as Bill without a real Erik to guide them. But of course, this is a limitation of any book. If I had one criticism it’s that unlike real life, there aren’t many experiments in the book that end up making things worse, and it’s this process of failing fast, learning from your failures, and coming up with new experiments that is instrumental to a real learning culture.

One important point worth noting if you are working in an organization like Parts Unlimited is this: the IT department’s rebirth is only possible because of the Titanic proportions of the disaster that unfolds in Part One. For management to truly embrace change, a compelling event or a teachable moment (i.e. a Charlie Foxtrot) is required. Unless your organization faces the same existential threat that Parts Unlimited does, you’ll have a much harder time convincing people they should adopt the tools described in the book.

Overall, The Phoenix Project is a fantastic read. It’s entertaining, cathartic, inspirational and informative. If, like me, you have an enormous backlog of books (and more work in process than you’d like) I suggest giving yourself a break and putting this one to the top of your list. It’ll only take you a day or two, and despite its conceptual density it will leave you feeling refreshed and energized with a bunch of new ideas to try out. The Phoenix Project deserves to be read by everyone who works in - or with - IT.

• Palo Alto Networks
• Cybersecurity
• The Cybersecurity Canon: ...

The Cybersecurity Canon: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

We modeled the   Cybersecurity Canon   after the Baseball or Rock & Roll Hall-of-Fame, except for cybersecurity books. We have more than 25 books on the initial candidate list, but we are soliciting help from the cybersecurity community to increase the number to be much more than that. Please write a review and nominate your favorite. 

The Cybersecurity Canon is a real thing for our community. We have designed it so that you can   directly participate in the process . Please do so!

Book Review by Canon Committee Member, Rick Howard : The Phoenix P roject: A Novel About IT, DevOps, and Helping Your Business Win  (2013)   by Gene Kim, Kevin Behr, and George Spafford

Executive Summary

DevOps is perhaps the most important innovation that has happened to the IT sector since the invention of the personal computer back in the early 1980s. It is the idea that organizations would use the same Agile methodology they use today with their software development teams but expand it across all organizations in the deployment cycle: product managers, marketing professionals, developers, quality assurance practitioners, systems engineers, system administrators, operations staff, database administrators, network engineers and security professionals. The specific concept behind The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win , as well as the DevOps philosophy in general, is that the development, quality assurance, deployment, maintenance and end-of-life of IT systems, to include security updates, is very similar to maintaining a production line of any other product. The best practice that has emerged since WWII to manage production lines is the Toyota Production System. DevOps is the IT version of that system. In it, DevOps practitioners try to reduce technical debt by limiting work in progress in order to control the flow of the entire system. I predict that, in 10 years, we will all be immersed in the DevOps philosophy. Because of the way the authors of The Phoenix Project explain DevOps through the novel form, the ideas are much more accessible to non-IT people: CEOs, CFOs and, yes, CSOs. Because of that quality, it is a must-read book for all C-level executives, including security professionals, and you should have read it by now. 

Introduction

One of the constant problems I hear about in my travels is the tension between network managers, security personnel and the information technology staff. In the best cases, even when the teams get along, the passage of workflow from one team to the next is always cumbersome and inefficient. In the worst cases, one or more of the main groups acts as the Minister of “No” within the organization and hinders the other groups’ desire to upgrade their internal systems. To fix these issues, information technology and security professionals have proposed different organizational schemes to equalize the power dynamic:

• The Chief Information Security Officer (CISO) should report to the Chief Information Officer (CIO).
• The CISO should be a peer to the CIO.
• The CIO should report to the Chief Security Officer (CSO).
• The CSO and the CIO should report to the Chief Executive Officer (CEO) or at least the Chief Operating Officer (COO).

I have been known to partake in those debates myself. [1] But those discussions tend to argue for the idea that one group should be in charge of the other or that they should all be peers. In each case, at least one group is never going to be happy. It seems there should be another way.

The relatively new notion of DevOps (development and operations) emerged out of three converging ideas sometime in late 2009: The Agile Development Method [2]; the 2009 Velocity Conference talk; 10+ Deploys per Day, by John Allspaw and Paul Hammond [3]; and Eric Ries' book, Lean Startup [4] which influenced many Silicon Valley companies between 2007 and 2010. [5] DevOps is the idea that there needs to be a much tighter integration between software developers and information technology operations (IT Ops); that once the developers, the quality assurance teams, and the security analysts pass any new code or maintenance updates to IT Ops for deployment, their jobs are not done. Instead of creating artificial black boxes where updates come in, get worked on, and then are passed to the next black box, DevOps is the recognition that update creation, deployment and maintenance is one big system of systems that needs to be managed that way. It is the idea that organizations would use the same Agile methodology they use today with their software development teams but expand it across all organizations in the deployment cycle: product managers, marketing professionals, developers, quality assurance practitioners, systems engineers, system administrators, operations staff, database administrators, network engineers and security professionals. In other words, DevOps uses the Agile philosophy across the entire lifecycle of deployed systems from design, to development, to testing, to deployment, to maintenance, and finally to end-of-life. [7] This idea elevates IT Operations and Security Operations from being mere support organizations to core competencies within the business.

Some big and successful organizations have adopted DevOps: Google, Amazon, Netflix, Facebook, Microsoft, BNY Mellon, The Gap, Nordstrom, and Northrop Grumman just to name a few.  Experts in the field say that adoption is a key part of their achievement. [8]

DevOps is such a new idea though that defining it precisely is not easy and explaining the potential benefits of this change-of-perspective to executive management and other IT professionals is challenging. Enter The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win. [9] You read that right. The authors wrote a novel to explain the intricacies of DevOps. They got the idea from another iconic book written in the early 1980s, called The Goal: A Process of Ongoing Improvement , where the authors used the novel form to explain the Theory of Constraints. [10]

Parts Unlimited is an automotive parts manufacturer and online retailer that used to be the market leader. In recent times though, the competition has taken the lead in growth and profitability. The company leadership has long promised that a new online program, code-named “Phoenix,” will restore Parts Unlimited to its former glory, but the project is years behind. Investors are pushing for significant leadership changes to right the ship. The company’s board of directors has stripped the chairmanship from the CEO, Steve Masters, and given him six months to show dramatic improvement, or they will take other more strategic and drastic measures, such as splitting up the company. In response, the CEO fired the existing CIO and VP of IT Operations and promoted the hero of the story, Bill Palmer, to interim CIO. That’s the setup.

The story revolves around how Bill, the interim CIO, learns about DevOps from an Obi-Wan-like board member candidate, Erik Reid, and incrementally deploys the philosophy across the company to save it in the nick of time. Through the process, the VP of Application Development, the lead engineer, the Director of Distributed Technology Operations, the CISO, the Director of IT Service Support, the Senior Director of Retail Program Management, the interim CIO, the Chief Financal Officer (CFO) and, ultimately, the CEO, come to realize that DevOps is the most important function of the company. At the end, when Bill succeeds as interim CIO, the CEO decides to groom him to become the company’s COO. In other words, the COO’s main job in Parts Unlimited is to oversee the DevOps function within the organization.

Of course, this book could have been a non-fiction description of DevOps, but that would have been dry and uninteresting to most people. By putting the key elements into novel form, the authors make the technical concepts accessible to a larger audience, not just the technicians of the world but every kind of business leader. The entire C-suite has a part to play in the story as well as all the technical leaders. The authors are trying to teach a wide audience about some fundamental issues that DevOps addresses.

DevOps: Key Concepts

During the story, our Obi-Wan-like board member candidate, Erik Reid, keeps dragging our interim CIO down to the parts manufacturing plant to give him the lesson of the day. Obi-Wan is a parts manufacturing guru and, throughout the story, he keeps trying to explain to the interim CIO that the management of IT Operations should be very similar to streamlining plant manufacturing. Many of the concepts are similar and the problem-solving solutions used in plant manufacturing can and should be applied to IT Operations.

Toyota Kata

The Toyota Car Company has been a profit leader in the auto industry for many years. Several researchers believe that Toyota’s success can be attributed to the Toyota Production System (TPS) that Toyota leaders instituted immediately after World War II. The basic idea is to eliminate waste in every nook and cranny within the company. [11] That is easier said than done, but the TPS way boils down to two katas: one for improvement and one for coaching. The thing about katas is that they are not processes, or information flows, or checklists, or management frameworks. The word “kata” is a martial arts term that describes movement patterns. The martial artist practices them so much that they are second nature; so much so that, when they get into real situations, they do not have to think about what to do. Their muscle memory automatically kicks in. [12]

Researchers and business leaders have studied the TPS for over 40 years. Many books have been published discussing the philosophy, and yet, Toyota continues to innovate and stay ahead of its competitors. [11] One attribution to that consistency is that Toyota thinks about innovation differently from its western competitors. Many in the West think that innovation is a bold new idea that takes the industry in a different direction. Toyota believes that innovation occurs in the score of little improvements made every day by its employees. The company makes millions of them a year because their Improvement Kata and Coaching Kata are second nature to the employees and part of their culture. Not all the improvements work. How could they? But the idea is to try new things, fail fast, and move on to the next. The Phoenix Project borrows heavily from Mike Rother’s book, Toyota Kata , [13] and the idea of continuous improvement is a key concept that our Obi-Wan imparts to our interim CIO. The story begins with Parts Unlimited years behind on the  Project Phoenix: an automation upgrade for their service and support. At the end of the story, Parts Unlimited is rolling out code changes to Project Phoenix ten times a day.

Technical Debt

When you consider that IT Operations is similar to manufacturing plant operations, you start to look at where your employees are spending their time. For instance, you may wonder why the security team can never get all the patches installed. That task seems pretty straightforward. Why is it so hard? One contributing factor is the unintentional deployment of fragile artifacts or systems. Because these systems tend to break down, more and more of the technical staff have to spend time bringing them back online or keeping them online. This effort is called “technical debt.” For every system an organization deploys, the IT Ops staff gets some amount of technical debt that they have to plan for and accommodate. The Toyota Production System attacks technical debt at every opportunity by vigorously trying to reduce it; ruthlessly making their systems less fragile. This activity is the cornerstone of DevOps. The story begins with Parts Unlimited swimming in technical debt. IT Ops can’t get any “real” work done because the team is constantly reacting to emergencies around failing systems.

WIP stands for Work in Progress. In the Toyota Production System, everything from the start of the car production line to the end when a brand-new Toyota rolls out into the world is WIP. According to Stephen Franklin, WIP “refers to all materials and partly finished products that are at various stages of the process.” “Essentially, it’s an investment that has had zero return and depreciates in value over time.” [13]

Everything within WIP represents potential value that has not yet materialized for the customer. It is the same idea with IT Ops. The more things an organization has within WIP, the more things will happen to impede the workflow. It follows, then, that reducing WIP is essential to any organization. Limiting WIP, therefore, makes IT leaders consider the system as a whole. They need to understand how any new work started will affect the capacity of the system. In other words, if they introduce new work at the beginning of the product line, how might that cause bottlenecks in the capacity of the system to continue delivering constant flow?

This idea is a key piece to the DevOps mantra. Instead of applying the Agile software development methodology to the company’s programmers, DevOps applies similar ideas to the entire system: development, quality assurance, deployment, maintenance and end-of-life. This kind of thinking allows IT leadership to discover constraints in the system; things that, because of resource limits, cause bottlenecks in the system’s flow.

In the story, the key constraint that affected everything wasa   Parts Unlimited’s key engineer, Brent Geller. We all have had a “Brent” on our staff. This is the one person who is the go-to engineer for everything. When we need something new, give it to Brent. When something breaks, give it to Brent. When we need to install the latest security patch, give it to Brent. Even though Parts Unlimited had many engineers on staff, Brent always got things done faster. The IT team grew to rely on him for everything and the company’s leadership would cherry-pick him for their pet projects. The more work the company gave Brent, the more WIP they created because he was that one person and everything relied on him to push the workflow. He was the constraint that hindered workflow.

Kanban boards

A Kanban board is a visualization tool to help teams reduce WIP. [14] Toyota invented the tool back when it started developing the Toyota Production System. [15] In order to seek continuous improvement by limiting WIP, Toyota discovered that the task became easier if they could “see” the data and discover where the bottlenecks were. The generic Kanban has three columns: To Do, Doing and Done. Kanban practitioners place various kinds of work on the chart: user stories, defects, tasks, and features. Today, DevOps organizations expand the Doing column into plan, develop, test, and deploy in order to view the entire system. Reducing WIP means that leadership is controlling the amount of work flowing through the system so that it never exceeds capacity. The Kanban board allows leadership to quickly see what is flowing through the system. [15]

There is a subtle difference between this Kanban board idea and the Agile development method’s Scrum idea. A Scrum has regular fixed length sprints. A Kanban board shows continuous flow. A Scrum releases new code every two weeks while the Kanban board emphasized continuous delivery. In a Scrum, no changes occur during a sprint. In a Kanban board, changes happen at any time.

In the story, before the IT Ops leadership team adopted the DevOps strategy, they tried to manage all the work in a system by tracking deadlines. Years before, they paid for and deployed a very expensive ITIL (Information Technology Infrastructure Library) tracking system and relied on project managers to keep the system updated with detailed analysis of each of their projects. They never had the time to do that so the system failed miserably. By adopting the Kanban board system, the entire team could visualize the work moving through the system and make decisions about restricting or increasing the flow.

The Five Dysfunctions of a Team

The authors borrow heavily from Patrick Lencioni’s book, The Five Dysfunctions of a Team: A Leadership Fable . [16] In that book, Lencioni says one of the major reasons that a team fails is lack of trust between team members. He says there are five indicators of this team problem: unwillingness to be vulnerable within the group, cosmetic discussions versus passionate and constructive debate, no accountability, publicly supporting a decision while privately undermining it, and focusing on individual success versus team success. [16] In the story, when the team is days from utter failure, the CEO gathers the team together and walks his way through these indicators. He tells a very personal story about the status of the company; has a pointed discussion about what is really going on; explains to the group that he is accountable for the success or failure of Project Phoenix and will hold his subordinates responsible for their parts; and, finally, he imparts that the team’s success, not individual contributors, will be the thing that keeps the company solvent.

Every time the Obi-Wan-like board member drags the interim CIO down to the production plant, he imparts a new concept of The Way . The Way is a metaphor for continuous delivery. As the story opens, the Phoenix Project is years behind schedule. After the interim CEO adopts The Way , he is able to continuously deploy new code and updates as often as is needed, every day, multiple times a day. The Way consists of three ideas [17]:

• The Flow: Understand how work moves through the system and know that changes will have random effects. Always try to increase the flow but never pass defects downstream.
• Feedback: Understand needs from both internal and external customers. Shorten feedback loops whenever possible.
• Continual Learning: Encourage experimentation and learn from failure. Recognize that the kata will build mastery.

I think that the concept of DevOps is perhaps the most important innovation that has happened to the IT sector since the invention of the personal computer back in the early 1980s. By forcing IT leadership and network defenders alike to consider the production system as a whole, to get us out of our stovepipe concerns for our individual projects, and to make collective decisions for the good of the organization that we work for, the community has invented The Way of continuous improvement for all parties involved. IT practitioners are most likely aware of the concept but my guess is that many security practitioners are not. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is an introduction to the subject. I predict that, in 10 years, we will all be immersed in the DevOps philosophy. Because of the way that The Phoenix Project authors explain DevOps through the novel form, the ideas are much more accessible to non-IT people: CEOs, CFOs and, yes, CSOs. Because of that quality, it is a must-read book for all security professionals, and you should have read it by now.

[1] " The Evolution of the Cybersecurity Executive Trifecta: The CSO/CIO/CISO ," by Rick Howard, RSA Conference, 21 April 2015, Last Visited 24 September 2016,

[2] " To agility and beyond: The history—and legacy—of agile development ," by Peter Varhol, TechBeacon, 26 August 2015, Last Visited 24 September 2016,

[3]" 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr ," by John Allspaw and Paul Hammond, Velocity 09, 25 July 2009, Last Visited 23 September 2016,

[4]" The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses ," by

Eric Ries, Published January 1st 2011 by Crown Business, Last Visited 23 September 2016,

[5] " The Convergence of DevOps ," by John Willis, IT Revolution Press: Helping Spark the Cambrian Explosion, Last Visited 11 August 2016,

[6] Deleted

[7] " What is DevOps? " by Ernest Mueller, the agile admin, 2 August 2010,  Revised 16 January 2016, Last Visited 11 August 2016,

[8] " Keynote PuppetCon 2014: The Phoenix Project: Lessons Learned - Gene Kim, IT Revolution Press (Vimeo repost) " by Gene Kim, YouTube, 9 October 2014, Last Visited 10 August 2016,

[9] " The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win ," by Gene Kim, Kevin Behr, and George Spafford, Published  by IT Revolution Press, 10 January 2013, Last Visited 28 July 2016,

[10] " The Goal: A Process of Ongoing Improvement ," by by Eliyahu M. Goldratt, and Jeff Cox, Published 1982 by North River, Last Visited 23 September 2016,

[11] " THE OPEN SECRET OF SUCCESS: Toyota Production System ," by James Surowiecki, The New Yorker, THE FINANCIAL PAGE, 12 MAY 2008, Last Visited 24 September 2016,

[12] " Toyota Kata: the 'how; of 'engaged leadership ,' " by Mark Rosenthal, The Lean Thinker: Thoughts and insights from the shop floor, 28 June 2010, Last Visited 24 September 2016,

[13] " Toyota Kata: M anaging People for Improvement, Adaptiveness and Superior Results," by Mike Rother, Published by McGraw-Hill Education, 1 September 2009 (first published 2009)

[14] " What is A Kanban Board? " by Leant, Last Visited 11 August 2016,

[15] " A brief introduction to kanban: What software makers can learn from Japanese manufacturing ," by Atlassian, Last Visited 11 August 2016,

[16] " The Five Dysfunctions of a Team: A Leadership Fable ," by Patrick Lencioni, Published by Jossey-Bass, 11 April 2002 (first published January 1st 2002), Last Visited 10 August 2016

[17] " Limited WIP Meeting presentation - The Phoenix Project book review ," by Rudiger Wolf,  LinkedIn SlideShare, 26 November 2013, Last Visited 10 August 2016,

" Book review: the Phoenix Project. " by skeptic, The IT Skeptic, 22 January 2013, Last Visited 10 August 2016,

" Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Martin Fowler Signature Book) ," by Jez Humble and David Farley, Published by Addison-Wesley Professional, 27  July 2010, Last Visited 11 August 2016,

" Itil Service Support ," by Central Computer, Published by Stationery Office Books (TSO), 1 March 2000, Last Visited 11 August 2016,

" Kanban 101: How to Use Kanban Boards to Manage Your Next Project ," BY DANNY SCHREIBER, zapier, Last Visited 11 August 2016,

" Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) ," by Michael T. Nygard, Published by  Pragmatic Bookshelf, 30 March 2007, Last Visited 11 August 2016

" The Visible Ops Handbook: Implementing Itil in 4 Practical and Auditable Steps ," by Kevin Behr, Gene Kim, and George Spafford, Published by Information Technology Process Institute, 2004, Last Visited 11 August 2016

" Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps ," by Gene Kim , Paul Love, and George Spafford, Published by It Process Institute, 17 March 2008, Last Visited 11 August 2016,

" Where To Learn More About Concepts In “The Phoenix Project ” (Part 1)," by Gene Kim, IT Revolution Press, Last Visited 10 August 2016

" WIP Limits: How to Journey Safely Into the Unknown (Part 1 of 3) ," by  Stephen Franklin, leankit, 18 March 2014, Last Visited 25 September 2016,

Related Blogs

Announcement , cybersecurity , cybersecurity canon , next-generation firewalls, and the 2017 cybersecurity canon winners are…, cybersecurity , cybersecurity canon, the cybersecurity canon: site reliability engineering: how google runs production systems, cybersecurity , cybersecurity canon , points of view, cybersecurity canon candidate book review: “abundance: the future is better than you think, the cybersecurity canon - american kingpin: the epic hunt for the criminal mastermind behind the silk road, we’re down to the last two contestants in the 2018 cybersecurity canon people’s choice awards, 2018 cybersecurity canon people’s choice awards: the final four, subscribe to the blog.

By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement . Please look for a confirmation email from us. If you don't receive it in the next 10 minutes, please check your spam folder.

Get the latest news, invites to events, and threat alerts

By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement .

Products and Services

• Network Security Platform
• CLOUD DELIVERED SECURITY SERVICES
• Advanced Threat Prevention
• DNS Security
• Data Loss Prevention
• IoT Security
• Next-Generation Firewalls
• Hardware Firewalls
• Strata Cloud Manager
• SECURE ACCESS SERVICE EDGE
• Prisma Access
• Prisma SD-WAN
• Autonomous Digital Experience Management
• Cloud Access Security Broker
• Zero Trust Network Access
• Code to Cloud Platform
• Prisma Cloud
• Cloud-Native Application Protection Platform
• AI-Driven Security Operations Platform
• Cortex XSOAR
• Cortex Xpanse
• Cortex XSIAM
• External Attack Surface Protection
• Security Automation
• Threat Prevention, Detection & Response
• Threat Intel and Incident Response Services
• Proactive Assessments
• Incident Response
• Transform Your Security Strategy
• Discover Threat Intelligence
• Corporate Responsiblity
• Investor Relations

Popular Links

• Communities
• Content Library
• Event Center
• Manage Email Preferences
• Products A-Z
• Product Certifications
• Report a Vulnerability
• Do Not Sell or Share My Personal Information

Get the Reddit app

The phoenix project is a terrible book..

I know everyone on this sub suggests this book, as well as people on my team. The concepts in book are fantastic at a high-level, but the book itself is terrible. The characters are insufferable and I hated almost everyone in the book. It also came off as borderline sexist on the depictions of the women characters in the book. The amount of grammar mistakes made it difficult to read and I am NOT the best at grammar. It truly just felt like some IT fan fiction that was terribly written. I feel like this book could’ve been summarized in 30 pages vs these 300+ pages of fluff.

If you want a terribly written book to understand DevOps, this is the book for you. Otherwise, I think it’s one of the worst books I’ve ever read.

Edit: I do expect to be downvoted to oblivion for this review, but my feelings still stand about it.

By continuing, you agree to our User Agreement and acknowledge that you understand the Privacy Policy .

Enter the 6-digit code from your authenticator app

You’ve set up two-factor authentication for this account.

Enter a 6-digit backup code

Create your username and password.

Reddit is anonymous, so your username is what you’ll go by here. Choose wisely—because once you get a name, you can’t change it.

Reset your password

Enter your email address or username and we’ll send you a link to reset your password

Check your inbox

An email with a link to reset your password was sent to the email address associated with your account

Choose a Reddit account to continue

• Business & Money

Sorry, there was a problem.

Download the free Kindle app and start reading Kindle books instantly on your smartphone, tablet, or computer - no Kindle device required .

Read instantly on your browser with Kindle for Web.

Using your mobile phone camera - scan the code below and download the Kindle app.

Image Unavailable

• To view this video download Flash Player

Follow the authors

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win Hardcover – January 10, 2013

• Part of series The Phoenix Project
• Print length 345 pages
• Language English
• Publisher IT Revolution Press
• Publication date January 10, 2013
• Dimensions 7 x 1.25 x 9.75 inches
• ISBN-10 0988262592
• ISBN-13 978-0988262591
• See all details

Products related to this item

Editorial Reviews

About the author.

Gene Kim is a multi-award winning CTO, researcher, and author. He is the founder of Tripwire and served as CTO for thirteen years. His books include The Phoenix Project, The DevOps Handbook, The Visible Ops Handbook, and Visible Ops Security .

Kevin Behr is the founder of the Information Technology Process Institute (ITPI) and the general manager and chief science officer of Praxis Flow LLC. Kevin has 25 years of IT management experience and is a mentor and advisor to CEOs and CIOs. He is the co-author of The Phoenix Project and The Visible Ops Handbook.

George Spafford i s a research director for Gartner, covering DevOps, technical change, and release management, in addition to the use of bimodal IT and the pace-layered application strategy. His publications include hundreds of articles and numerous books on IT service improvement, as well as co-authorship of The Phoenix Project, The Visible Ops Handbook, and Visible Ops Security .

Product details

• Publisher ‏ : ‎ IT Revolution Press; First Edition (January 10, 2013)
• Language ‏ : ‎ English
• Hardcover ‏ : ‎ 345 pages
• ISBN-10 ‏ : ‎ 0988262592
• ISBN-13 ‏ : ‎ 978-0988262591
• Item Weight ‏ : ‎ 1.38 pounds
• Dimensions ‏ : ‎ 7 x 1.25 x 9.75 inches
• #153 in Production & Operations
• #154 in Computers & Technology Industry
• #2,087 in Business Management (Books)

Videos for this product

Click to play video

Must Watch Before You Buy

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

Amazon Videos

About the authors

Kevin Behr is the founder of the Information Technology Process Institute (ITPI) and the Chief Strategist for the CIO and Board Advisory Practice at Assemblage Pointe, where Kevin has built a unique consulting practice that mentors and coaches IT organizations to increase their business effectiveness and competitive advantage now and over the long term through the application of improvement sciences..

As a trusted mentor and advisor to chief executive officers and chief information officers around the world, Kevin blends his 25 years of IT management experience with his skills as a communicator, collaborator and synthesist to deliver powerful solutions to everyday business problems. He has held the post of CTO and CIO at companies ranging from public corporations to nimble technology start-ups. He is the author of several IT management books, including the exciting new business novel The Phoenix Project in tandem with the same author team as the bestselling Visible Ops Handbook, which he also coauthored with Gene Kim and George Spafford, and The Definitive Guide to IT Management, published by Hewlett Packard.

Kevin is a very popular keynote speaker and is frequently called on to address a broad range of technology and management topics by organizations such as the National Academy of Sciences, Hewlett-Packard, the SANS Institute, AFCOM and The IT Service Management Forum.

George Spafford

George is a Research Director for Gartner covering process improvement in IT operations that leverage best practice references such as ITIL, COBIT, ISO/IEC 20000 and so forth. He is a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall service improvement in the U.S., Canada, Australia, New Zealand and China. His publications include co-authorship of “The Phoenix Project”, “The Visible Ops Handbook", “Visible Ops Security” and the IIA Information Security Governance guidance. His current areas of research include service design, complexity and operational processes.

Gene Kim is a multiple award-winning CTO, researcher and author, and has been studying high-performing technology organizations since 1999. He was founder and CTO of Tripwire for 13 years. He has written six books, including The Unicorn Project (2019), The Phoenix Project (2013), The DevOps Handbook (2016), the Shingo Publication Award winning Accelerate (2018), and The Visible Ops Handbook (2004-2006) series. Since 2014, he has been the founder and organizer of the DevOps Enterprise Summit, studying the technology transformations of large, complex organizations.

In 2007, ComputerWorld added Gene to the “40 Innovative IT People to Watch Under the Age of 40” list, and he was named a Computer Science Outstanding Alumnus by Purdue University for achievement and leadership in the profession.

He lives in Portland, OR, with his wife and family.

Customer reviews

• 5 star 4 star 3 star 2 star 1 star 5 star 72% 21% 5% 1% 1% 72%
• 5 star 4 star 3 star 2 star 1 star 4 star 72% 21% 5% 1% 1% 21%
• 5 star 4 star 3 star 2 star 1 star 3 star 72% 21% 5% 1% 1% 5%
• 5 star 4 star 3 star 2 star 1 star 2 star 72% 21% 5% 1% 1% 1%
• 5 star 4 star 3 star 2 star 1 star 1 star 72% 21% 5% 1% 1% 1%

Customer Reviews, including Product Star Ratings help customers to learn more about the product and decide whether it is the right product for them.

To calculate the overall star rating and percentage breakdown by star, we don’t use a simple average. Instead, our system considers things like how recent a review is and if the reviewer bought the item on Amazon. It also analyzed reviews to verify trustworthiness.

Customers say

Customers find the book wonderful, easy to read, and with good concepts. They also describe the writing style as easy to understand, recognizable, and entertaining. Readers also appreciate the storyline, which provides a realistic view of what types of reactions to expect.

AI-generated from the text of customer reviews

Customers find the book wonderful, educational, and worth every moment. They also say it's a very solid book that provokes thinking about business problems.

"...Overall, I recommend this book. Its both a good read with an interesting , if unusual, story to tell, and certainly capable of getting one to think..." Read more

"...to allow for rapid development and deployment of secure, quality-tested products as well as aiding in automation of these products/software...." Read more

"== Summary ==This is an excellent novel explaining how things go on IT projects and departments...." Read more

"Props to goodwill. Product was labeled as 'acceptable' and came in very good condition ...." Read more

Customers find the book has good concepts and would recommend it to other people working in IT. They say the story informs, educates, and provides a jumping-off point for IT organizations. Readers also say the book is a clever pointer to the way forward. They mention it's entertaining and even cathartic read.

"...Goal and OPT movement almost 30 years ago this book is a clever pointer to the way forwards - starting from where at least many firms would..." Read more

"...avoids stereotypes - the characters are well-defined and have actual motivations ...." Read more

"...This book is essential for IT organizations as it uses real examples to show the problems IT groups face, how to overcome those challenges, and how..." Read more

"...The book is insightful , easy to read (for anyone used to IT terms and words) and very well written.== Pros ==*..." Read more

Customers find the writing style easy to read, and accessible to a wide audience. They also say the book does a great job explaining the theory and providing an easy way for non-business people to understand.

"...a humorous reminder of how bad and fragile IT can be, and a good mindset for how an org that gets a lot done should operate. Recommend." Read more

"...== Pros ==* Very well written novel with a perfect picture of a messed-up IT department* Is based on real cases*..." Read more

"...book in my memory -- is that the way he does this is incredibly accessible to a broad set of people from a broad set of technology disciplines...." Read more

"What a great way to introduce and teach some fairly complex theory...." Read more

Customers find the storyline easy to understand, convincing, and interesting. They also appreciate the nice capture of real life in IT and the laying bare of wasted effort, inefficiencies, and bottlenecks.

"...Its both a good read with an interesting, if unusual, story to tell , and certainly capable of getting one to think about the right ways to approach..." Read more

"...Real-life examples make the book relatable ...." Read more

"... This book is descriptive and is to be followed by the proscriptive DEV/OPS Cookbook...." Read more

"...The story informs , educates and provides a jumping-off point for those seeking additional knowledge in the fields of Lean IT and Agile..." Read more

Customers find the book entertaining, exciting, and riveting. They also say it's an amazing book for introducing anyone to DevOps, with funny moments.

"...For me this was a humorous reminder of how bad and fragile IT can be, and a good mindset for how an org that gets a lot done should operate...." Read more

"...It'll be easy. It's riveting )..." Read more

"...Do not expect a literary writing but a very enjoyable fairy tale for nerds with a moral that hints you neatly to plenty of possible solutions..." Read more

"...I found it very engaging and definitely wanted to read the whole thing all in one sprint...." Read more

Customers have mixed opinions about the characterization in the book. Some find the characters relatable and quirky, while others say they're unimagined.

"...His quirky personality works extremely well - picturing him as the Yoda of the novel wouldn't be entirely far off...." Read more

"...have the characters stand for a particular IT mindset resulted in all characters being cliched ; Gene occasionally hits the reader over the head with..." Read more

"...The cast is spot-on . Each is clearly meant to represent a specific organizational perspective or archetype...." Read more

"...The characters are fleshed out and easy to empathize with...." Read more

Customers are mixed about the emotional intensity of the book. Some find it painfully entertaining, gripping, and disturbing. Others say it's stressful, depressing, and scary too close to real life.

"...There is a large element of vicarious pain and frustration , but the doses are followed with quick wins and encouragements which maintain the..." Read more

"...The book manages to explain the angst , lay bare the wasted effort, inefficiencies and bottlenecks, and no matter your shop, you'll find analogies at..." Read more

"...It felt like a punch in the gut . I started sweating, I felt like I was going to throw up...." Read more

"...with strawmen corporate types makes this for a boring and stressful novel . We have Bill, the main character...." Read more

Reviews with images

This is a great book. I really like it.

• Sort reviews by Top reviews Most recent Top reviews

Top reviews from the United States

There was a problem filtering reviews right now. please try again later..

Top reviews from other countries

• Amazon Newsletter
• About Amazon
• Accessibility
• Sustainability
• Press Center
• Investor Relations
• Amazon Devices
• Amazon Science
• Sell on Amazon
• Sell apps on Amazon
• Supply to Amazon
• Protect & Build Your Brand
• Become an Affiliate
• Become a Delivery Driver
• Start a Package Delivery Business
• Advertise Your Products
• Self-Publish with Us
• Become an Amazon Hub Partner
• › See More Ways to Make Money
• Amazon Visa
• Amazon Store Card
• Amazon Secured Card
• Amazon Business Card
• Shop with Points
• Credit Card Marketplace
• Reload Your Balance
• Amazon Currency Converter
• Your Account
• Your Orders
• Shipping Rates & Policies
• Amazon Prime
• Returns & Replacements
• Manage Your Content and Devices
• Recalls and Product Safety Alerts
• Registry & Gift List

• Conditions of Use
• Privacy Notice
• Consumer Health Data Privacy Disclosure
• Your Ads Privacy Choices

Nextgen Builders

Location & Hours

Suggest an edit

705 E Covey Ln

Phoenix, AZ 85024

Ask the Community

Ask a question

Yelp users haven’t asked any questions yet about Nextgen Builders .

Recommended Reviews