Review of: The Phoenix Project 

5170sr05QALTitle

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win

Author

Gene Kim, Kevin Behr and George Spafford

It is not often that you hear of a novel which is part of some ethereal ‘required reading’ list for IT professionals. This is apparently one of those rare beasts. I was dubious. I mean who reads a NOVEL about DevOps and software?! Putting aside my cynicism, I downloaded it onto my Audible.

While obviously a somewhat caricatured scenario (well… in most cases…) this book does a remarkable job of putting the software delivery life-cycle under the spotlight while actually remaining readable, engaging and entertaining.

The story revolves around a newly promoted Operations Manager, a failing company, and its flagship ‘super-project’ all set against the familiar backdrop of a highly competitive market. Hampered by disassociated business, project and IT teams, single points of failure, a chronic blame culture, and significant technical debt, the ‘heroic’ Operations Manager and his team embark upon a journey of Agile and DevOps self discovery under the (slightly bizarre) tutelage of a ‘IT whizz’ who seems a strange cross between ‘Master Shifu’ and a rich, aging hipster.

It turns out I enjoyed this book. I found I was identifying with the protagonist; cringing at the situations I recognised (countless!), laughing at the jokes and nodding sagely at the thought processes (and occasional absolute confusion) of the main character. Everyone who has ever worked in or alongside IT Delivery would recognise these characters; everyone knows someone a bit like Brent, or Sarah or John.

If you can suspend your disbelief at the apparent ease of new process adoption in this company (only ONE team actively trying to get around the rules?… yeah right!), the astonishing lack of panicked attempts to backtrack on the new processes when the going gets tough, and a somewhat exaggerated ‘mentor’ – this is valuable book. It takes the idea of ‘telling a story’ to its ultimate endpoint – a full novel. Instead of a pseudo-rule-book of buzzwords tied together with dry examples of a finished product, this book takes you on a journey to show how you could get there… and even more importantly, WHY you should.

As someone whose entire role revolves around one of those ‘bottleneck workstations’ so accurately described in the book, I found the authors managed to succinctly put their fingers right onto about 80% of my daily challenges. I also found myself giving mental high-fives when I identified initiatives that I have introduced or been part of in my own career, and rubbing my chin thoughtfully over possible future opportunities.

This book touches on most of the main challenges and drivers of modern day software life-cycle management, alongside practical descriptions of various Agile, Lean, Devops, Continuous Delivery, Kanban, Continuous Improvement, and a whole host of other practices in between. It identifies the common misconceptions between IT and the business, and it demonstrates -albeit in a somewhat exaggerated way – the benefits to the whole business if everyone starts working as part of a cohesive system.

I thoroughly recommend this book for anyone that works as part of – or relies upon – business IT as part of their job. Ir might explain a lot and it could have some useful ideas for your own practice.

Take-away thoughts for DevOps / Agile practices

I attended the Computing DevOps Summit last Wednesday in London. It was a rather polished affair at the Grosvenor Square Marriott in Mayfair; well attended, well presented and with a broad lineup of Keynotes all roundly advocating DevOps.

It was a valuable day overall, but one speaker in particular resonated with me, as his choice of topic – ‘Unicorns and Elephants’ – is something quite familiar. The speaker, Rick Allan, Head of Delivery Capability at Zurich Insurance, spent his time waxing lyrical on the myriad challenges encountered by complex, multi-faceted organisations that have gone through significant organic growth. and the unexpected barriers this can create when adopting agile practices.

This is a scenario that I have seen in several organisations over the years – where do you even start when you have a estate that is riddled with legacy infrastructure and applications that have, over time, been ‘bolted’ onto each other, integrated with third parties and heavily customised. Automation in this landscape is a veritable minefield of problems.

My main take-aways from the event were:

  • Know what you actually have got, what it does, and what it communicates with.
  • Agree a vision with the business – implementing the changes needed to achieve that vision could have some serious cost and usability implications and so their buy-in and support is critical.
  • Pick off simpler applications first. Chipping small, tactical chunks from the monolith is going to be easier at first than trying to brute force it. Prove your method works.
  • Move away from project and start thinking by product and value stream (again – something the business really needs to get on-board with to enable this to work as this has budgeting implications.) This helps to break down velocity-sapping silos and move away from a transaction based culture.
  • Stand firm in the face of large, expensive programmes of change – they need to follow the rules too.
  • Implement a default tool-bench – a set of approved tools that are authorised and licensed for use. Migrate services over to them and shut off unauthorised tools behind you. Make sure your developers and engineers actually know about them, know what they are for and how to use them.
  • Use metrics to understand and prove where bottlenecks exist. This information can then be leveraged to determine a strategy to overcome the problem. Whatever the final option, the business case will need to be proven, and those metrics can help to establish that mandate.

In order to enable true continuous delivery, the ultimate goal needs to be consistent, converged and scalable architectures, ideally managed by smart software – and that is a long, and probably quite expensive, path for organisations with significant amounts of legacy applications and architecture. This type of change requires buy-in from the very top, and the investment, time and willpower to carry it through. Good intentions can only go so far.

My take on 3rd Annual DevOps Virtual Summit #dovs17

I have never attended a virtual summit before. It was an interesting experience – like a more impressive webinar – but it is probably not a format for the easily distracted. I am on GMT and the event was EDT – so it is in the evening for me (childrens dinnertime + software methodologies = a mess!)

Other than the sweetcorn on the floor though, I was pleasantly surprised.

I stumbled across a invitation for this event on Twitter about a week ago – it is hosted by CA Technologies. It was free to sign up, and they had some interesting keynotes from businesses that have trodden the path of moving from Waterfall to Agile and beyond United Airlines, CNN, GM Financial and a few other (the full list is on the CA website here.)

The most interesting keynote for me was GM Financial as this one showed a real work in progress transformation – quite unusual for this sort of event – in my experience delegates would only see the polished final article and not the journey to get there.

The best speaker of the event was Silvia Prickel, Managing Director at United Airlines. She brought a refreshing no-nonsense, senior business stakeholder attitude to the table – again a really useful insight into how differently senior managers think to the developers and testers for a IT project of this size.

Delegates that signed up came away with some useful whitepapers and a copy of a DevOps book that I have yet to have a really good look at (so I cannot really comment on it yet). 

Here is the link to the recorded sessions if you want to check them out yourself.

Would I attend another one? Yes… I probably would so long as I could could guarantee some quiet time to do so. You don’t get the Networking experience that you would with a ‘in-person’ event – you don’t really see or hear from other ‘attendees’ bar the Q&A chat box, but if you can give it your undivided attention I think you can focus more on the information being given by the keynotes. 

That and standing on sweetcorn in socks is just nasty.