If you are anything like me you read a lot of ‘business’ books. For me these are usually at least somewhat related to doing work in the internet-era — often with titles including buzzwords like ‘lean’, ‘agile’, ‘transformation’, ‘sprints’ (or a creative combination of all of them!). Also if you are anything like me you do what James Herbert (boss of bosses at NotBinary) pointed out at a recent away day — read a third of the book and then decide you are an expert!

The book I recently read a third of (actually a little more) and that I am pushing at anyone who will listen, and which I have bought a real copy of just to easier lend out is this →

Written by some of the team behind both ‘The Phoenix Project’ and the annual ‘State of DevOps’ survey and report it really makes the argument about the importance of the technology aspects of transformation alongside the cultural ones that I stumbled around in my recent post about it not just being about people.

The book takes a notably academic tone — with a sizeable portion of the book just laying out the teams research methodology and process — and while this can at times make it a less than easy read I think it becomes a much more powerful artefact thanks to this decision.

It makes the conclusions much harder to dismiss when it is based on some data rather than just the opinions — no matter how expert — of the authors and I suspect it will mean that passages of this book will be wheeled out by anyone trying to convince the local ‘powers that be’ on the worth of investing in this kind of transformation for years to come.

There has no doubt it has had an immediate influence on my thinking. The last couple of months I’ve been sketching out some ideas about what a network of high performing teams might look like — given that is basically what I have joined NotBinary to try and achieve — and this book had the dual effect of (a) making me think I was on the right lines and (b) realising I needed to rethink everything as I wasn’t being ambitious enough.

The fact is I suspect there is very little new in the book for any existing high performing teams — especially those in and around the Government Digital Service world these last few years as much of it is the good practice as outlined in the Service Manual (and elsewhere) but it somehow feels more explicit in its recommendations and benefits from the weight of evidence provided by the survey.

I actually read the book (well some of the book) in a rather haphazard order. Starting with Appendix A which covers what they call the ‘Capabilities to Drive Improvement’ — these five categories are:

• Continuous delivery
• Architecture
• Product and process
• Lean management and monitoring
• Cultural

As you might expect I found myself mainly drawn to the final three categories there — with each both reassuring me about some of my own beliefs about helping teams and organisations benefit from these new ways of working but also introducing me to new ideas (well to me) and approaches.

The Westrum model for organisational culture is seemingly well known and understood by others but was new to me and was an immediate lightbulb moment:

Pathological organisations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
Bureaucratic organisations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book — their book.
Generative organisations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

Despite my retreat to my comfort zone even within my reading habits I have to say that it feels like this book really articulates the massive wins possible by embracing modern software development processes and particularly just being able to get to a point where you can deploy changes easily, regularly and safely which really opens up the possibilities of iterative improvements. This and the idea of ‘shifting left on security’ were lessons I had taken from my own experiences back at ONS so I was really pleased to see them stated so clearly here.

I think even as a relatively non technical product person I’d be nervous of working in any team where things like;

• version control
• automated deployments
• continuous integration
• automated tests
• security involvement early and often (preferably as part of the team)

..were not at least the ambition if not the starting point on day one.

One of the things I am most proud of at ONS was moving from a situation where two deployments a year was the norm to an expectation of daily (or more) deployments. This felt like such a game changer and made a lot of the thinking around things like agile and user-centricity so much more real as we could genuinely iterate based on user research and our sprints had real skin in the game.

My professional goal is to take on roles where I need to convince those that need convincing that this approach is what is needed and then to provide the space and the culture for teams implementing it to succeed. This book will really help with that so thanks!