If, like me, you have to interact with IT —and technology is vital for you or your clients — this excellent novel will enlighten your day-to-day work.
Written by three luminaries of the DevOps movement — Gene Kim, Kevin Behr, and George Spafford — the Phoenix Project is an excellent book for Board Members, Executives and, frankly, any Business or IT professional interested in IT as an enabler.
“Bill Palmer here,” the books begins. Bill is an IT manager at Parts Unlimited. The company’s new initiative, code-named ‘Phoenix Project’, is critical to the future of the company, but the project is dangerously over budget and overdue. The CEO wants Bill to report directly to him and fix the mess in ninety days or else he’ll outsource Bill’s entire department.
I have recognized Bill Palmer’s story, and the issues he faces, time and again with IT projects in financial services (and other industries, I am sure).
The Phoenix Project was first published in 2013 and, in the fast-moving world of technology, one could view this book as ‘outdated.’ But no. The way it articulates the value of DevOps for organisations remains insightful. It remains useful. And it remains worth your attention. Of particular value is the presentation of the Three Ways — the principles from which all observed DevOps behaviours are derived.
Source: Gene Kim, The Three Ways: The Principles Underpinning DevOps, IT Revolution Press Blog, 2016
To deliver value to the business quickly, the technology value stream requires a fast and smooth flow of work from development to operations i.e., a fast flow from left to right. Only three weeks ago, I was discussing the deployment of a new functionality for commercial banking customers with a UK client. The client’s IT team told me that the deployment lead time would be three months if all went well… Back to the First Way; we must address this!
With rapid flow from left to right, what is then required is constant feedback from right to left. Personally, I contrast that with what you would typically get with a waterfall software project where code is developed for months and the team gets no feedback on quality until the testing begins. We sometimes see this too in financial services when the software or the app is released to end-users.
In contrast, when one implements the principles of the Second Way, one can see problems as they occur and set about solving them. The end result combines cost efficiency and, obviously, better user experience.
This was the approach my colleagues at Reply adopted when we developed the iPad Apps for BNP Paribas Fortis and I’m pleased to say it worked. You can listen to what BNP Paribas Fortis have to say about that in this short video here.
The third principle, focussing on learning and experimentation, enables high trust and boundary-spanning between functions. It accepts that failures will always occur and it delivers better performance and increased resilience.
I’ve seen this first hand within Reply and within many clients, ranging from Illimity to Revolut. This includes the concept of Product Owners, or POs, who are “in charge of building the infrastructure and launching new products and features”. Product Owners manage a team of designers and engineers that demonstrate excellence in this concept of continual learning and experimentation.
The Phoenix Project is as enjoyable as it is useful and, in my experience, business and IT are better when one follows these three principles. If you happen to have read and enjoyed The Goal (1984) by Goldratt and the Theory of Constraints, you will definitely enjoy this fast-paced and entertaining book.
The concluding icing on the cake for me was the following reference included in The Phoenix Project from one of my favourite books, Flatland, first published in 1884: “And like when Mr. Sphere told everyone in Flatland, you must leave the realm of IT to discover where the business relies on IT to achieve its goals.”
Cover of Flatland: a romance of many dimensions / with illustrations by the author, A Square. By Edwin Abbott Abbott (1838-1926). Published: London: Seeley & Co., 1884. *EC85 Ab264 884f Houghton Library, Harvard University