Accelerate has consistently been described as one of the best books when it comes to DevOps and building technical agility in organizations. I finally got around to reading it and it was every bit as good as I had expected it to be.

The book is essentially presents the conclusions of a multi-year research program and contains a whole section on why certain research methods were chosen over others. I have been reading and writing a fair bit about agility and moving fast, so most of the things in the book were not new, but the solid research backing it means that “CI/CD is a must-have” is not just an opinion anymore. The authors have shown it to be a demonstrable trait of successful teams in the wider industry. 

Accelerate is a short-ish read, but it is dense with information. I am sharing my highlights from it below so that you can get a taste of what the book is like. If you like these semi-organized snippets, you should definitely read the book.

Preface

improvements in software delivery are possible for every team and in every company, as long as leadership provides consistent support — including time, actions, and resources — demonstrating a true commitment to improvement, and as long as team members commit themselves to the work.

Chapter 1 – Accelerate 

1. Small teams that work in short cycles and measure feedback from users to build products and services that delight their customers and rapidly deliver value to their organizations.
2. DevOps emerged from a small number of organizations facing a wicked problem: how to build secure, resilient, rapidly evolving distributed systems at scale.
3. The Forrester report states that DevOps is accelerating technology, but that organizations often overestimate their progress (Klavens et al. 2017). Furthermore, the report points out that executives are especially prone to overestimating their progress when compared to those who are actually doing the work.
4. The key to successful change is measuring and understanding the right things with a focus on capabilities — not on maturity.
5. Maturity models are not the appropriate tool to use or mindset to have. Instead, shifting to a capabilities model of measurement is essential for organizations wanting to accelerate software delivery.
6. Three reasons capability models are better than maturity models:
   1. Maturity models focus on helping an organization “ arrive ” at a mature state and then declare themselves done. Capability models focus on helping an organization continually improve and progress, realizing that the technological and business landscape is ever-changing.
   2. 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. 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.
   3. Capability models focus on key outcomes and how the capabilities, or levers, drive improvement in those outcomes — that is, they are outcome-based. Most maturity models simply measure the technical proficiency or tooling install base in an organization without tying it to outcomes.
7. Maturity models define a static level of technological, process, and organizational abilities to achieve. In contrast, capability models allow for dynamically changing environments and allow teams and organizations to focus on developing the skills and capabilities needed to remain competitive.

Chapter 2 – Measuring Performance

1. Velocity, lines of code, and other typical technical measures focus on outputs rather than outcomes. Second, they focus on individual or local measures rather than team or global ones.
2. Ideally, we should reward developers for solving business problems with the minimum amount of code — and it’s even better if we can solve a problem without writing code at all or by deleting code (perhaps by a business process change).
3. 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. 
4. 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.
5. In our search for measures of delivery performance that meet these criteria, we settled on four:
   1. Delivery lead time
   2. Deployment frequency
   3. Time to restore service
   4. Change fail rate.
6. Lead time
   1. This is the time it takes to go from a customer making a request to the request being satisfied.
   2. There are two parts to lead time: the time it takes to design and validate a product or feature, and the time to deliver the feature to customers. 
   3. In the design part of the lead time, it’s often unclear when to start the clock, and often there is high variability.
   4. However, the delivery part of the lead time — the time it takes for work to be implemented, tested, and delivered — is easier to measure and has a lower variability.
7. Deployment Frequency
   1. Reducing batch size is another central element of the Lean paradigm.
   2. We settled on deployment frequency as a proxy for batch size since it is easy to measure and typically has low variability. By “ deployment ” we mean a software deployment to production or to an app store.
8. Delivery lead times and deployment frequency are both measures of software delivery performance tempo. The key question becomes: How quickly can service be restored (if something goes wrong)?
9. A key metric when making changes to systems is what percentage of changes to production ( including, for example, software releases and infrastructure configuration changes ) fail. In the context of Lean, this is the same as percent complete and accurate for the product delivery process, and is a key quality metric.
10. The ability to take an experimental approach to product development is highly correlated with the technical practices that contribute to continuous delivery.

Chapter 3 – Measuring and Changing Culture

