This is a repost of from my blog at, originally from 2015

Over the summer I read The Phoenix Project. An amazing story about someone who was in a situation similar to myself when I took over leading the team at work. The book has quickly made its way through the team and has turned us all onto the amazing world of DevOps.

Book Summary

CAUTION: This part will obviously contain spoilers

The book tells the story of Bill, a director who finds himself being shoved into the position of vice president of IT operations after his old boss gets fired. The company he works for isn’t doing too well and is putting all its effort into a new project that will rebirth the company The Phoenix Project.

Bill finds himself in the position of ensuring that the project gets the up-most attention from the IT team but he also finds himself inheriting a team burdened with operational issues. These issues involve dealing with team members who take on all the work (and thus become the constraint in the team), issues with managing work, defining & following processes and dysfunctional relationships with a number of internal & external teams.

Via the sage like wisdom of Erik, a new board member at the company Bill learns about Kanban, the theory of constraints and a number of other Lean & agile methodologies. By getting the team to flow and ensuring the work flow is visualised and then finally shortening the handover between development & operations Bill is then able to get everything under control.

The Impact The Phoenix Project Has Had At Work

After reading the book myself while on holiday I came back and got a few colleagues to read it. We had a small working knowledge of Kanban but very little exposure to Lean and the theory of constraints. The book really helps people understand the way they’re working and the way the team functions, this may have lead to some ‘Brent’ name calling too.

Since then we’ve held a number of Lean workshops internally so we as a team understand the 7(8) wastes, 5 Ss and other concepts that allow us to ensure we’re building a quality product. This has lead to a number of Kaizen Blitzs during which we have improved the way we use our Kanban board & Wiki (practising the Standardise and Sort parts of the 5 Ss) and we have more lined up.

The book has also lead to me & the team reading a lot more books such as The Visible Ops Handbook, Continuous Delivery, Kanban In Action, and Software Development Metrics. This has lead to a culture of self improvement through learning and we’re now in a position to start paying off our technical debt which we were nowhere near before.

I’ve also been doing a lot of projects on improving the communication and visualisation of work such as getting the data out of our Kanban board to show the lead time & cumulative flow so we can understand the flow of work better. I’m also planning a series of Katas for the team to practice and learn the different aspects of the pipeline such as testing, CI and deploying code.

TLDR; The Phoenix Project explains the core principles behind the DevOps movement through the medium of a story we can all relate to

Written by

Technical Lead at BJSS. Interested in Automated Testing, Dev practises, Metal, Chiptune. All views my own.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store