by Leon Rosenshein

Dev Ops Book Club

The Phoenix Project, Accelerate The Dev-Ops Handbook, and recently, The Unicorn Project. Two novels and a two how-to books backed by research. Full disclosure, the novels, as novels aren't that good. Character development is shallow, the plot moves at the speed of the message, and there are more stereotypes than you can shake a stick at.

However, if you can get past that there's some really good information in all of those books. At the top of the list are the 4 kinds of work (Phoenix) and 4 key metrics (Accelerate). They're at the top, not for themselves, but for what they drive, which is Value or impact. If what you're doing doesn't have value it doesn't matter how well you're doing it. You're wasting your own and other's time.

The 4 kinds of work are:

  • Business Projects - The things your customers ask for
  • Internal Projects - The things you do to make your life easier
  • Operational Changes - The work you do between finishing something and seeing value, deploying things
  • Unplanned Work  - Things you need to do right now. The kind of work the on-call is doing. Dealing with failures, bugs, and sudden changes in plans.


The 4 metrics are:

  • Lead Time for changes - The time between a request coming in and customers seeing the change
  • Deployment Frequency - How many times you can deploy on any given day
  • Mean Time to Recovery - Average time to recover from a failure
  • Change fail percentage - The percentage of changes that fail to work as designed


There are also other operational things mentioned and explained that help achieve those goals while delivering value. Things like customer focus, developers finding joy from getting into the flow, improvement of daily work, and minimizing work in progress (WIP). The first one is key to making sure you're not wasting your time and truly adding value.

That last one is also interesting and something my boss and I appear to have divergent views on, but really, that's not the case. He likes to minimize WIP. Do one thing, finish it, then do the next. And generally speaking, I agree with him. Sometimes there are good reasons to not do that. But that's a discussion for another day.