Even in 2024, Accelerate remains a must-read for improving software delivery performance. Seven years after its release, the book’s lessons are as relevant as ever, thanks to its practical advice and real-world data. While the first part is especially impactful, the entire book offers valuable insights that apply seamlessly to modern AI-driven tools and systems.

One of the book’s greatest strengths is its focus on achieving meaningful outcomes rather than merely checking boxes. It makes a compelling argument against maturity models, stating:

> “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.”

The authors emphasize measuring what truly matters, such as delivery lead time, deployment frequency, time to restore service, and change fail rate. These metrics ensure teams focus on results, not unnecessary busywork. As they put it:

> “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.. (Second,) it shouldn’t reward people for putting in large amounts of busywork that doesn’t actually help achieve organizational goals.”

Overall, Accelerate is an exceptional guide for improving software delivery and team performance. Its ideas are simple to grasp, practical to implement, and enduringly relevant. For anyone working in tech or leading teams, this book is just as valuable today as it was when it first came out.

Accelerate will convince you that modern agile/devops development practices are worth investing in and will bring you business benefits. At least, that is the goal of the book. It explores survey results from 3 years of DevOps survey, explain why they are trustworthy and relevant and what you can learn from them. It does so in a very convincing way if I may say so. I personally experienced most of the promoted practices to be useful and therefore probably didn't need convincing. If I did, this book might have been able to do so.

The DevOps survey is an industry survey originally done by Puppet Labs for exploring Continuous Delivery and DevOps practices in the industry. The first DevOps survey was in 2014 and the book takes 3 years of survey results (3 surveys) and shares the results and the conclusions of these results. The book consists of three parts: (1) What we found, (2) The Research, and (3) Transformation.

The first part shares the results and conclusions of the DevOps survey. Good development and continuous delivery practices result in less stress, better quality, and better business results. This part summarizes different practices and how they correlated with improved business success. I felt most of the practices were not controversial (for someone with an agile background) although there were some exceptions (how far should you go in not standardizing tools) and areas not covered. Especially the area of organizational and team structure was not covered and, at times, the book suggested traditional organizations and traditional role divisions. This was unfortunate as it would have been interesting inclusions... but not covered well in this book.

I actually enjoyed the second part of the book, which had nothing to do with software development but explains the different research methods and practices applied. It explains different data collection strategies and why a survey was the right strategy for the questions the authors were asking. One skepticism I had (still have) is that the selected target population (people familiar with DevOps) causes a self-selection bias and therefore invalidates the findings when extrapolating to the entire industry. The authors, unfortunately, didn't discuss that much, but it did come up with arguments on why they should restrict the target population to people familiar with DevOps. The arguments were good... though not fully convinced me. Still, I found part 2 unusual and interesting.

Part 3, transformation, was small and not written by the authors. Instead it provided a case study of lean management practices by Steve and Karen Whitley Bell. The case study was from ING Netherlands. Although I enjoyed the case study, I did wonder at times why it was included as it didn't actually talk about the majority of the practices of the book. It mostly focused on Lean Management and Lean Transformation practices. Nevertheless, I enjoyed reading the case study.

All in all, Accelerate was an enjoyable little book. It didn't provide huge new insights to me, which was not the intention of the book. The intend was to share evidence (science) that some existing modern practices actually work. In that, the book succeeded. I would not recommend the book to people who want to understand these modern practices in-depth, for that, this is the wrong book. I would very much recommend the book for people who want to understand (and be convinced) that these modern DevOps/Development/Agile practices can have a positive effect on your business... and they are worth investing time and resources in. Good book, recommended, 4 stars.

Excellent book! It provides clear explanations of Agile principles and provides a pragmatic approach on how to apply them. If you're a Scrum manager buy this for your team. They will thank you for it.

I’ve lived in and consulted for many companies that would benefit from transforming their culture. If you are a leader in a company, and you 1) want to validate perceptions of company performance from the inside, and 2) want to continuously improve, read on.

“The most innovative companies and highest-performing organizations are always striving to be better. High performing companies 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, and 5 times lower change failure rate (1/5 as likely for a change to fail).”

The reasons for embarking on this DevOps journey of acceleration and transformation are many. Leaders who want to realize this level of performance will get more loyalty and work out of their current people and attract awesome new ones. They will build better, more secure software--and a mature software delivery capability provides a competitive advantage to any business. This book provides evidence and research to back these assertions.

Accelerate offers clear and compelling guidance to begin this shift no matter a company’s current level of maturity, covering the spectrum of roles from leaders to doers, from coders to architects to managers. If you are pressed for time, chapters are focused and easy to consider in turn, and provide excellent implementations recommendations.

Leaders will be especially inspired by Part 3, a case study about a real Transformation. It all started by the willingness to change.

DevOps is a cultural movement that feeds value delivery and growth within an organization. If you are responsible for any aspect of building secure, resilient rapidly evolving distributed systems, buy this book! Read it on your next plane ride and begin your journey of differentiation and transformation with the inspirational and executable guidance it offers.

Accelerate is a data based discussion of how technical practices relate to overall organizational performance. Neither technical practices, nor project management methodologies, nor management practices work in isolation and this book provides some evidence about how People Technology and Process interact to help delivery work. While I was familiar with the work, I took far to long to get around to reading the book.

