Agile / DevOps

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

The Phoenix Project … I think this book is great.  Admittedly not as a novel – but it totally resonated with me.  I felt that someone was finally writing about my world.  (And not just because I understood the few technologies mentioned.)  The book accurately conveys the chaos and continuous firefighting that seems to be an integral part of some companies.

balancing-act_740

The book is written from the point of view of the men in the trenches being bombarded from all sides until shell-shock sets in.  I’m sure a lot of project managers, many software developers and testers and just about anyone in operations will recognise aspects of their daily lives in this book.  And much and all as they should enjoy reading it, they’re not the ones who need to read it!

The suits need to read it.

Why?  Because as one of the authors Gene Kim said in his key note at Agile2013: “95% of all capital projects have an IT component” and “50% of all capital spending is technology related”.  You can’t afford to treat IT as the poor relation in the company.

The key is to view your business holistically.  The analogy is made with a production plant, which initially seems worlds apart from the world of IT.  (The book is quite open about its debt here to “The Goal: A Process of Ongoing Improvement” by Goldratt, which explores the theory of constraints within a production plant.)  However, as the book progresses the similarities between a company delivering a product for customers and a plant producing parts becomes clearer.

The short version would be that without end-to-end optimisation of resources and capacity there will inevitably be bottlenecks and delivery problems.  To enable this optimisation, management needs to appreciate how IT ticks and to view it as integral part of the whole company and not as subservient to the whims of business.  This involves optimising operations, better coordination with development and finally aligning business goals with available IT resources.

However, maybe the book makes its most salient point when it when describes what it takes for business to sees things that way.  A major project that investors were banking on has to go belly up, the main character quits his job, the whole company goes to pot and the board wants to split it up.  Only then, on the brink of extinction, were management prepared to re-evaluate IT and its role in the company.

Hopefully that’s just literary exaggeration.  It shouldn’t take such extremes for forward thinking management to appreciate the important of IT to a company.  While there’s always going to be room for optimisation at a local level, the real rewards come when there is company-wide alignment of goals.

As a novel, the book is on shakier ground.  Sometimes the characters sound like they’re reading from a textbook on DevOps (which the authors have previously written!).  And there are a couple of scenes and character development which stretch credulity – I mean, how long can it take to realise that Brent is a constraint?  It also seems to be full of ex-military types (and often their way of thinking) – you could get the impression that the only way to the top is by wearing a lot of khaki!  However, this shouldn’t take away from the central message – that until IT resources and capacity are understood and optimised to meet the business goals there won’t be a happy ending!

Passende Artikel

Kommentare gesperrt.