In one sentence
High-performing technology organizations do not win by choosing between speed and stability. They improve both by continuously developing evidence-backed capabilities—such as small-batch work, automation, loosely coupled architecture, fast feedback, transformational leadership, and a generative culture—and by measuring delivery outcomes rather than local activity.
Overview
The book presents the authors’ four-year research program based on State of DevOps surveys and quasi-experimental statistical methods. It defines software delivery performance through throughput and stability, links that performance to organizational outcomes, and identifies 24 capabilities associated with improvement. Its central management advice is to treat transformation as continuous capability-building, not as reaching a fixed “maturity” level.
Core ideas
Measure outcomes, not busyness
Avoid lines of code, individual utilization, or team velocity as primary performance measures. The book emphasizes delivery outcomes: deployment frequency, lead time for changes, change failure rate, and time to restore service. These reveal whether an organization can deliver value quickly and recover safely.
Speed and stability are complementary
The research rejects the idea that frequent delivery necessarily means more incidents. High performers achieve greater throughput while also producing fewer failed changes and recovering faster; the mechanism is building quality into the delivery process rather than relying on a late testing or approval phase.
Small batches reduce risk and improve learning
Break work into smaller changes that can move through an automated, repeatable delivery process. Smaller batches shorten feedback loops, make failures easier to diagnose, and allow teams to learn from users sooner.
Capabilities matter more than maturity stages
Maturity models imply a stable destination and can encourage checklist behavior. A capability model instead asks which specific constraint should be improved next, recognizing that technology, markets, and useful practices keep changing.
Architecture shapes delivery performance
Teams deliver more effectively when systems and teams are loosely coupled, enabling independent changes and deployments. Architecture is therefore not merely a technical concern: it determines how much coordination and waiting a change requires.
Culture is produced through working conditions
A generative, mission-oriented culture—marked by information sharing, cooperation, trust, and learning from failure—supports both delivery and organizational performance. The practical implication is that leaders can influence culture by changing systems of work, incentives, decision rights, and feedback mechanisms, rather than treating culture as an abstract attitude.
Leadership removes organizational constraints
Transformational leaders provide vision, communicate purpose, support experimentation, and protect improvement work. Effective leadership also decentralizes appropriate decisions, funds capabilities, and avoids using metrics as instruments of blame.
Technology stack is not the main explanation
The authors report that factors such as application age, whether development or operations performs deployments, and the existence of a change-approval board did not predict performance in their model. Practices and capabilities matter more than fashionable tools or nominal process labels.
Practical takeaways
- Establish a baseline for the four delivery metrics, then track trends rather than ranking teams against one another.
- Map the path from idea or commit to production; identify queues, handoffs, approval delays, and rework before buying tools.
- Reduce batch size and make the delivery path repeatable through version control, automated testing, continuous integration, and automated deployment.
- Design team boundaries and system interfaces so teams can make valuable changes without extensive cross-team coordination.
- Use production incidents as learning opportunities; improve monitoring, recovery procedures, and the architecture that makes failures difficult to isolate.
- Create regular feedback loops with users and stakeholders, including experiments that test whether delivered changes create value.
- Treat security and quality as built-in properties of the delivery system, not gates added at the end.
- Use metrics diagnostically. If a measure becomes a target for punishment or compensation, expect gaming and degraded learning.
Caveats and counterpoints
- The book’s evidence is primarily survey-based and uses quasi-experimental analysis rather than randomized controlled experiments; its findings support predictive relationships, but readers should be careful about treating every association as universal proof of causation.
- The four delivery metrics measure software delivery performance, not product success by themselves. Faster and safer deployment cannot compensate for solving the wrong customer problem.
- The 24 capabilities are a prioritization aid, not a universal implementation sequence. Regulatory constraints, safety-critical systems, legacy dependencies, and organizational politics may change what is feasible first.
- The book is strongest as an evidence-backed synthesis of Lean, Agile, and DevOps practices. It adds methodological rigor more than wholly new technical concepts; some readers may find the research exposition more valuable than the practice descriptions.
Questions worth revisiting
- Which part of our delivery system has the longest feedback or waiting time?
- Can we measure lead time and recovery time without turning the metrics into individual or team performance rankings?
- Are our architecture and team boundaries enabling independent delivery, or forcing coordination for ordinary changes?
- What would make a failed deployment small, observable, and quickly reversible?
- Which capability is the current bottleneck: automation, testing, architecture, product feedback, leadership, or organizational trust?
- Do our incentives reward reliable learning and customer outcomes, or merely utilization, project completion, and avoiding visible failure?
Return to this when…
Return to the book when planning a DevOps or digital transformation, choosing engineering metrics, diagnosing slow delivery, redesigning team or system boundaries, or challenging the assumption that governance and reliability require sacrificing deployment speed.
Highlights
My journey started in the summer of 2011. I was working at Nordstrom and we had made a strategic decision to focus on digital as the growth engine. Up until that point, our IT organization was optimized for cost; I shared in my DevOps Enterprise Summit 2014 presentation that one of my “aha” moments was the shift to optimizing for speed. I made a lot of mistakes along the way and wish I had access to the information in this book back then. Common traps were stepped in—like trying a top-down mandate to adopt Agile, thinking it was one size fits all, not focusing on measurement (or the right things to measure), leadership behavior not changing, and treating the transformation like a program instead of creating a learning organization (never done).
Second, maturity models are quite often a “lock-step” or linear formula, prescribing a similar set of technologies, tooling, or capabilities for every set of teams and organizations to progress through. Maturity models assume that “Level 1” and “Level 2” look the same across all teams and organizations, but those of us who work in technology know this is not the case. In contrast, capability models are multidimensional and dynamic, allowing different parts of the organization to take a customized approach to improvement, and focus on capabilities that will give them the most benefit based on their current context and their short and long-term goals. Teams have their own context, their own systems, their own goals, and their own constraints, and what we should focus on next to accelerate our transformation depends on those things.
We discuss how we measure software delivery performance and how our cohort performs in detail in the following chapter. To summarize, in 2017 we found that, when compared to low performers, the high performers have: 46 times more frequent code deployments 440 times faster lead time from commit to deploy 170 times faster mean time to recover from downtime 5 times lower change failure rate (1/5 as likely for a change to fail)
Measuring performance in the domain of software is hard—in part because, unlike manufacturing, the inventory is invisible. Furthermore, the way we break down work is relatively arbitrary, and the design and delivery activities—particularly in the Agile software development paradigm—happen simultaneously. Indeed, it’s expected that we will change and evolve our design based on what we learn by trying to implement it. So our first step must be to define a valid, reliable measure of software delivery performance.
Finally, many organizations measure utilization as a proxy for productivity. The problem with this method is that high utilization is only good up to a point. 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.
A successful measure of performance should have two key characteristics. First, it should focus on a global outcome to ensure teams aren’t pitted against each other. The classic example is rewarding developers for throughput and operations for stability: this is a key contributor to the “wall of confusion” in which development throws poor quality code over the wall to operations, and operations puts in place painful change management processes as a way to inhibit change. Second, our measure should focus on outcomes not output: it shouldn’t reward people for putting in large amounts of busywork that doesn’t actually help achieve organizational goals.
Astonishingly, these results demonstrate that there is no tradeoff between improving performance and achieving higher levels of stability and quality. Rather, high performers do better at all of these measures.
This is precisely what the Agile and Lean movements predict, but much dogma in our industry still rests on the false assumption that moving faster means trading off against other performance goals, rather than enabling and reinforcing them.
The fact that software delivery performance matters provides a strong argument against outsourcing the development of software that is strategic to your business, and instead bringing this capability into the core of your organization. Even the US Federal Government, through initiatives such as the US Digital Service and its agency affiliates and the General Services Administration’s Technology Transformation Service team, has invested in bringing software development capability in-house for strategic initiatives.
In software organizations, the ability to work and deliver in small batches is especially important, because it allows you to gather user feedback quickly using techniques such as A/B testing. It’s worth noting that the ability to take an experimental approach to product development is highly correlated with the technical practices that contribute to continuous delivery.
We can measure other outcomes we care about, such as team burnout and deployment pain. We can answer questions like, “Do change management boards actually improve delivery performance?” (Spoiler alert: they do not; they are negatively correlated with tempo and stability.)
What they found instead was that “who is on a team matters less than how the team members interact, structure their work, and view their contributions” (Google 2015). In other words, it all comes down to team dynamics.
In The Visible Ops Handbook, unplanned work is described as the difference between “paying attention to the low fuel warning light on an automobile versus running out of gas on the highway” (Behr et al. 2004). In the first case, the organization can fix the problem in a planned manner, without much urgency or disruption to other scheduled work. In the second case, they must fix the problem in a highly urgent manner, often requiring all hands on deck—for example, have six engineers drop everything and run down the highway with full gas cans to refuel a stranded truck.
Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance. Teams that did well had fewer than three active branches at any time, their branches had very short lifetimes (less than a day) before being merged into trunk and never had “code freeze” or stabilization periods.
There is no contradiction here. When the tools provided actually make life easier for the engineers who use them, they will adopt them of their own free will. This is a much better approach than forcing them to use tools that have been chosen for the convenience of other stakeholders. A focus on usability and customer satisfaction is as important when choosing or building tools for internal customers as it is when building products for external customers, and allowing your engineers to choose whether or not to use them ensures that we keep ourselves honest in this respect.
What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems. Architects should collaborate closely with their users—the engineers who build and operate the systems through which the organization achieves its mission—to help them achieve better outcomes and provide them the tools and technologies that will enable these outcomes.
The results were surprising. We found that approval only for high-risk changes was not correlated with software delivery performance. Teams that reported no approval process or used peer review achieved higher software delivery performance. Finally, teams that required approval by an external body achieved lower performance.
We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, approval by an external body (such as a manager or CAB) simply doesn’t work to increase the stability of production systems, measured by the time to restore service and change fail rate. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.
Our recommendation based on these results is to use a lightweight change approval process based on peer review, such as pair programming or intrateam code review, combined with a deployment pipeline to detect and reject bad changes. This process can be used for all kinds of changes, including code, infrastructure, and database changes.
The Agile brand has more or less won the methodology wars. However, much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes. For example, in larger companies it’s still common to see months spent on budgeting, analysis, and requirements-gathering before work starts; to see work batched into big projects with infrequent releases; and for customer feedback to be treated as an afterthought.
In particular, be aware that if deployments have to be performed outside of normal business hours, that’s a sign of architectural problems that should be addressed. It’s entirely possible—given sufficient investment—to build complex, large-scale distributed systems which allow for fully automated deployments with zero downtime.
Burnout is physical, mental, or emotional exhaustion caused by overwork or stress—but it is more than just being overworked or stressed. Burnout can make the things we once loved about our work and life seem insignificant and dull. It often manifests itself as a feeling of helplessness, and is correlated with pathological cultures and unproductive, wasteful work.
Research shows that stressful jobs can be as bad for physical health as secondhand smoke (Goh et al. 2015) and obesity (Chandola et al. 2006). Symptoms of burnout include feeling exhausted, cynical, or ineffective; little or no sense of accomplishment in your work; and feelings about your work negatively affecting other aspects of your life. In extreme cases, burnout can lead to family issues, severe clinical depression, and even suicide.
Christina Maslach, a professor of psychology at the University of California at Berkeley and a pioneering researcher on job burnout, found six organizational risk factors that predict burnout (Leiter and Maslach 2008):3 Work overload: job demands exceed human limits. Lack of control: inability to influence decisions that affect your job. Insufficient rewards: insufficient financial, institutional, or social rewards. Breakdown of community: unsupportive workplace environment. Absence of fairness: lack of fairness in decision-making processes. Value conflicts: mismatch in organizational values and the individual’s values.
At the heart of Lean management is giving employees the necessary time and resources to improve their own work. This means creating a work environment that supports experimentation, failure, and learning, and allows employees to make decisions that affect their jobs. This also means creating space for employees to do new, creative, value-add work during the work week—and not just expecting them to devote extra time after hours. A good example of this is Google’s 20% time policy, where the company allows employees 20% of their week to work on new projects, or IBM’s “THINK Friday” program, where Friday afternoons are designated for time without meetings and employees are encouraged to work on new and exciting projects they normally don’t have time for.
According to this model, the five characteristics of a transformational leader are: Vision. Has a clear understanding of where the organization is going and where it should be in five years. Inspirational communication. Communicates in a way that inspires and motivates, even in an uncertain or changing environment. Intellectual stimulation. Challenges followers to think about problems in new ways. Supportive leadership. Demonstrates care and consideration of followers’ personal needs and feelings. Personal recognition. Praises and acknowledges achievement of goals and improvements in work quality; personally compliments others when they do outstanding work.
You may be asking yourself: What could investment in DevOps initiatives and my teams look like? There are a number of ways technology leaders can invest in their teams: Ensure that existing resources are made available and accessible to everyone in the organization. Create space and opportunities for learning and improving. Establish a dedicated training budget and make sure people know about it. Also, give your staff the latitude to choose training that interests them. This training budget may include dedicated time during the day to make use of resources that already exist in the organization. Encourage staff to attend technical conferences at least once a year and summarize what they learned for the entire team. Set up internal hack days, where cross-functional teams can get together to work on a project. Encourage teams to organize internal “yak days,” where teams get together to work on technical debt. These are great events because technical debt is so rarely prioritized. Hold regular internal DevOps mini-conferences. We’ve seen organizations achieve success using the classic DevOpsDays format, which combines pre-prepared talks with “open spaces” where participants self-organize to propose and facilitate their own sessions. Give staff dedicated time, such as 20% time or several days after a release, to experiment with new tools and technologies. Allocate budget and infrastructure for special projects.
The analyses done in the exploratory stage include correlation but not causation. Correlation looks at how closely two variables move together—or don’t—but it doesn’t tell us if one variable’s movement predicts or causes the movement in another variable. Correlation analysis only tells us if two variables move in tandem or in opposition; it doesn’t tell us why or what is causing it. Two variables moving together can always be due to a third variable or, sometimes, just chance.
But it’s important to recognize that there is no checklist or playbook. You can’t “implement” culture change. Implementation thinking (attempting to mimic another company’s specific behavior and practices) is, by its very nature, counter to the essence of generative culture.
Don’t contract it out to a large consulting firm to expediently transform your organization or to implement new methodologies or practices for you. Your teams will feel that these methodologies (Lean, Agile, whatever) are being done to them. While your current processes may temporarily improve, your teams will not develop the confidence or capability to sustain, continue to improve, or to adapt and develop new processes and behaviors on their own.
Within each category, the capabilities are presented in no particular order. CONTINUOUS DELIVERY CAPABILITIES Use version control for all production artifacts. Version control is the use of a version control system, such as GitHub or Subversion, for all production artifacts, including application code, application configurations, system configurations, and scripts for automating build and configuration of the environment. See Chapter 4. Automate your deployment process. Deployment automation is the degree to which deployments are fully automated and do not require manual intervention. See Chapter 4. Implement continuous integration. Continuous integration (CI) is the first step towards continuous delivery. This is a development practice where code is regularly checked in, and each check-in triggers a set of quick tests to discover serious regressions, which developers fix immediately. The CI process creates canonical builds and packages that are ultimately deployed and released. See Chapter 4. Use trunk-based development methods. Trunk-based development has been shown to be a predictor of high performance in software development and delivery. It is characterized by fewer than three active branches in a code repository; branches and forks having very short lifetimes (e.g., less than a day) before being merged into master; and application teams rarely or never having “code lock” periods when no one can check in code or do pull requests due to merging conflicts, code freezes, or stabilization phases. See Chapter 4. Implement test automation. Test automation is a practice where software tests are run automatically (not manually) continuously throughout the development process. Effective test suites are reliable—that is, tests find real failures and only pass releasable code. Note that developers should be primarily responsible for creation and maintenance of automated test suites. See Chapter 4. Support test data management. Test data requires careful maintenance, and test data management is becoming an increasingly important part of automated testing. Effective practices include having adequate data to run your test suite, the ability to acquire necessary data on demand, the ability to condition your test data in your pipeline, and the data not limiting the amount of tests you can run. We do caution, however, that teams should minimize, whenever possible, the amount of test data needed to run automated tests. See Chapter 4. Shift left on security. Integrating security into the design and testing phases of the software development process is key to driving IT performance. This includes conducting security reviews of applications, including the infosec team in the design and demo process for applications, using preapproved security libraries and packages, and testing security features as a part of the automated testing suite. See Chapter 4. Implement continuous delivery (CD). CD is a development practice where software is in a deployable state throughout its lifecycle, and the team prioritizes keeping the software in a deployable state over working on new features. Fast feedback on the quality and deployability of the system is available to all team members, and when they get reports that the system isn’t deployable, fixes are made quickly. Finally, the system can be deployed to production or end users at any time, on demand. See Chapter 4. ARCHITECTURE CAPABILITIES Use a loosely coupled architecture. This affects the extent to which a team can test and deploy their applications on demand, without requiring orchestration with other services. Having a loosely coupled architecture allows your teams to work independently, without relying on other teams for support and services, which in turn enables them to work quickly and deliver value to the organization. See Chapter 5. Architect for empowered teams. Our research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance. No one knows better than practitioners what they need to be effective. See Chapter 5. (The product management counterpart to this is found in Chapter 8.)
Have a lightweight change approval processes. Our research shows that a lightweight change approval process based on peer review (pair programming or intrateam code review) produces superior IT performance than using external change approval boards
Correlation looks at how closely two variables move together (or don’t) but it doesn’t tell us if one variable’s movement predicts or causes the movement in another variable. Two variables moving together can always be due to a third variable or, sometimes, just chance.
High-performing teams reported having leaders with the strongest behaviors across all dimensions: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition.
References
- books.google.com
- books.google.com
- Accelerate | Book by Nicole Forsgren, PhD, Jez Humble, Gene Kim | Official Publisher Page | Simon & Schuster
- arhohuttunen.com
- books.google.com
- Q&A on the Book Accelerate: Building and Scaling High Performance Technology Organizations - InfoQ
- books.google.es
- moi.vonos.net
- openlibrary.org
- play.google.com
- books.google.de
- books.google.com.br
- nicolefv.com