The “data” behind the book is survey data. Fosgren and Humble surveyed a number of organizations and the data they present supports what I and others have observed anecdotally: technical practices play a key role in defining how an organization can deliver. Part one of the book presents the findings (which are summarized in an appendix) Part two explain the methodology and why the surveys can be considered useful objective data.

Over all, the book is a worthwhile, inspirational, read that also provides a foundation for introducing change. My only reservations are about the presentation. There is a bunch of great stuff in the book. But the connection between the parts is a bit disjointed, and different readers may find the book uneven. While the second part about methodology was interesting, it also felt like much of it could be relegated to an appendix. The third part of the book was a case study of organizational management, which was somewhat connected to the devops practices described in part one, but more focused on the role of management practices than dev ops ones than the impact of practices.

Process and team are deeply intertwined. And in team dynamics, the balance between objective and subjective measurements is hard to find. This book is a good first step in explaining how to measure what matters and how doing so can help you team. Just be prepared to skim parts of it at times.

This book was excellent, I read it twice before reviewing. They scienced the crap out of DevOps and go to painstaking lengths to identify what can and should be measured, and what those predict. Very helpful if you are looking to baseline your DevOps capability and identify areas for improvement around key outcomes.

Fair warning though, the book doesn't go into detail on how the capabilities identified/measured work together, the correct combinations, or proper order. Recommend picking up Lean Enterprise and Continuous Delivery by Jez for that. So it's not that the authors are naive to this, it's just not the intent of this book. On the contrary I'd say they are very aware of what can be measured and what would be speculation--and this book is scoped to what they could measure.

With that in mind, it actually places appropriate limitations on the conclusions you can draw from their results--an atypical (but welcome) admission they make early on. They can only measure outcomes, not intents. So they show behaviors and how they correlate to outcomes, but warn the reader to understand the why behind those behaviors before trying to adopt them blindly. Basically a nice way of saying, "Don't be a #cargocult."

In Lean Enterprise, Jez and his co-authors make several recommendations on combinations and order, as well as the why behind each. I appreciate that this book only focuses on what can be measured--it provides a good baseline from which to look at my own organization's practices. But it does assume that the reader is familiar with DevOps and isn't looking to understand the why or the how.

I highly recommend this book.

When I originally posted my review, I said that I would be glad to amend or even delete it based upon my concerns being answered or their being shown to be incorrect. One of the authors, Jez Humble, took the time to respond to me. I still have some lesser concerns but I am satisfied by his response. There was peer review of the research and DORA was not formed until after the research had been submitted for review. Since I was wrong about those points, I have upgraded my rating and have revised my review which starts in the next paragraph.

Note that I make no claim to be as skilled when it comes to research as is Forsgren. Hands down, she has an impressive resume and experience which makes me look like what you scrape off the bottom of your shoe in comparison. When I approach this book and the research, I am concerned regarding the use of Snowball research. However, I recognize how hard it is to conduct research in the workplace and the so-called "real world" outside the laboratory. When reading this book, my main point would be to keep in mind what the authors openly say, to their credit, that the research presented does not lead itself to predictive or causal analysis. However, it can be used to draw inferences that those implementing DevOps can find very valuable. Use this book to expand your ideas of how to improve software delivery.

Well worth to re-read and use as a guide as your travel on a path and journey of change - Learn, Succeed, Fail, Learn, Adjust - repeat - and with an open mind you will succeed - remember to share the learning and failures along the way -

Great book on devops

O melhor livro sobre cultura devops aplicada com a conceitos científicos. Fantástico.

Das Buch ist höchstknteressant. Der wissenschaftliche Ansatz unterscheidet es von vielen anderen Büchern. Hier wird befragt, gemessen und verglichen. Die Fazits aus dem Research und die Handlungsanweisungen, sowie die Möglichkeit das eigene Unternehmen und die Skalen einzuordnen sind wertvolle Grundlage, um die eigenen Prozesse an der richtigen Stelle zu optimieren. Zudem geht es nicht nur um Business-Wert sondern auch um die Angestellten und ihre Gesundheit.

Great book on actionable improvements in DevOps a company ( and also on an individual level) can make to improve performance, well-being, and output.

Why do I like this book and why do I think it is worthy of reading, reviewing and recommending ahead of a host of other books on DevOps?

1. It is short enough and accessible enough to be reasonably recommended to and consumed by a range of roles outside of the technology function.

2. It is written by and recommended by a number of people who clearly know their onions: Jez Humble, Nicole Forsgren and Gene Kim are all multipublished, award winning authors who have been involved in the State of DevOps survey for an extended period of time. Martin Fowler (who writes a forward) is one of the founding fathers of Agile and has written profoundly on many aspects of the programming craft

3. It seeks to justify its assertions with a range of quantitative methods which are pitched at the right level…you could use these ideas both to structure a business case and as a measurement framework to report against it.

4. It explores a range of technical, organizational, managerial and cultural aspects that combine to provide a step change in software development capability. It isolates atomic drivers of improvement. It describes positive and negative feedback loops to be aware of.

5. It connects those ideas into a coherent programme and suggests how you might go about adoption.

Apart from all of the practical ideas and the way it connects them I think the most interesting thought it left me with was this. Not only is high performance in the technology space going to offer a key differentiator for businesses in the future but that high performing technology function can be a catalyst to a high performing organization full stop.