I recently read Accelerate by Nicole Forsgren, Jez Humble and Gene Kim. This is not a classical book summary, but rather a collection of thoughts from the book which I found worth noting down. I have to say upfront: I really love the book’s approach of only presenting results that have a measurable proof - which sets it apart nicely from all kinds of heavily opinionated literature on software development and delivery. However, it also makes the results less surprising than one might expect, especially if you’re familiar with what I would consider to be “modern” software development practices.

Developer productivity

The first notable result for me is their approach to measuring developer productivity. There has been a lot said and written about what the right way to measure developer performance would be. Everyone seems to be in agreement that we need to first measure something before we can improve it – so it’s kind of the holy grail of software development. The authors suggest four metrics to assess developer productivity:

• Delivery lead time: The idea is to measure how long it takes to translate a customer request into a complete and delivered piece of product. The metric makes all the good stuff visible that happens when you cut down work into smaller pieces (decreasing batch sizes) and focus on the optimal flow of the development process. It needs to be balanced with its counterpart metric called “utilization” (which, counter-intuitively, needs to go down for an increased productivity). The trick is to find the economically optional balance point between utilization and lead time.
• Deployment frequency: Again, this is a great way to assess the capability of delivering increments in a continuous stream. Data shows clearly that the most successful software organizations deliver small increments extremely fast and frequently (and with an ever increasing speed while their organizations grow)
• Time to restore service and change fail rate: I am putting these together because I personally find them very hard to measure in a meaningful way. The logic that these metrics are strongly correlated with team productivity make sense to me. And the ability to measure them requires a highly automated and nuanced system for failure and resolution tracking – which again points in the right direction (“automation is king”).

Technical practices

The key practices that are correlated with high productivity include (unsurprisingly) things like version control, test automation and trunk-based development.

What I found notable though is that they rightfully point out that configuration is often times treated as a second class citizen when it comes to version control. Data shows that the contrary is true and there is a strong correlation between high performance and keeping both, source code and configuration in version control.

Architecture concerns

The chapter on architecture starts with a hopeful message: “We found that high performance is possible with all kinds of systems, provided that (…) they are loosely coupled.” (and the teams are loosely coupled as well). So, neither is it a must to follow each architectural trend to be successful, nor is it a guarantee for high performance to engage in microservices (or any other trend out there). It all comes down to the characteristics of the system, of which coupling is a very important one. It confirms what lean thinkers have known before: giving teams autonomy and confidence to deliver increments with as little dependencies to other teams and other pieces of code is a winning strategy.

Another characteristic that seems to support high performance teams is independent deployability and testability. They found that those teams that agree with the following statements are more likely to be in the high performing group:

• “We can do most of our testing without requiring an integration environment”
• “We can and do deploy or release our application independently of other applications/services it depends on.”

“In teams which scored highly on architectural capabilities, little communication is required between delivery teams to get their work done, and the architecture of the system is designed to enable teams to test, deploy, and change their systems without dependencies on other teams.”

The book also reinforces the notion of “you build it you run it” (making developer team responsible for running the system): “we must also ensure delivery teams are cross-functional, with all the skills necessary to design, develop, test, deploy, and operate the system on the same team.”

An aspect that I don’t fully share is the aspect of standardization: the book suggests to allow teams to choose their own tooling and sees value in standardization only around architecture and infrastructure. In my experience at least mid-sized companies benefit from a higher degree of standardization on the tooling side as well (as it helps creating a common culture, understanding of process, and lifts barriers to move between teams).

The last piece of advice sounds almost trivial, but as of the technical nature of everyone involved is a good reminder still: Architecture (and architects themselves) should always focus on engineers and outcomes, not on tools or technologies.

Management practices for software delivery teams

For people not familiar with the topic there’s plenty of good stuff in this chapter. However, I would want to highlight two things that I really liked:

WIP limits alone do not predict high performance: Talking about lean practices, especially WIP limits (work-in-progress limits) the book stats: “What is most interesting is that WIP limits on their own *do not strongly predict delivery performance. It’s only when they’re combined with the use of visual displays and have a feedback loop from production monitoring tools back to delivery teams or the business that we see strong effect”

*Code change approval processes don’t increase system stability”: The book advises to implement very light-weight change management processes. The surprising finding of the study is: “In short, approvall by an external body (such as a manager or CAB) simply does not work to increase the stability of production systems” .. “However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”

A quote I really liked on the leadership aspect of things:

“Being a leader doesn’t mean you have people reporting to you on an organizational chart. Leadership is about inspiring (and motivating) those around you”. (I added the brackets as I think it’s less about motivating and more about not de-motivating).

Product development

In my view the way product management is done probably has the single biggest impact on delivery performance. The topic itself is huge and goes way beyond what’s in the book. It’s clear though also from the text: “Effective product management drives performance.” And the book does not stay short of a definition of how effective product management looks like in a nutshell:

“The key to working in small batches is to have work decomposed into features that allow for rapid development, instead of complex features developed on branches and released infrequently.”