I don't need any convincing that lean manufacturing or Theory of Constraints can be applied to software development. And I certainly don't need any convincing that continuous delivery magnifies the entire capabilities of an organisation. Yet I still thoroughly enjoyed the Phoenix Project which sets out to teach those things.
Following the format of The Goal, The Phoenix Project tells the dramatic tale of a failing organisation. And just like the goal, a bunch of modest workers become heroes on their way to rescuing the organisation, guided by a quirky main character who learns about lean engineering practices.
I enjoyed The Goal more, I think it's a more compelling story and a better book, but for many people, The Phoenix Project is actually the one they should read...
Convincing Your Colleagues with the Phoenix Project
The group of people I see most benefitting from The Phoenix Project are those who rely on IT & software developers to get their job done.
We're pretty good at preaching about continuous delivery, test-driven development and delivery pipelines. But most of the time we look like a bunch of geeks who want to play with our new toys.
Finance, marketing, everyone else in the organisation just wants to get their job done, and they usually have a very strong reaction to software developers who always bring them pain.
So I think, for those non-IT people, this book could really be a game-changer for them. This book can show them how continuous delivery really is something revolutionary they need to devote a lot of resources to achieving. This book will show them it's not just the latest craze software developers want on their CV.
Pulls Together a lot of Relevant Information
Whilst the story underlying The Phoenix Project is genuinely entertaining, what impresses me the most is how the authors pulled together this holistic view of how organisations and IT should be inseparable.
From digging deep into business needs and creating a transparent list of priorities shared with IT staff, to relentlessly chipping away at cycle times to deploy software 10 times a day, this book tries to show the entire flow of needs and information from the CEO to the junior developer.
I find it so impressive that the authors can put together this coherent view spanning from the very top of the organisational hierarchy to the very bottom, showing techniques and patterns that can be used to create alignment, autonomy, and improved flow at every level.
Admittedly, there isn't a mass of detail on how to do agile financial planning, or strategies for writing unit tests, but all of the key areas are covered.
Readers of The Phoenix Project are left with a broader understanding of the organisational landscape and a desire to optimise their entire value chain. Reason enough for anyone to pick up a copy.