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.
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.