Thoughts on "The Phoenix Project"
At the recommendation of one of my podcast co-hosts, Ben Nadel, I read The Phoenix Project last week; and I thought I would share both my review of the book, and some notes that I took to refer back to later.
If it wasn't for the —frankly, fucking offensive— callously negative attitude toward "developers" in the first few chapters of the book, I might have even given it 5 stars in my review. Instead, I gave it 4 stars.
My approach to reading books is often feast or famine. If I'm really into it then I can't put it down and I'll finish it in just a couple of days. If I'm forcing myself to read it for some reason even though I'm not truly enjoying it then I might only pick it up for an hour or two per week. TPP falls into the former category. I actually stayed up past midnight (I usually go to bed around 9:30) to finish the last few chapters. So while the book had some issues, I have to say that I greatly enjoyed it.
And there is no doubt in my mind that I enjoyed it more than I would have enjoyed some drab "Why and How To Agile" book. Using a fictional novel to illustrate the concepts is kind of brilliant, if a touch contrived.
I don't think the average non-IT person would really care for it. They would probably come away wondering what makes the idea of Kanban so exciting. But for those of us working at companies that sometimes can't seem to keep from aiming a gun squarely at its own foot, it also offers some catharsis.
That said, there be dragons here. Remember that spending time setting up tools and processes that are supposed to help you do more and better work is a useless distraction if keeps you from doing the work. Put another way: it's more fun to setup processes for doing work than it is to do work. There's a trap there, so don't fall into it.
All in all, I'm really glad I read it and I will probably read it again. I'd like to add more detail to the notes I was able to cobble together the day after finishing the book. This was yet another example of a book that I wished I would have known how much I'd like it in advance so that I could be prepared to take notes as it happens. Alas, reading again will have to do.
There's also a sequel, which I've started reading but I'm not very far into yet. So far it seems like an Ender/Bean situation: Mostly the same timeline but told through someone else's eyes. (A developer!)
As I said previously, I intend to refer back to these notes in the future when and as they might be helpful in my career. To separate them from my review above, and also because I needed an excuse to play with Notion, I have also made this public notion page containing only my notes.
The 4 Types of Work
- Business Projects
- Internal Projects
- Changes (bug fixes, improvements generated by the first two types)
- Unplanned work — the most dangerous
WIP ("whip") ~ Work In Progress
What drags everything down is clutter of unfinished projects. Keeping too many balls in the air results in more time spent keeping them all from hitting the ground than working on them.
Formula for Wait time = % busy / % idle
- 50% busy / 50% idle = 1 unit of wait time
- 90% busy / 10% idle = 9 units of wait time
- 99% busy / 1% idle = 99 units of wait time
Visualize everything on everyone's plate. We too easily get sucked into juggling invisible tasks which causes slippage and demoralizes. Making all tasks visible creates the opportunity to prioritize and defer.
10 Deployments per Day
Less about actually completing enough work to need 10 deployments/day and more about having the agility to be able to respond that rapidly when the need arises. If you can deploy 10x daily then your deploys are automated, fast, and reliable.
The Theory of Constraints
Identify bottlenecks and work to prevent a backup of WIP behind them, by:
- systematizing the bottleneck so more people can share the load
- automating what can be automated
- using proper work queues instead of treating whoever yells the loudest as a VIP
The 3 Ways
Maximize value delivery by optimizing workflows. "Value" is anything a customer finds useful.
- The First Way: Continuously find and implement ways to improve delivery. (Kaizen)
- The Second Way: Shorten feedback cycles to get advance warnings of impending failures. Work signals from strongest to weakest.
- The Third Way: Use the efficiencies of The First Way and the safety net of The Second Way to introduce rapid experiments that could provide significant gains. Be willing to try 30 ideas to find 1 that succeeds. Make those 30 ideas tiny to keep the feedback cycle fast.
"Developers" get suprisingly little attention and treatment for a book about "dev-ops" but to be fair, the story makes its points without them. Of course there are developers out there that have the completely brazen and careless attitudes depicted in The Phoenix Project, but even the smallest dose of nuance would point out that "developer" is not a synonym for "careless cowboy". It was only 2-3 offhand remarks from the protagonist, but clearly it left an impression on me. ↩︎