A five-minute summary of the book “Accelerate: The Science of Lean Software and DevOps” by Nicole Forsgren, Jez Humble, and Gene Kim.

About the book

The overall idea of “Accelerate” is to find how engineering practices affect companies’ performance and the well-being of their employees.

This book feels like two books under the same cover. The first part, “What we found,” is practical, while the second, “The research,” explains in detail the science behind the book. Finally, there’s a third smaller part, “Transformation,” with a case study. I read the first part and only skimmed thought the second and the third.

Summarizing this book in a phrase, I would say, “Everything you knew about development is right!” The book doubles down on the importance of DevOps and agile and proves their superiority by science.

What we measure

What would you choose as a metric of the company’s success? It should be something comparable across markets and business cycles. The authors chose profitability, market share, and productivity.

If the company succeeds at the cost of employee happiness and a healthy working environment, it’s a hollow victory. The authors measure the deployment pain and burnout and explore their influence on job satisfaction and a company’s success.

Important. If you apply the right practices, company success and employee happiness are positively correlated. It’s a win-win.

Sadly, way too often, I hear stores of developers that leave their jobs burned out because the company decided to chase for the market share with brute force at the expense of human happiness.

What should we do to succeed. Key capabilities

Authors uncover 24 practices to improve software delivery performance. They call it “key capabilities” and group them into five categories.

• Continuous Delivery: adopt CI/CD.
• Architecture: use a loosely coupled architecture, and also, let the teams choose their tools.
• Product and Process: have a tight feedback loop from customers, and let your teams react on it autonomously.
• Lean Management and Monitoring: collect and visualize data to monitor quality and work-in-progress.
• Cultural: encourage learning and collaboration.

It probably sounds like something you heard many times before, but it’s helpful to keep this as a checklist at hand. I printed and pinned them over my desktop, and I plan to keep it around until I internalize them.

Measuring Software Delivery Performance

As a development manager, how do you know that your team is making progress toward greater productivity? Is it time to celebrate success by the end of the quarter?

Measuring personal and team delivery performance by lines of code (!), velocity, or utilization is a bad idea. Instead, the authors suggest using four metrics:

• Lead Time: The time from code committed to running in production.
• Deployment Frequency: How often deploys happen.
• Mean Time To Restore (MTTR): How quickly can teams restore service after production outages.
• Change Fail Rate: What percentage of deploys result in service impairment or an outage.

Benchmark values for high performers, as defined in the book:

• Lead Time: less than one hour.
• Deployment Frequency: on-demand (multiple deploys per day).
• Mean Time To Restore (MTTR): less than one hour.
• Change Fail Rate: 0-15%

Important. The research has shown that there’s no tradeoff between tempo and stability. Continuous Delivery improves both velocity and quality.

The book doesn’t give you any hints on how to measure these metrics. I found that measuring lead time and deployment frequency is easier than time to restore and change fail rate.

Measuring and Changing Culture

The organization’s culture predicts software delivery performance and the success of the company as a whole.

The authors distinguish three types of cultures, so-called “Westrum typology” by the name of the author introducing the classification: pathological (power-oriented), bureaucratic (rule-oriented), and generative (performance-oriented.)

We want to have a generative culture. The key characteristics of the generative team are high cooperation and a blameless reaction to failures. Not surprisingly, organizations with that type of culture perform better.

Authors refer to Google’s research “The five keys to a successful Google team” that echoes the same sentiment. The study says, “Who is on a team matters less than how the team members interact, structure their work, and view their contributions” and emphasizes the importance of psychological safety.

Important. The takeaway sounds like a signal to shift the HR focus from hiring and “filtering out wrong candidates” to onboarding and empowering team members. Don’t be too obsessed with hiring the perfect candidate; instead, focus on creating the team culture.

Technical Practices

So, we learned that the team culture is critical for team success. How can we start changing it? The “Technical practices” chapter of the book outlines the importance of continuous development (CD) and tooling in general in this process. I left with three takeaways.

• Tooling affects culture. If you want to turn the team performance-oriented, start by adopting Continuous Delivery practices.
• Tooling affects how people feel. Continuous Delivery makes people feel safer and more productive, decreases the deployment pain and burnout.
• CD reduces the amount of unplanned work. According to the research, the amount of unplanned work or rework decreased from 27% for low performers to 21% for high performers.

Architecture

Contrary to common belief, increasing the number of people in the company not necessarily decreases personal productivity. If people can work autonomously, there is a positive correlation between the number of people in the team and their productivity. Low performers deploy with decreasing frequency. Medium performers deploy at a constant frequency. High performers deploy at significantly increasing frequency.

Deploys per developer per day. Source: Accelerate: Chapter 5. Architecture.

There are two premises of high performance: loosely coupled architecture and freedom in teams to choose or make their tools.

Making work sustainable

For many teams, the fear and anxiety of pushing new changes to production are real. The authors evangelize the CD motto “if it hurts, do it more often.” The book refers to a case study from Microsoft that reported that the adoption of DevOps increased developers’ satisfaction from 38% to 75%.

Source: Thiago Almeida. Inside Microsoft Engineering: DevOps Lessons Learned

Leaders and Managers

The closing chapter of the first part reminds us that leadership is not about who reports to whom. Instead, it’s about inspiration and motivation. The book provides characteristics of a transformational leader and tips on how leaders should support the culture in their teams.

• Enable cross-functional collaboration.
• Create a climate of learning.
• Make effective use of tools.

Resources

• Accelerate: The Science of Lean Software and DevOps. The website of the book.
• Thiago Almeida. Inside Microsoft Engineering: DevOps Lessons Learned. The video and slides from the Microsoft Ignite conference (2016).
• The five keys to a successful Google team. Research from Google on what makes teams perform better.
• Key Capabilities. All 24 key capabilities in one page to print.