Book review: Accelerate

Accelerate came out on Tuesday and I’d finished it by Thursday night, which tells you something about the length (it’s short, under 300 pages including the appendices) and something about how much I wanted it. Nicole Forsgren, Jez Humble and Gene Kim have been running the State of DevOps survey for years, and this is the book that pulls the research behind those reports into one place and explains how they did it.

I reviewed The Phoenix Project back in 2013 and called it corny and accurate. Accelerate is what you hand the person who read Phoenix and said “nice story, where’s the evidence?” There’s no Bill Palmer, no Brent, no parable. It’s charts and constructs and a chapter on why Likert scales are fine.

The core of it is four measures of software delivery performance: how often you deploy, lead time from commit to running in production, how long it takes to restore service when something breaks, and what fraction of changes cause a failure. The first two measure speed, the last two measure stability, and the headline finding is that they don’t trade off against each other. The teams that deploy most often also have the lowest change failure rates and recover fastest. The gap between the top and bottom clusters is huge (the high performers in their data deploy 46 times as often and have lead times 440 times shorter).

That finding alone is worth the price, because it’s the argument I end up having every time someone proposes slowing releases down “to improve quality”. It’s nice to have a citation now instead of just my opinion and some stories.

Then there are the 24 capabilities that, according to their analysis, drive that performance. Most of them won’t surprise anyone who’s been paying attention: trunk-based development, deployment automation, test automation, loosely coupled architecture, monitoring, small batches, a generative culture in Ron Westrum’s sense (information flows, messengers aren’t shot). What I liked is that they’re specific about the version of each practice that matters. Trunk-based development means three or fewer active branches, merged at least daily. Test automation means tests developers trust and fix, and the ones written by a separate QA team didn’t show the same effect.

And the one that’ll start fights: external change approval, a change advisory board or a manager signing off, was negatively correlated with delivery performance and didn’t improve stability. In their data you’d be better off with peer review and nothing else. I’ve sat through enough CAB meetings to find this very satisfying, and I’m aware that “a study confirms what I already believed” is exactly when I should be most careful.

Which brings me to Part II, the research methods section, which I expected to skip and ended up reading twice. A year ago I probably would have skipped it. But I’m partway through a data science certificate right now, a lot of it regression in R, and so I read it with fresh eyes, looking for the places where it could go wrong. They’re upfront about most of them. It’s survey data, so it’s self-reported. They explain how they test whether a set of survey questions actually measures one underlying thing (a latent construct) and not something else, and why they think a well-designed survey can be more trustworthy than system data that nobody has cleaned. And they’re careful with the word “predicts”, which they use in the inferential sense: controlling for other things, X is associated with Y in a way that holds up. It’s not a randomized trial, nobody is assigning companies to do trunk-based development, and they say so.

I’m not fully convinced on a couple of points. The sample is people who choose to answer a DevOps survey, which skews toward organizations that already care about this stuff, and I’d love to know what the bottom cluster looks like in companies that never heard of the survey. And the link from delivery performance to organizational performance (profitability, market share) rests on respondents rating their own company against competitors, which is a lot to ask of anyone’s objectivity. But they show their work, which is more than most management books do.

Part III is a short case study of a transformation at ING in the Netherlands, written by different authors, and it’s the weakest part. Fine, but it reads like a different book.

If you lead an engineering team, read Part I and keep it on the desk. If you’ve ever had to argue with a finance person about why you need to spend a quarter on deployment automation, read Part II too, because that’s where the ammunition is. I’ve already ordered a second copy to lend out, since the first one isn’t leaving my desk.