The Zen of DevOps

A review of The Phoenix Project
Book Reviews
Last Blog | Index | Next Blog


9 August 2017

When I was given The Phoenix Project last year, I kind of thought it was goofy and looked dumb. A book about DevOps? Really? Why would I want to read that. Still, people at the Nashville DevOps raved about it. So it's been in my pile to read for a little while now. And I wish I'd read it sooner! For anyone in IT tried to manage communication with the business, setting and achieving realistic development goals, finding a successful deployment rhythm, and keeoing the lights on, this book gives some excellent perspective.

My only complaint about the book is that everything works out too nicely with the business. I've done the Jerry McGuire "it's not a memo, it's a mission statement thing". It turned out about like it did in Jerry McGuire, with my being escorted out of the building. If you find a team that values honesty, then radical candor can work, but if the board has been promised 2+2=20 and the CEO believes 2+2=20 things just aren't going to work out for you to keep insisting that it's 4.

The book outlines 4 types of work:

  • Business Projects
  • Internal IT Projects
  • Changes
  • Unplanned Work
Which provides a good framework for discussing the different types of work IT deals with. It's often easy for the rest of the business to understand the first and maybe the second type, but the other two don't often get enough support behind them. I've seen firsthand what happens when everybody can make untracked changes - unplanned work to fix it happens all over the place stalling business projects that could generate more revenue!

One thing the book kept harping on that I don't think I understood well enough before was minimizing work in progress (WIP). I've always kinda thought the Kanban limit on the "in progress" column to be a little silly, but I'm rethinking that now. Understanding that bottlenecks in the development and deployment ecosystem are the real rate limiting factors to a team was also an eye-opener.

Things start to get a little more zen with "The Three Ways":

  1. The First Way - work should flow in the direction of development to ops to the customer, never backward.
  2. The Second Way - feedback of information relevant to process improvement should flow the other way, customer to ops to developers.
  3. The Third Way - foster a creative culture of continuous experimentation and risk taking.
which read like the bible of every success tech startup I've read about.

If you're in IT, go buy this book and read it now! I can't thank the folks at the Nashville DevOps Meetup enough for giving it to me.





Last Blog | Index | Next Blog


Web wogsland.org

This file last modified 10 August 2017 by Bradley James Wogsland.

Copyright © 2017 Bradley James Wogsland. All rights reserved.