1. Organizational culture can exist at three levels in organizations: basic assumptions, values, and artifacts (Schein 1985).
2. Basic assumptions are formed over time as members of a group or organization make sense of relationships, events, and activities.
3. The second level of organizational culture are values, which are more “visible” to group members as these collective values and norms can be discussed and even debated by those who are aware of them.
4. The third level of organizational culture is the most visible and can be observed in artifacts. These artifacts can include written mission statements or creeds, technology, formal procedures, or even heroes and rituals.
5. Type of organization as defined by Ron Westrum- https://cloud.google.com/architecture/devops/devops-culture-westrum-organizational-culture
6. Culture enables information processing through three mechanisms.
   1. First, in organizations with a generative culture, people collaborate more effectively and there is a higher level of trust both across the organization and up and down the hierarchy.
   2. Culture emphasizes the mission, an emphasis that allows people involved to put aside their personal issues and also the departmental issues that are so evident in bureaucratic organizations. The mission is primary. 
   3. And third, generativity encourages a ‘level playing field’, in which hierarchy plays less of a role”.
7. We should emphasize that bureaucracy is not necessarily bad. 
8. Westrum’s theory posits that organizations with better information flow function more effectively.
   1. A good culture requires trust and cooperation between people across the organization, so it reflects the level of collaboration and trust inside the organization.
   2. Better organizational culture can indicate higher-quality decision-making. In a team with this type of culture, not only is better information available for making decisions, but those decisions are more easily reversed.
   3. Finally, teams with these cultural norms are likely to do a better job with their people, since problems are more rapidly discovered and addressed.
9. Failure in complex systems is, like other types of behavior in such systems, emergent (Perrow 2011).
10. Following the theory developed by the Lean and Agile movements, implementing the practices of these movements can have an effect on culture. You can act your way to a better culture by implementing these practices in technology organizations, just as you can in manufacturing.

Chapter 4 – Technical Practices

1. Continuous delivery is a set of capabilities that enable us to get changes of all kinds into production or into the hands of users safely, quickly, and sustainably.
2. There are five key principles at the heart of continuous delivery:
   1. Build quality in: “Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place ” (Deming 2000).
   2. Work in small batches: By splitting work up into much smaller chunks that deliver measurable business outcomes quickly for a small part of our target market, we get essential feedback on the work we are doing so that we can course correct.
   3. Computers perform repetitive tasks; people solve problems. One important strategy to reduce the cost of pushing out changes is to take repetitive work that takes a long time, such as regression testing and software deployments, and invest in simplifying and automating this work.
   4. Relentlessly pursue continuous improvement.
   5. Everyone is responsible
3. In order to implement continuous delivery, we must create the following foundations:
   1. Comprehensive configuration management. It should be possible to provision our environments and build, test, and deploy our software in a fully automated fashion purely from information stored in version control.
   2. Continuous integration (CI): high – performing teams keep branches short-lived ( less than one day’s work ) and integrate them into trunk/master frequently.
   3. Continuous testing: Because testing is so essential, we should be doing it all the time as an integral part of the development process. Automated unit and acceptance tests should be run against every commit. No one should be saying they are “ done ” with any work until all relevant automated tests have been written and are passing.
4. By giving developers the tools to detect problems when they occur, the time and resources to invest in their development, and the authority to fix problems straight away, we create an environment where developers accept responsibility for global outcomes such as quality and stability.
5. We discovered nine key capabilities that drive continuous delivery.
   1. The comprehensive use of version control is relatively uncontroversial.
   2. Configuration is normally considered a secondary concern to application code in configuration management, but our research shows that this is a misconception.
   3. Test automation is a key part of continuous delivery. Having automated tests that are reliable: when the automated tests pass, teams are confident that their software is releasable.
   4. Developers primarily create and maintain acceptance tests, and they can easily reproduce and fix them on their development workstations. It’s interesting to note that having automated tests primarily created and maintained either by QA or an outsourced party is not correlated with IT performance.
   5. Successful teams had adequate test data to run their fully automated test suites and could acquire test data for running automated tests on demand.
   6. Our research also found that developing off trunk/master rather than on long-lived feature branches was correlated with higher delivery performance.
   7. High-performing teams were more likely to incorporate information security into the delivery process. Their infosec personnel provided feedback at every step of the software delivery lifecycle, from design through demos to helping with test automation.
   8. A critical obstacle to implementing continuous delivery is enterprise and application architecture.

Chapter 5 – Architecture

1. The architecture of your software and the services it depends on can be a significant barrier to increasing both the tempo and stability of the release process and the systems delivered.
2. We found that high performance is possible with all kinds of systems, provided that systems — and the teams that build and maintain them — are loosely coupled.
3. This reinforces the importance of focusing on the architectural characteristics, discussed below, rather than the implementation details of your architecture.
4. In teams that scored highly on architectural capabilities, little communication is required between delivery teams to get their work done, and the architecture of the system is designed to enable teams to test, deploy, and change their systems without dependencies on other teams.
5. Organizations should evolve their team and organizational structure to achieve the desired architecture.
6. 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, so we can instead use that bandwidth for discussing higher-level shared goals and how to achieve them.
7. If we achieve a loosely coupled, well-encapsulated architecture with an organizational structure to match, two important things happen. First, we can achieve better delivery performance, increasing both tempo and stability while reducing the burnout and the pain of deployment. Second, we can substantially grow the size of our engineering organization and increase productivity linearly — or better than linearly — as we do so.
8. Architects should focus on engineers and outcomes, not tools or technologies.

