Accelerate

Accelerate was written in 2018 following four years of survey based research data compiled by its authors. In 2021, the book feels a bit dated: the practices mentioned in the book are treated as fairly commonplace in high performing software development organizations. Most of the ideas presented in the book make intuitive sense are accepted without much argument in today’s software companies. The link between presented ideas and team performance is based on survey measures. The authors do not make conclusive claims about the overall performance of a company (using their stock price for example) and good devops practices.

The book is in three parts. The first is of interest to an engineering audience, the second goes into their survey methods, and the third is a case study. If actionable takeaways are the sole things of interest, most of the book can be skipped for Appendix A Capabilities to Drive Improvement.

Key Ideas

1. Software development team performance can be measured and improved.
2. Teams that develop devops capabilities and follow good practices ship software faster, and at a higher quality. Teams are also happier and more retained.

Performance Measurement

The authors assert that team performance can be measured. Prior attempts to measure team performance have been unsuccessful because they have focused on outputs rather than outcomes. For example, lines of code, or story points, are outputs. They are highly subjective. Instead, measures should focus on global outcomes. Company level goals, for example, are global outcomes.

I saw this idea implemented at Facebook where all functions – engineering, product, design – were graded on whether they achieved a common, measurable goal. This prevented the ownership disparity where one function owns the product outcome (“did likes go up by 1%?”) and another function owned stability (“the app had 99% uptime”).

The authors recommend four performance indicators to measure software delivery:

1. Delivery lead time: Time from spec to full rollout. Does not include design lead time (time for design and specification development, nor iteration to get the product right.)
2. Deployment frequency: Faster is better.
3. Time to restore service: All systems fail. How quickly can a complex system be restored?
4. Change fail rate: What percentages of submitted PRs result in a patch, hotfix, or need to be rolled back.

[These results demonstrate that] there is no tradeoff between improving performance and achieving higher levels of stability and quality

Capabilities

Team performance can be correlated to a base of capabilities that the teams have developed, broken down into five categories:

1. Continuous Delivery

Defn: Set of capabilities that enable us to get changes of all kinds - features, configuration changes, bug fixes, experiments - into production or into the hands of users safely, quickly, sustainably.

Capabilities

• Version control.
• Fully automated deployments. No manual scripts needed.
• Continuous integration. Each check-in triggers a set of tests to discover serious regressions.
• Trunk based development. Somewhat challenging with GitHub flow, but a straightforward idea nonetheless. Use extremely short lived branches.
• Test automation.
• Test data management. Maintaining clean test data is just as important.
• Shifting Left on security. Pull security reviews up in the early part of the development cycle. Infosec contributes to all parts of the software development. Use pre-approved libraries, packages, toolchains, and processes.
• Continuous delivery. Code check-ins result in changes getting pushed out all the way to customers.

2. Software Architecture

Authors found no significant correlation between system type and delivery performance, with the exception of engineers working on custom software developed by another company (outsourcing partners).

Capabilities

• Loosely coupled architecture
• Let teams choose their tools.

3. Product and Process

The capabilities mentioned by the authors are implemented in most modern software shops and taken for granted. They do not discuss the difficulties of implementing some of these capabilities (eg. experimentation is great, assuming you have sufficient sample size to experiment with.)

Capabilities

• Gather and implement customer feedback
• Everyone should understand how their work flows into the whole.
• Work in small batches.
• Enable team experimentation.

4. Lean Management

Capabilities

• Limit work in progress
• Create and maintain visual displays showing key quality and productivity metrics and current status of work (including bugs)
• Use data from application performance and infrastructure monitoring tools to make decisions.
• Lightweight change monitoring: no approvals or peer-reviewed approvals to check-in code.
• Leaders should try and follow the principles of Transformational Leadership

5. Culture

The authors define Culture using Edgar Schein’s model in Organizational Culture and Leadership. The model posits that culture built on three concepts

1. Basic assumptions. These are not stated but implicitly agreed upon.
2. Values. Stated missions and way we approach problems.
3. Artifacts. Public and conspicious declarations of values and assumptions.

Authors use R. Westrum’s typology of organizational cultures:

1. Pathological (power-oriented)
2. Bureaucratic (rule-oriented)
3. Generative (performance-oriented)

The goal for all organizations is to be a generative culture. Westrum posited that the culture predicts how information flows within an organization.

The authors’ theories on changing culture reminded me of Switch, especially some of the analogies about the Elephant and the Rider, based on Jonathan Haidt’s work.