What I learnt from the Phoenix Project
Having just read this book - The Phoenix Project - A Novel About IT, DevOps and Helping your Business Win - Gene Kim, Kevin Behr, George Spafford - I'm keen to express exactly what I learnt so I don't forget its important messages.
The book follows Bill, a "Director of Midrange Technology Operations" who is forced into a more senior role of "VP of IT Operations". As soon as he is given this job he's on the back foot trying to work out why stuff keeps breaking. As the book goes on, we get the impression of an IT department stumbling around from disaster to disaster in complete and utter disarray. Bill guided by his khaki pants guru Erik, turns the place around.
Here's what I learnt...
Find your bottlenecks - The books message here is that any improvement made anywhere besides the bottleneck is wasted. This makes perfect sense and comes from comparing IT to a manufacturing pipeline and applying the Theory of Constraints. Not only does it make perfect sense, it's easy to remember. The really hard part is firstly identifying them. I think I now realise why our project manager is so insistent that we keep our project management view (Rally) up to date with the status of stories. If you don't reliably track where things are and for how long, how do you identify your bottlenecks? In the absence of proper stats and figures I would guess that it would come down to (unreliable) anecdotal evidence. Fixing them and not creating more as you go is another story.
Prioritize - This comes down to saying no (or at least "not now") and actually choosing between competing deliverables. If you never decide or prioritize, the ultimate extreme manifests as a huge amount of WIP which creates overhead (in managing all the stories) inefficiencies (by switching from one thing to another) and a feeling of stress due to never feeling on top of things.
Is this work absolutely necessary? - A huge portion of work on the IT department's backlog was to fix auditing issues. It emerges later that they don't need to be fixed since manual actions already in place prevent them from becoming real issues. I think the lesson here is... Don't dictate the solution of a problem. As soon as you dictate the solution, that's what will be built.
Respect change control - I have always found the form filling and approval process of changes/releases a pain in my IT career. However the chaos depicted in this book, of no change control at all, makes me now happy to suffer this pain and make sure all details submitted are accurate. This was depicted very well in the book whereby an incident was blamed on one change (which when rolled-back made things even worse) when the actual culprit was a change no one knew about.
Big bang releases are to be avoided at all costs as they are risky and don't release business value quick enough.
The other lessons from the book were equally relevant but perhaps less profound to me.
If you haven't read it, do. Aside from it's important lessons, it's a lot of fun reading about massive IT catastrophes with the comfort of not being involved.
The book follows Bill, a "Director of Midrange Technology Operations" who is forced into a more senior role of "VP of IT Operations". As soon as he is given this job he's on the back foot trying to work out why stuff keeps breaking. As the book goes on, we get the impression of an IT department stumbling around from disaster to disaster in complete and utter disarray. Bill guided by his khaki pants guru Erik, turns the place around.
Here's what I learnt...
Find your bottlenecks - The books message here is that any improvement made anywhere besides the bottleneck is wasted. This makes perfect sense and comes from comparing IT to a manufacturing pipeline and applying the Theory of Constraints. Not only does it make perfect sense, it's easy to remember. The really hard part is firstly identifying them. I think I now realise why our project manager is so insistent that we keep our project management view (Rally) up to date with the status of stories. If you don't reliably track where things are and for how long, how do you identify your bottlenecks? In the absence of proper stats and figures I would guess that it would come down to (unreliable) anecdotal evidence. Fixing them and not creating more as you go is another story.
Prioritize - This comes down to saying no (or at least "not now") and actually choosing between competing deliverables. If you never decide or prioritize, the ultimate extreme manifests as a huge amount of WIP which creates overhead (in managing all the stories) inefficiencies (by switching from one thing to another) and a feeling of stress due to never feeling on top of things.
Is this work absolutely necessary? - A huge portion of work on the IT department's backlog was to fix auditing issues. It emerges later that they don't need to be fixed since manual actions already in place prevent them from becoming real issues. I think the lesson here is... Don't dictate the solution of a problem. As soon as you dictate the solution, that's what will be built.
Respect change control - I have always found the form filling and approval process of changes/releases a pain in my IT career. However the chaos depicted in this book, of no change control at all, makes me now happy to suffer this pain and make sure all details submitted are accurate. This was depicted very well in the book whereby an incident was blamed on one change (which when rolled-back made things even worse) when the actual culprit was a change no one knew about.
Big bang releases are to be avoided at all costs as they are risky and don't release business value quick enough.
The other lessons from the book were equally relevant but perhaps less profound to me.
- Key man dependencies are bad as they introduce bottlenecks.
- Blame culture slows the fixing and learning processes.
- Us and them culture between IT and business obviously isn't good.
If you haven't read it, do. Aside from it's important lessons, it's a lot of fun reading about massive IT catastrophes with the comfort of not being involved.
Comments
Post a Comment