The Phoenix Project summary

Phoenix is supposed to deploy in ten days – but only three of the project’s 12 final tasks are done, because the IT department has been handling emergency issues.

More accurately, Brent, its lead engineer, has been handling them. Poor Brent. Bill doesn’t understand how one guy seems to be bolstering the entire organization. He’s a wunderkind at solving any problem he’s hit with. And so he’s hit with them all.

It’s a few days before Phoenix’s deployment, and the project management meeting isn’t going well. Despite Bill’s request for more time, Sarah from Retail Operations is pushing for the launch to go ahead as planned. When she accuses the IT Operations team of dragging its feet, Bill takes a deep breath.

He’s seen this movie before. A project’s shipment can’t be delayed because of promises made to customers or Wall Street. The developers usurp the schedule, leaving no time for proper operations testing. As a result, absurd shortcuts are made – and the final software product is often unstable or even unusable. Who has to pull all-nighters, continuously rebooting servers and adhering metaphorical Band-Aids to offset shoddy code? IT Operations.

Bill tries to implement Erik’s lessons. But Steve, the CEO, intervenes; he insists on doing things the old way, according to the impossible timeline. As expected, the Phoenix launch fails spectacularly. And Bill doesn’t bat an eye.

Instead, he quits.

The leadership meeting doesn’t solve everything – but that’s not the point. Bill sees that what the team has now is even better: a shared vision as they move toward a solution. It’s time for everyone to work together. It’s time, Erik says, for DevOps: a set of practices that integrates software development – “Dev” – and IT operations – “Ops.”

Today, DevOps is doing for IT what the industrial revolution did for manufacturing. Instead of optimizing the process of turning raw materials into finished goods, DevOps shows how to upgrade the IT value stream – that is, speed up time to market, create more flexible and resilient systems, and integrate tests to quickly probe potential innovations.

A 2007 Suzuki Hayabusa dragster motorcycle is a thing of beauty, Erik says. It can go over 230 mph. It has a six-gear constant mesh box and a #532 chain drive. What it does not have is a reverse gear.

He’s trying to make a point. Like the high-speed motorcycle, IT’s workflow shouldn’t have a reverse gear. Work that moves backward – a result of defects or ambiguity – is literally waste. Ideally, the flow of work should go in just one direction: forward.

Bill is gazing at his shiny new laptop. His applications and data are all there, his email is functioning, every piece is intact – in short, it works perfectly. If Bill’s old laptop was a metaphor for everything that was wrong with Parts Unlimited, his new laptop represents everything his team has accomplished together in the past few months.

SEV1 outages are down by two-thirds, and incident recovery time has been cut in half. The ticketing system has been purged of unnecessary work. There’s a standardized environment creation process – or build procedure – to keep Development and Operations in sync and remove variance.