Thoughts on "The Phoenix Project"

By Adam Tuttle on Nov 28, 2021

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.

My Review

If it wasn't for the —frankly, fucking offensive— callously negative attitude toward "developers" in the first few chapters of the book^[1], 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!^[2])

My Notes

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

1. Business Projects
2. Internal Projects
3. Changes (bug fixes, improvements generated by the first two types)
4. 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

Kanban Boards

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:

1. systematizing the bottleneck so more people can share the load
2. automating what can be automated
3. 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.

1. The First Way: Continuously find and implement ways to improve delivery. (Kaizen)
2. The Second Way: Shorten feedback cycles to get advance warnings of impending failures. Work signals from strongest to weakest.
3. 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.