Book Review: Accelerate



Nicole Forsgren, Jez Humble, Gene Kim

My Rating

star star star star
"A data-driven study showing which practices correlate with high-performing teams and organisations."

Wouldn't it be wonderful for our industry if we had data to validate the most, and least, effective practices? Imagine if we could clearly identify better ways to develop software rather than having endless holy wars about whether we should use feature branches or whether we need change approval boards (CABs).

It's hard to think of a more worthwhile contribution to our industry isn't it? So credit to Nicole, Jez, and Gene for setting out on this seemingly-impossible endeavour. But productivity and performance is so hard to measure, can we even trust their results?

In Accelerate, the authors try to give us the statstically-significant answers we crave and they try to convince us the results are valid by detailing the design of their statistical surveys.

For what it's worth, I'm not an expert in statistics and so I hold many reservations about the findings in the book, even though they confirm many of my favourite practices correlate with high-performing organisations. Having read section 2, which explains the design of the research, I do, however, feel more confident that I can trust the findings. 

With those caveats aside, let me share with you a few of the statistically-significant insights that really opened my eyes.

Survey Highlights

Early on in the book, the authors show that their survey findings highlight a stastistically-significant correlation between continuous delivery and organisational performance. The next time you feel you aren't making progress at improving the delivery capabilities in your organisation, and you question yourself "why should I bother?", remember - it really does matter.

Another surprising insight is that architecture is one of the biggest predictors of continuous delivery performance (which predicts organisational performance). The authors show there is a statistically significant correlation between a loosely-coupled software architecture with an organisational structure to match, and continuous delivery performance.

I've observed the importance of architecture anecdotally, and if you've been reading my blog or attended any of my conference talks, you'll know I think there are lots of improvements we can make in this area. But for the study to to highlight architecture as, statistically, one of the most important characteristics was shocking even to me.

Another finding, related to autonomy, that I was extremely satisfied to hear about was the importance of roadmap autonomy. There is a high correlation between teams shaping their own direction and organisational performance. Next time you're fighting against featurefactoryitis, remember you're doing the right thing.

An Important Book

I definitely think you should read this book. In addition to the findings there is plenty of actionable advice. For instance, the authors suggest 4 metrics we can put in place to measure the effectiveness of delivery teams.

There's also a third part of the book, which is a case study of Dutch bank ING. There are some interesting observations, although it did made me chuckle in one place. They advise that high performing organisations should find what works for them (I agree), yet they've copied the Spotify Model themselves. It's s a nice little bit of bonus content, but it's not the reason you should buy the book.

Overall, though, my feeling is that it often feels like playground bickering in software development as we argue about which practices to use. Everybody has their favourites and nobody has any proof.

It's books like Accelerate, which are based on surveys and lead the way for future research, that are going to advance our immature ways of working and let us spend more of our energy focusing on what we're building instead of arguing over how we build it. I'll drink to that.



"the ability of teams to try out new ideas and create and update specifications during the development process, without requiring the approval of people outside the team, is an important factor in predicting organizational performance."

"Teams that reported no approval process or used peer review achieved higher software delivery performance. Finally, teams that required approval by an external body achieved lower performance."

"organizations should evolve their team and organizational structure to achieve the desired architecture... the biggest contributor to continuous delivery in the 2017 analysis—larger even than test and deployment automation—is whether teams can: Make large-scale changes to the design of their system without the permission of somebody outside the team "

"If we achieve a loosely coupled, well-encapsulated architecture with an organizational structure to match, two important things happen. First, we can achieve better delivery performance, increasing both tempo and stability while reducing the burnout and the pain of deployment. Second, we can substantially grow the size of our engineering organization and increase productivity linearly"

"The goal is for your architecture to support the ability of teams to get their work done—from design through to deployment—without requiring high-bandwidth communication between teams."

You may also like...

Software Design X-Rays

Growing Object-Oriented Software, Guided by Tests

Effective Akka

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design
The Strategic Practices of Domain-Driven Design