My Foreword to Accelerate

A few years ago I read a report that said “We can now assert with confidence that high IT performance correlates with strong business performance, helping to boost productivity, profitability and market share.” When I read something like that, my usual response is to toss it with great force into the rubbish bin, because that's usually a tell for some bogus bullshit masquerading as science. I hesitated this time, however, for this was the “2014 State of Devops Report”. One of its authors was Jez Humble, a colleague and friend who I knew was equally allergic to this kind of twaddle. (Although I have to confess that another reason for not tossing it was that I was reading it on my ipad.)

So instead I emailed Jez to find out what lay behind this statement. A few weeks later I was on a call with him and Nicole Forsgren, who patiently walked me though the reasoning. While I'm no expert on the methods they used, she said enough to convince me there was some real analysis going on here, far more than I usually see, even in academic papers. I followed the subsequent State of Devops reports with interest, but also with growing frustration. The reports gave the results of their work, but never contained the explanation that Nicole walked through with me on the phone. This greatly undermined their credibility, as there was little evidence that these reports were based on more than speculation. Finally those of us that had seen behind the curtains convinced Nicole, Jez, and Gene to reveal their working methods by writing this book. For me it's been a long wait, but I'm glad I now have something that I can genuinely recommend as a way to look at IT delivery effectiveness, one that's based on more than a few analysts' scattered experiences.

The picture they paint is compelling. They describe how effective IT delivery organizations take about an hour to get code from committed-to-mainline to running-in-production, a journey lesser organizations take months to do. They thus update their software many times a day, instead of once every few months, increasing their ability to use software to explore the market, respond to events, and release features faster than their competition. This huge increase in responsiveness does not come at a cost in stability, since these organizations find their updates cause failures at a fraction of the rate of their less-performing peers, and are usually fixed within the hour. Their evidence refutes the Bimodal IT notion that you have to choose between speed and stability, instead speed depends on stability, so good IT practices give you both.

So, as you may expect, I'm delighted that they've put this book into production, and will be recommending it willy-nilly over the next few years. (I've already been using many bits from drafts into my talks.) However I do want to put in a few notes of caution. They do a good job of explaining why their approach to surveys makes them a good basis for their data. However, they are still surveys that capture subjective perceptions, and I wonder how their population sample reflects the general IT world. I'll have more confidence in their results when other teams, using different approaches, are able to confirm their reasoning. The book already has some of this, as the work by Google on team cultures provides further evidence to support their judgment on the important role that a Westrum-generative organizational culture plays in effective software teams. Such further work would also make me less concerned that their conclusions confirm much of my advocacy - confirmation bias is a strong force (although I mostly notice it in others ;-). We should also remember that their book focuses in IT delivery, the journey from commit to production, not the entire software development process.

But these quibbles, while present, shouldn't distract us from the main thrust of this book. These surveys, and the careful analysis done on them, provide some of the best justification around for practices that can significantly improve most IT organizations. Anyone running an IT group should take a good hard look at these techniques and work to use them to improve their practice. Anyone working with an IT group, either internally or from a IT delivery company like ours, should look for these practices in place and a steady program of continuous improvement to go with them. Forsgren, Humble and Kim have laid out a picture of what effective IT looks like in 2017, IT practitioners should be using this as a map to join the high performers.

---