Book review of Accelerate: The Science Behind DevOps – Building and Scaling High Performing Technology Organizations by Nicole Forsgren, PhD, Jez Humble, and Gene Kim.

If you have been at any programming or agile related conference within the last 8 months or so, you will probably have heard people recommend Accelerate. One of the reasons it is often recommended is that it explains the importance of DevOps for high performing tech organizations. This is not really anything new, but what Accelerate does, is base it on actual science, and not just anecdotes and opinions – something we see all too often in the tech field.

The findings of Accelerate is based upon the survey data collected through the yearly survey “State of DevOps” in the years 2014-2017. Those data clearly demonstrated that a high performing organization performed much better than a low performing organization, but they could also be used to explain what caused this differences in performance.

The book is split into 3 parts, a conclusion, and some appendixes. The first part explains the findings, the second part, the science used, and the third part is a case study contributed by Steve Bell and Karen Whitley Bell. I will go through each part separately below.

The first part of the book is called “What we found”, and what they found is certainly noteworthy. They looked at some key indicators of software delivery performance, and found that a high performance organization had the following performance compared to low performance organizations:

• 46 times more frequent deployments
• 440 faster lead time from commit to deploy
• 170 times faster mean time to recover from downtime
• 5 times lower change failure rate

These numbers are from page 10 of the book, and show a much greater difference than most would expect, no matter how big a proponent of DevOps.

The rest of the first part of the book goes through their other findings, which identifies “24 key capabilities that drive improvement in software delivery performance, and, in turn, organizational performance”. According to the authors, “[t]hese capabilities are easy to define, measure, and improve”.

I won’t include the list here, but many of them relate to DevOps practices and lean management practices, though there are a couple related other things, such as architecture. One thing I will mention, is that the findings indicate that while culture has an influence on the use of DevOps techniques, the use of DevOps techniques also have an influence on culture, which changes as a result of that.

None of the mentioned capabilities are new, but here we have, for the first time, evidence that they actually work, and help improve performance.

The second part of the book, “The Research”, goes into how the research was conducted, and why survey data was suitable for the research. It doesn’t include the actual data, which would have been nice, but I can understand why that isn’t the case (breach of confidentiality etc).

I can’t recall seeing a similar chapter in any other book on programming/systems development, and I highly applaud it. I also think it was a smart move to put it in the second part, rather than the first part, as most people will be more interested in the findings, rather than the methods behind finding them.

The third part of the book, the case study contributed by Steve Bell and Karen Whitley Bell, is called “Transformation”. They takes us to Ing Netherlands, a world-wide bank, where they have been involved in a cultural change, started and lead by the IT manager, enabling the organization to become high-performance.

To be honest, I find this part to be the weakest part of the book, both in content and in presentation, but it does provide a nice overview of practices on the team, management, and leadership level (it can be found online here).

All in all, the findings of the book should not be shocking to people who has worked with agile, DevOps etc., but it is nice to have a list of proven capabilities to focus on. It is also a useful tool when debating with management about these subjects.

I highly recommend the book to people working in any aspect of software engineering – be it as a programmer, a project manager, in a leadership position, or in any other capacity.