Friday, 31 January 2014

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.

  • 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.

Wednesday, 1 January 2014

The more people contribute to a team's output, the closer they should be to the team.

Everyone contributing to an IT project, ideally needs to be on the team responsible for delivery.  When this isn't possible, the more they contribute the closer they need to be to the team. 

The above point probably seems obvious to the point of being redundant to most people.  I'm sure that many teams (like mine) are structured with a healthy enough mix of skills that they can be mostly self-sufficient. With our team of testers, developers, infrastructure people etc etc I too would have thought we had this base more than covered. 

However, beware that contributors to a team's output come in many different guises.  I feel that we recently suffered on a project due to a key contributor being very distant from the team.

The project involved adding a new user journey to ft.com.  The UX team had designed a user journey, in isolation from the development team, which we were to implement.  The user journey that had been created was great, however, the team had another idea which involved less technical effort and might just get us in production (with that crucial real user feedback) sooner.

Thankfully, the product owner, project manager (and I think the UX team) were all open minded in considering the alternative user journey the team proposed.  After-all, the original flow could be added later as an enhancement after go-live.  The team set off in development with an aim of keeping both options open for a while, but the path of least resistance was clearly the original option and it was up to the team to persuade otherwise.

Sadly, mockups of the alternative flow were never created.  I suspect that, as a team, we felt out of place creating them ourselves as none of us wore the UX badge. We could have asked the UX team ourselves but given we didn't know them very well, they sat on a different floor and were outside of technology.  I suspect there were too many awkward hurdles for us to overcome.  Or, to reference Conway, the "organization's communication structure" did not (easily) allow it.

Eventually a decision had to be made and the original option was chosen.  After all, the original option was more "known" to people as it had been presented numerous times with mockups. 

As mentioned previously, the original (and chosen) user journey was good and I'm very pleased to say that it's currently live and being used well.  But I think we missed a trick by not giving the alternative user journey a fair chance.  This would have been more likely to happen had we been closer to the UX team.