Book Summary: Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations

I had the chance to read Accelerate written by Nicole Forsgren, Jez Humble, Gene Kim, which is a follow up to The Phoenix Project, written by Gene Kim, Kevin Behr, George Spafford. (Disclosure: Yes, those are affiliate links. Help me with beer money if you buy the books and find this content helpful, but you’re not obligated to do anything!) The Phoenix Project tells the story of how DevOps came to be and Accelerate provides research into thousands of companies and pulls out characteristics and capabilities that determine a company’s performance. The thesis is that there is a significantly large gap between high, medium, and low performers. The success of a company rests on the practices by which the IT department operates, as the ability to deliver value at velocity is the only way companies pull itself away from competition.

Below I’ve summarized all the facts and high level things that I pulled out of Accelerate that struck close to home. In future posts I hope to be able to drill into these topics in more detail to see how we’ve applied some of these concepts, or what’s worked and didn’t work for us.

Continuous Delivery

• Use version control for all production artifacts, including application code, application configurations, system configurations, and scripts for automating build and configuration for the environment
• Automate deployment process. They should not need manual intervention
• Implement continuous integration, check in and run tests on every commit. CI process should create canonical builds and packages that are ultimately deployed and released
• Use trunk-based development methods. It is 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 have short lifetimes. No “code lock” periods, freezes, or stabilizing periods
• Implement test automation. Developers responsible for creating and maintaining
• Support test data management. Have adequate data to run your test suite, have ability to get necessary data on demand, condition test data in pipeline, and make sure the data is not the bottleneck for your testing pipeline. When possible, limit the test data you need to run your tests.
• Shift left on security. Integrate it into design and testing phases of software development. Include infosec team during design and demo, and use preapproved security libraries and packages.
• Implement continuous delivery. Keep product in deployable state over working on new features. System can be deployed to production or end users at any time, on demand.

Architecture

• Use loosely coupled architecture. Allows teams to work independently without relying on other teams for support.
• Architect for empowered teams. Teams that choose which tools to use do better at continuous delivery and in term drive better software development and delivery performance.

Product and Process

• Gather and implement customer feedback on a regular basis and incorporate into design
• Make the flow of work visible through the value stream. Teams should have a good understanding of and visibility into the flow of work from the business all the way through to customers, including the status of products and features
• Work in small batches. Slice work into small pieces that can be completed in a week or less. This can be applied at the feature and product level. By doing this you get short lead times and faster feedback loops.
• Foster and enable team experimentation. Let developers try out new ideas and create and update specifications throughout the development process, without requiring approval from an outside team. Particularly useful when working with the context of all of the above.

Lean Management and Monitoring

• Have lightweight change approval processes, typically through peer review. Much better than external change approval boards (CABs).
• Monitor across application and infrastructure to inform business decisions.
• Check system health proactively. Monitor system health using threshold and rate-of-change warnings to preemptively detect and mitigate problems
• Improve processes and manage work with work-in-process limits. This increases throughput and makes constraints visible in the system
• Visualize work to monitor quality and communicate throughout the team. Visual displays such as dashboards or internal websites contribute to software delivery performance

Culture

• Support a generative culture, which is predictive of IT performance, organizational performance, and decreasing burnout. This means good information flow, high cooperation and trust, bridging between teams, and conscious inquiry
• Encourage and support learning. Is learning considered essential for continued progress? Is it thought of as a cost or an investment?
• Support and facilitate collaboration among teams. This reflects how well teams interact in development, operations, and information security
• Provide resources and tools that make work meaningful. Give tools and resources needed to do job well
• Support or embody transformational leadership, which supports and amplifies the technical and process work that is so essential in DevOps. It includes vision, intellectual stimulation, inspirational communication, supportive leadership, and personal recognition. See diagram.

Originally published at https://elevensquared.blog on August 26, 2019.