The Phoenix Project – Book

Overall 9/10 – Highly engaging easily-read book for software developers.

Interesting book that uses a story about an IT manager getting promoted and being responsible for a team as a way to explain lean/agile concepts. Working in IT a relatively long period now I guess most the scenes are basically from somewhere I’ve worked which is nice that it’s realistic but perhaps shows the book would be more useful for those newer to software development.

Small Topics

The book covers a wide range of topics in varying levels of detail. While quite succcessfully tying them together into one story.

• Incompetent management – Few bad employees making trouble. Useful to hear of scenarios but characters were shallow though served their purpose.
• Issue prioritization – kanban and prioritize issues that fix the bottleneck only. Bill re-discovers kanban from manual post-it note creation. How to decide whether a project is worthwhile, the company projects should return >10% rate of return in time period.
• Releases – Bad change release procedures, continuous deployment
• Change Management – Allow all minor/low risk automatically, only monitor medium and require manual intervention of high risk items. Else you’ll never survive.
• SDLC/Kanban – Things are only done when deployed, anything else is WIP that should be avoided. Smaller iterations = lower risk
• One Genius – How to reduce reliance on 1/2 great developers and spread work over a team
• Types of Work – Business projects, Internal Projects, Changes and Unplanned Work! Last one is very dangerous as it throws off planning.
• Dev vs Ops – Shouldn’t be separate but working together.
• Teams – Need trust and mutual respect.
• Minimizing WIP is essential – Nice analogy of a factory with parts and Work In Progress building up showing how that can actually slow progress.

Key Takeaways for Me

The Three Ways

1. left to right flow of work – small batch sizes, never pass defects downstream and constantly optimize for global goals. Limit work in progress.
2. right-to-left – have constant fast feedback to ensure to prevent problems. Stop the production line if going wrong.
3. Foster a good culture – Encourage constant experimentation and risk taking. But understand that practice and repetition pre-requisite to mastery. High trust is essential.

Percent Busy and Waiting Times

We’ve all relied on a chain of people/teams or systems and wondered why simple changes take so long. This graph goes some way to explaining it: