Accelerate: The Science of Lean Software and DevOps

Summary of “Accelerate: The Science of Lean Software and DevOps” by Nicole Forsgren, Jez Humble, and Gene Kim. The book is about finding (software) engineering practices, that work. Basically confirming all the good biasses about importance of DevOps and lean software development for SaaS products.

Part I: What we found

What should we do?

Authors lay down 24 practices (they call the key capabilities) essential for improving software delivery, and group them into five groups:

• Continuous Delivery: adopt CI/CD, automate linting, testing, staging etc.
• Architecture: use a loosely coupled architecture, minimize dependencies among teams. Allow teams autonomously choose technology.
• Product and Process: have a tight feedback with users / customers. Allow responsible teams to handle it autonomously.
• Lean Management and Monitoring: collect, visualize, and share data openly.
• Culture: learning and collaboration is the cornerstone.

You get what you measure

Measuring development productivity is hard. Similarly, choosing a right metric for the whole company is hard. The choice of metric(s) will influence peoples’ behavior. Frequently, in not-that-great way. E.g., people may start inventing shortcuts, instead getting feedback on where to improve. Similarly, company trading market share for employee satisfaction doesn’t lead to long-term sustainability.

Authors highlight the typical flaw of measuring outputs instead of outcomes. I would add that many companies do even more fundamental mistake and completely forget about inputs in their strategies (don’t focus that much on the lagging metrics).

Measure Software delivery

Suggested metrics to follow:

• 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 team(s) restore service after production outage.
• Change Fail Percentage: What percentage of deploys result in downtime or limitation of service.

Their research shows that development tempo doesn’t need to be tradedoff for stability. CI/CD improves both velocity and stability.

Measure Culture

Authors follow “Westrum continuum” to define three types of cultures: pathological (power-oriented), bureaucratic (rule-oriented), and generative (performance-oriented). Obviously, we want the generative. The key characteristics are high collaboration, transparency, and a blameless approach to problems.

Pathological (Power-Oriented)	Bureaucratic (Rule-Oriented)	Generative (Performance-Oriented)
Low cooperation	Modest cooperation	High cooperation
Messengers “shot”	Messengers neglected	Messengers trained
Responsibilities shirked	Narrow responsibilities	Risks are shared
Bridging discouraged	Bridging tolerated	Bridging encouraged
Failure leads to scapegoating	Failure leads to justice	Failure leads to inquiry
Novelty crushed	Novelty leads to problems	Novelty implemented

Technical practices

This chapter goes through several technical practices, which are important for implementing DevOps approach. Reiterating importance of using proper version control, CI/CD, test automation etc. Nice is a research support for the gut-felt correlations:

• Tooling affects culture. Cannot expect generative culture, if it is painful to do even small changes.
• Tooling affects how people feel. Continuous Delivery provides a safety net for people ==> they feel less stressed and safer to experiment as well as to admit mistake.

Architecture and Management

Next chapters really resonated with my biasses  – the people autonomy is a key building block for any meaningful scaling of the business. They show how adding people can have a positive impact on the throughput instead hindering productivity.

The autonomy creeps out on the following pages multiple times. For example, showing that change approval by external body (manager, CAB etc.) doesn’t work and hinders the team productivity. Lightweight approval process, based on peer-review seems the best.

Management should focus on limiting work in progress, showing and sharing important metrics/progress, keeping feedback loop tight and lightweight approval process. Similarly product management focus evolves around keeping work in small batches, making work visible, keeping feedback flowing and encouraging experimentation.

Leadership and Management

Last chapter of the first part provides hints to managers in the organization on what to focus on. Advocating for transformational leadership (as defined by Rafferty and Griffin in “Dimensions of transformational leadership: Conceptual and empirical extensions”) and it’s five key characteristics: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition.

Managers should focus on enabling cross-functional collaboration, creating a climate of learning/exploration/experimentation, maintaining team and individual autonomy, making things like logging/monitoring, code-reviews a priority.

Part II: The Research

The second part of the books goes into great details on how the data were actually gathered. It provides a great guidance on how to run own surveys within the organization.

Part III: Transformation

Is a guest “post” by Steve Bell and Karen Whitley Bell on High-Performance leadership and management. It lists learnings from ING on some of the practices discussed through the book.

Amazon link (no affiliation)