Chapter 6 – Integrating Infosec into the Delivery Lifecycle

1. Infosec is a vitally important function in an era where threats are ubiquitous and ongoing. However, infosec teams are often poorly staffed and they are usually only involved at the end of the software delivery lifecycle when it is often painful and expensive to make changes necessary to improve security.
2. We found that when teams “shift left” on information security — that is, when they build it into the software delivery process instead of making it a separate phase that happens downstream of the development process — this positively impacts their ability to practice continuous delivery.
3. First, security reviews are conducted for all major features, and this review process is performed in such a way that it doesn’t slow down the development process.

Chapter 7 – Management Practices for Software

1. Limit work in progress (WIP), and use these limits to drive process improvement and increase throughput.
2. Create and maintain visual displays showing key quality and productivity metrics and the current status of work.
3. Use data from application performance and infrastructure monitoring tools to make business decisions on a daily basis.
4. WIP limits on their own do not strongly predict delivery performance. It’s only when they’re combined with the use of visual displays and have a feedback loop from production monitoring tools back to delivery teams or the business that we see a strong effect. 
5. WIP limits are no good if they don’t lead to improvements that increase flow.
6. Implement a lightweight change management process.
   1. We found that approval only for high-risk changes was not correlated with software delivery performance.
   2. 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.

Chapter 8 – Product Development

1. The key to working in small batches is to have work decomposed into features that allow for rapid development, instead of complex features developed on branches and released infrequently.
2. The ability of teams to try out new ideas and create and update specifications during the development process, without requiring the approval of people outside the team, is an important factor in predicting organizational performance as measured in terms of profitability, productivity, and market share.

Chapter 9 – Making Work Sustainable

1. The technical practices that improve our ability to deliver software with both speed and stability also reduce the stress and anxiety associated with pushing code to production.
2. In order to reduce deployment pain, we should:
   1. Build systems that are designed to be deployed easily into multiple environments, can detect and tolerate failures in their environments, and can have various components of the system updated independently.
   2. Ensure that the state of production systems can be reproduced (with the exception of production data) in an automated fashion from information in version control.
   3. Build intelligence into the application and the platform so that the deployment process can be as simple as possible.
3. 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):
   1. Work overload
   2. Lack of control
   3. Insufficient rewards
   4. Breakdown of community
   5. Absence of fairness
   6. Value conflicts

Chapter 10 – Employee Satisfaction, Identity, and Engagement

1. Employees in high-performing teams were 2.2 times more likely to recommend their organization to a friend as a great place to work, and 1.8 times more likely to recommend their team to a friend.
2. We found that the employee Net Promoter Score was significantly correlated with the following constructs:
   1. The extent to which the organization collects customer feedback and uses it to inform the design of products and features
   2. The ability of teams to visualize and understand the flow of products or features through development all the way to the customer
   3. The extent to which employees identify with their organization’s values
3. investments in continuous delivery and Lean management practices, which contribute to a stronger sense of identity, may very well help reduce burnout.
4. Being able to apply one’s judgment and experience to challenging problems is a big part of what makes people satisfied with their work.

Chapter 11 – Leaders and Managers

1. Being a leader doesn’t mean you have people reporting to you on an organizational chart — leadership is about inspiring and motivating those around you.
2. According to this model (Rafferty and Griffin 2004), the five characteristics of a transformational leader are:
   1. Vision
   2. Inspirational communication
   3. Intellectual stimulation
   4. Supportive leadership
   5. Personal recognition
3. Transformational leadership means leaders inspiring and motivating followers to achieve higher performance by appealing to their values and sense of purpose, facilitating wide-scale organizational change.
4. A transformational leader’s influence is seen through their support of their teams ’ work, be that in technical practices or product management capabilities.
5. …leaders cannot achieve goals on their own.
6. As the real value of a leader or manager is manifest in how they amplify the work of their teams, perhaps the most valuable work they can do is growing and supporting a strong organizational culture among those they serve – their teams.
7. Enable cross-functional collaboration by:
   1. Building trust with your counterparts on other teams.
   2. Encouraging practitioners to move between departments.
   3. Actively seeking, encouraging, and rewarding work that facilitates collaboration.

Read Next: Summary of “97 things every software architect should know”