Book Report: Accelerate: the science behind DevOps
This is a review of the book “Accelerate: the science behind DevOps: building and scaling high performing technology organizations” by Nicole Forsgren, PhD, Jez Humble and Gene Kim.
Read this book if:
- You are interested in improving the culture of your team or organization
- Are interested in software development processes
- Want to reduce burnout in your organization
- Want to discover how create and/or be part of a high performing team
- Are interested in scientific measurements of software development
As a book that describes itself as “the science behind DevOps”, it definitely meets that mark. I found this book very insightful and well reasoned. I believe they have hit the mark on how to unlock high-performing organizations. Maybe because it aligns with my “ship faster” desire.
Published in 2018, it’s done fairly well at remaining relevant with today’s industry. The main premise is that software delivery performance is critical to an organization and that performance is affected by leadership, tools, automation and a culture of continuous learning and improvement1. The authors break this down by explaining that they’ve measured organizations performance and statistically proved that software delivery performance drives organizational performance.
They have identified 24 capabilities that can be defined, measure and improved on2. These capabilities are broken up into five categories:
- Continuous delivery
- Architecture
- Product and process
- Lean management and monitoring
- Cultural
There were several parts to this book that stood out to me.
I had continuous delivery wrong
I thought I knew what continuous delivery meant. Automated deployments right? Nope. I mean, it is, but it’s about other things, including shipping faster.
The biggest piece I learned is the idea is that your branch should only last a day and at that point it should be merged back into the trunk3. It’s about limiting the Work In Progress (WIP) branches and highlighting them. Knowing you need to ship production ready code in one day requires the team’s culture and process to change. In fact, it causes the software to change. Everything needs to become more adaptable and flexible. Which sets up the software to implement the feedback from users more efficiently.
Throughout the book the authors discuss how culture changes can happen by changing how people work4. I love that this example was given so early in the book which helped me understand exactly how that can be true.
The power of surveys
I’ve done some statistics in my life. Not enough to be competent by any means, but enough to know I should know more. “Accelerate” does an excellent job of explaining their process of data collection in Part 3: The Research5. The authors go into detail about why surveys can be trusted because by using “carefully identified measures, latent constructs, and statistical methods to confirm the validity and reliability of measures”6. It all seems to make sense, but I promise you, I will have to reread these chapters when I go to work on my next survey.
Should you read this book?
I think there’s a lot of value in this book. That said, it’s something that’s more valuable when you’re open to learning, which means being open to being wrong. “Accelerate” does a good job of showing you the way to improvement and ends on the most telling piece of life philosophy, develop the right mindset, practice discipline, practice patience and practice practice7.
If you have thoughts, comments or questions, please let me know. You can find me on the Fediverse, Django Discord server or via email.
-
Chapter 17, Conclusion, Page 199 ↩
-
Appendix A, Page 201 ↩
-
Chapter 4, Technical Practices, Page 55 ↩
-
Chapter 3, Measuring and changing culture, Page 39; Chapter 16, High-performance leadership and management, Page 192 ↩
-
Chapters 12-15, Pages 131-177 ↩
-
Chapter 14, Why use a survey, Page 164 ↩
-
Chapter 16, High-performance leadership and management, Pages 194-196 ↩