Tuesday 9 September 2014

Thoughts on The Phoenix Project

I finally got round to reading The Phoenix Project last weekend. I know right? It's about time. I thought I'd share a few thoughts, as I think it's a great book and well worth a read for anyone in a business delivering products depending on IT (hint, nearly every business of any size these days depends on successful IT supporting the core business functions).

The Phoenix Project is told as a novel about the recovery story of a business who who used to be the best widget maker in the world, and are now being pounded on by a faster, more agile, hungrier up-and-comer. We follow Bill, who is promoted into the seventh circle of hell - VP of IT Operations, with only 90 days until the release of the-mother-of-all-projects which is vital to the companies survival. It's failing hard, VPs are falling left and right, every meeting looks like Game of Thrones and every piece of the puzzle seems to depend on one engineer, Brent, who's time is more oversubscribed than a year 2000 dotcom IPO.

Before I go any further - I cannot recommend enough the concept of getting your message through as a novel, rather than a text book. There are other books that take this similar approach, The Five Dysfunctions of a Team is another one I love, and for the same reason. It turns dry, bullet point material, and turns it into a "what happens next" adventure. You are with the protagonist on whether they solve their problems, and your brain is following the same steps as they do all the way through. A fiction is worth a thousand bullet points you might say. Consider them "text books with only extremely coherent examples". I read The Phoenix project in two days. I can't remember the last time I read a Terry Pratchett so fast.

There are some key messages to take from it. I want to avoid explaining the entire story of the book, because half of it's power is you working the problem yourself.

The first is actually not one really focused on by the book explicitly in its "lessons", but is worth learning: While development, operations, sales, marketing, "products" etc are all sniping at each other and seeing all other departments as "getting in the way of real work", you are in a pretty bad spot. Maybe a more positive assertion is: All teams need to work together with the vision that they are all responsible for delivering the companies core product

The second is more explicit: Understand the definition of work and from that understand what things your team actually works on and prioritise it. The book lists four, but you could easily make it two; planned work, and unplanned work. The book splits planned into business project, internal project (e.g. infrastructure upgrade) and changes (e.g. production db schema update). The obvious question is this - if you don't know all the work that your team are being asked to do, or where it comes from, how can you possibly ensure that you prioritise it correctly?

The next is a classic from lean, and is well developed in books such as The Toyota Way, and The Lean Startup. Work in progress kills productivity. In IT terms, anything that's started, but not working correctly in production is useless to the business. It is money spent and no return gained. When stock analysts look at companies they are interested in investing in, they look at how well they convert raised capital into further gains, and so should we as IT professionals. It ties in very closely to one of my own favourite mantras on "the definition of done", which I firmly believe can only be interpreted as working bug free as desired by the client or business in the production environment. Why such a stringent definition? Anything else can still come back as a task on your plate. You have to context switch (not multi-task, you actually can't do that you know), and internally prioritise. Putting something on hold either requires carefully "putting something back on the shelf", or even worse, simply dropping it without care or attention.

Possibly the most unique lesson in the book is: Any attempt to optimise a process that doesn't improve the time of that processes' bottleneck is false progress. This is gold dust, and if there is nothing else in this book for you, take that. When you read the book you see things in a new light (unless you've already read The Goal). In any process - look at the bottleneck and refine that and that only, until it is no longer the bottleneck. Then find the new bottleneck. The books example is the amazing "Brent" - at the heart of every production incident, architectural planning exercise and key software project deliverable. If he gets hit by a bus, the company could literally fold. However, after several chapters of removing Brent from every coal face so that he can actually improve the overall process of the organisation comes the big reveal. Brent is not a "work centre" - he's only a person at the work centre. Like any manufacturing plant many parts of what we do are automatable - particularly in the deployment life cycle and testing. Which leads to...

Identify your work centres: Identify all the parts of your software development cycle, they are your work centres. Now find the bottleneck among those, and improve that. Remember the golden rule above - if you are not improving the bottleneck of the process, then your effort will not reap the benefits you desire.

These last two are  the current topics of my own contemplation, as we try to reduce our continuous deployment cycle down to where we know others have already reached. It finally gives me a strategy for approaching the problem that doesn't involve simply "refine all the things". It may be obvious to say "improve your worst bits first", but what you think are your "worst bits" might not actually turn out to be your bottlenecks, so improving them would be false progress.

There are lots of other excellent snippets in there (and probably some major points I glossed over, but hey, you are going to read it anyway, right?). Why ten minutes work might take several days to be acted upon for example, and these just add more and more interesting food for thought.

I'll certainly be re-reading The Phoenix project - probably any time I get stuck on how we improve next, but first up I'll be reading The Goal

Happy reading :)

No comments:

Post a Comment