Nicole Forsgren, Jez Humble, Gene Kim

accelerate

According to online reviewers, the best thing about "Accelerate" is its practical insights and actionable strategies for improving organizational performance and leadership effectiveness. Reviewers appreciate the clear framework it offers for implementing change. On the downside, some readers find the content to be dense and overwhelming, arguing that it may not be easily digestible for those new to the concepts discussed.

Key Insights

  • The Four DORA Metrics. The research settled on exactly four measures that predict software delivery performance: “delivery lead time, deployment frequency, time to restore service, and change fail rate.” Everything else is a proxy; these four are the signal. When evaluating an engineering org, map it against all four — a team that deploys daily but takes days to recover has a hidden risk.
  • Speed and stability are not a trade-off. The book “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.” The argument that “we need to slow down to reduce risk” is usually wrong; it’s a symptom of missing automation and loose coupling, not a trade-off to accept.
  • Utilization approaching 100% makes lead times approach infinity. “Queue theory in math tells us that as utilization approaches 100%, lead times approach infinity.” When a team has no slack, every unplanned request creates a cascade. The fix isn’t adding people; it’s reducing in-flight work.
  • Configuration in version control matters more than code. “Keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control.” When debugging a hard-to-reproduce production issue, check whether config is versioned before hunting for code bugs.
  • Generative culture as information architecture. Westrum’s typology: pathological orgs hide information, bureaucratic orgs silo it, generative orgs route it to where it’s needed. “How organizations deal with failures or accidents is particularly instructive — pathological organizations look for a ‘throat to choke’… accident investigations that stop at ‘human error’ are not just bad but dangerous.” Blameless post-mortems are not a nicety; they’re how you fix the actual system.
  • Loosely coupled architecture is a people decision, not just a technical one. “The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn’t overwhelmed by fine-grained decision-making at the implementation level.” Conway’s Law runs both ways: structure your teams toward independent deployability and the architecture follows.

— Drafted from external sources; review and edit to make your own.

Kindle Highlights: >-

Highlights

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. — location: 147 ^ref-58563

moving to outcome-based team structures, knowing our cycle time (by understanding our value stream map), limiting the blast radius (starting with one to two teams vs. boiling the ocean), using data to drive actions and decisions, acknowledging that work is work (don’t have a backlog of features and a backlog of technical debt and a backlog of operational work; instead, have a single backlog because NFRs are features and reducing technical debt improves stability of the product). — location: 172 ^ref-26233

capabilities are classified into five categories: Continuous delivery Architecture Product and process Lean management and monitoring Cultural — location: 199 ^ref-63430

shifting to a capabilities model of measurement is essential for — location: 386 ^ref-47161

Once utilization gets above a certain level, there is no spare capacity (or “slack”) to absorb unplanned work, changes to the plan, or improvement work. This results in longer lead times to complete work. Queue theory in math tells us that as utilization approaches 100%, lead times approach infinity—in other words, once you get to very high levels of utilization, it takes teams exponentially longer to get anything done. — location: 480 ^ref-26970

measures of delivery performance that meet these criteria, we settled on four: delivery lead time, deployment frequency, time to restore service, and change fail rate. In — location: 492 ^ref-16083

organizational culture predicts the way information flows through an organization. Westrum provides three characteristics of good information: It provides answers to the questions that the receiver needs answered. It is timely. It is presented in such a way that it can be effectively used by the receiver. — location: 689 ^ref-22529

How organizations deal with failures or accidents is particularly instructive. Pathological organizations look for a “throat to choke”: Investigations aim to find the person or persons “responsible” for the problem, and then punish or blame them. But in complex adaptive systems, accidents are almost never the fault of a single person who saw clearly what was going to happen and then ran toward it or failed to act to prevent it. Rather, accidents typically emerge from a complex interplay of contributing factors. Failure in complex systems is, like other types of behavior in such systems, emergent (Perrow 2011). Thus, accident investigations that stop at “human error” are not just bad but dangerous. Human error should, instead, be the start of the investigation. Our goal should be to discover how we could improve information flow so that people have better or more timely information, or to find better tools to help prevent catastrophic failures following apparently mundane operations. — location: 786 ^ref-63550

team’s ability to achieve the following outcomes: Teams can deploy to production (or to end users) on demand, throughout the software delivery lifecycle. Fast feedback on the quality and deployability of the system is available to everyone on the team, and people make acting on this feedback their highest priority. — location: 890 ^ref-54949

loosely coupled, well-encapsulated architecture (this is discussed in more detail in Chapter 5) Teams that can choose their own tools based on what is best for the users of those tools — location: 896 ^ref-11703

keeping system and application configuration in version control was more highly correlated with software delivery performance than keeping application code in version control. Configuration is normally considered a secondary concern to application code in configuration management, but our research shows that this is a misconception. — location: 946 ^ref-52544

DevOps is all about better collaboration between teams, and we don’t mean to suggest teams shouldn’t work together. The goal of a loosely coupled architecture is to ensure that the available communication bandwidth isn’t overwhelmed by fine-grained decision-making at the implementation level, — location: 1073 ^ref-30912

ALLOW TEAMS TO CHOOSE THEIR OWN TOOLS — location: 1092 ^ref-17676