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":
-
The First Way - work should flow in the direction of
development to ops to the customer, never backward.
-
The Second Way - feedback of information relevant to process
improvement should flow the other way, customer to ops
to developers.
-
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.
|