Does technology actually matter? And how can we apply technology to drive business value? For years, we've been told that the performance of software delivery teams doesn't matter—that it can't provide a competitive advantage to our companies. Through four years of groundbreaking research, Dr. Nicole Forsgren, Jez Humble, and Gene Kim set out to find a way to measure software delivery performance—and what drives it—using rigorous statistical methods. This book presents both the findings and the science behind that research. Readers will discover how to measure the performance of their teams, and what capabilities they should invest in to drive higher performance.
Accelerate presents original research into how to organise effective software development organisations. This is direly needed.
The results indicate that DevOps and lean software development is the most effective ways to deliver software. Not only that, but loosely coupled architecture and fast feedback loops, among many other things, turn out to be highly predictive of high-performance software delivery. Given how I've written and talked about these topics for more than a decade, I can only be pleased. As Martin Fowler also touches on in his foreword, it's a full plate of confirmation bias bingo.
Research about software development has, in general, been weak and the results hardly credible. The Leprechauns of Software Engineering discusses how many commonly accepted truths about software development are, in fact, based on poor or non-existing research.
If the research presented in Accelarate is, indeed, solid, it's even more extraordinary. The book doesn't present the actual research, but discusses why it's trustworthy. Based on the description in the book, and what I know about science and statistics, I see no fundamental flaws. Given that I also want to believe the results reported, I welcome the research.
The book itself, unfortunately, is dull and repetitive. The language is bloated and impersonal, and the same points are presented multiple times. It may turn out that it'll work well as a handbook where one can easily look up and find important results, but as a continuous reading experience, it was boring.
An important book that could, and should, have been better written.
This is a good book. It’s great to have actual data to validate our assumptions or disprove certain pre-conceived ideas.
For people who are immersed in the Agile and Software Craftsmanship worlds and are already sold on the benefits of continuous delivery, this book won’t say anything they don’t already know or experienced but will certainly give them more ammunition (data) to make their case.
The first part of the book - with the results of survey-based research - is very nice. Although it is almost common practice nowadays to pursue such technical practices like continuous delivery, or organisational - like generative culture, it is always nice to see scientific correct proof for that.
Second part is devoted to the general guidance on how to perform statistically correct surveys. Not sure why it is included here, since it is a completely different topic, that should rather be covered in a separate publication.
Also one word of caution - the audio book is quite difficult to follow, be prepared to keep the pdf file with additional materials within reach.
Three stars at goodreads mean 'liked it' (compared to five stars 'it was amazing') so it is exactly what my perception is - a quite interesting book, but no more than that.
Redundant, boring and old. In all honesty, I am surprised that this book was even published in 2018, because it's so superfluous and recycled. It also does the classic 'you will find out about this in chapter x' all the time! And then you hope that chapter will go into the ideas more in depth, but no.
This book describes the findings of The State of Devops reports during a series of 4 years, but the information just doesn't work well in a prose format, it's one of those cases where pictures say a thousand words and where graphs and charts would have worked much better. The text in the book just explains those. When it does not, it goes through the definition of what Continuous Integration or Delivery is, preaches about when and where your automated tests should be run, and how one instills a culture of caring about Operations in your teams. In 2018 these are well-known factors, and these pieces of advice are not backed up with any use cases (there is just one at the end, which is more an office tour of wall artifacts than anything else...) so come across as theoretical and generic. Oh and let's not forget it also recycles material like the rugged manifesto, did this really have to be copied in the book?
Didn't learn anything new, I just thought it was annoying to have this information conveyed to me in this read the picture manner, without answering any whys.
This book is an attempt to make an extract out of "Lean Enterprise" & prove it using the "scientific" data from annual DevOps Report (that's being assembled by J. Humble & some associates for few years already) - sadly I can't figure out what's the point ... :
1. content itself is repetitive beyond all recognition - it's like re-discovering Scrum & going through it bit-by-bit. This was already described zillion of times, in a far more imaginative way. 2. this is mainstream already - within last 3 years at least I haven't met noone who needed to be convinced anymore ... 3. the "methodology" used to prove the thesis is VERY controversial - it's based mainly on self-evaluation in surveys ... seriously? anyone finds that convincing?
I understand that DevOps Report didn't get the expected attention, so authors tried slightly different approach, but this dish is already very cold.
The good part of this book is that it is based on evidence and even better: it shows us the methodology they used to avoid some problems.
The bad part is that the reading is a little bit boring because it has a report-like format. Besides that, it didn't bring any new information compared to other materials focused on DevOps, Lean, Leadership, and related.
Instead of focusing only on what "works", I think it could be much better if the book would present practices broadly used that have little or no effect. In my opinion, this content would be much rarer and valuable.
This book is probably a good present for the typical unconvinced top level manager. It's short enough that he might actually read it, well researched enough to fend of the obligatory wave of refutation and it offers a glimpse into what the future will have in store for those companies that don't understand the role technology is playing in the overall competitiveness of the company going into the 2020s.
The findings in the book match-up with what I've seen in the small with a high performance team leveraging most of what is depicted in the book (the impact of good architecture, small batch sizes, a lot of automation, the right test strategy, etc.).
It also properly highlights the role of top level management support has in fostering a generative culture. There's only so much you can achieve from the grassroots. Another thing that lines up with my experience.
So why does this book not get more than it's 3 stars?
It's a good overview, but if you have read the other books from the authors (like the Phoenix Project, Continuous Delivery or The DevOps Handbook) and maybe a bit Goldratt, Maurya, Reinertsen, Bungay, Doerr, Appelo and friends, then there are absolutely no new insights in here for you to find. I believe this book is at best a start. In order to learn the real kung fu, you'd have to dive deeper into all the referenced material and start experimenting.
You can also look at this book from another angle: That it's only a more top level management suitable version of the red pill that was the Phoenix Project (e.g. not a business novella). I also take the whole second part of the book (which was interesting though) as a general means to emphasise the findings in part one of the book in that regard.
Although I'm not in a position to judge this well and I have a bias towards the content of the book, the research seems solid enough to recommend this book to everyone interested in IT!
On personal experience I would also recommend to think about implementing the capabilities described in the book.
My only small concern (maybe someone with more background in scientific research will have more concerns?) about the science is about the data collection and sample groups. I wonder if by having a group biased towards DevOps as your starting sample group you might miss capabilities or working methods that work for different groups. I don't think this concern is something that invalidates anything in the book, but it might be interesting to try to tackle it or to try to reproduce the results with different sample groups.
This book is a must read for any leader in tech organisation. This book will scientifically proof that Continuous Delivery and Lean Management practices are significant contributors to IT and organisational performance.
Book is split in two parts firs one is going through all the findings from 4 years of DevOps report research. Second all the science behind the research, to eradicate any doubt of validity of findings and insights.
I heard a lot of praise about this book but it didn’t live up to my expectations. It’s written in a way that resembles an academic paper and presents a collection of truisms and surface level advice.
The point it tries to get across is that continuous delivery would greatly improve any organisation. It goes into detail of how the authors reached that conclusion and their research methods - that’s about it. The actionable advice seemed shallow to me.
O centro deste livro é a descrição de 24 habilidades (práticas) divididas em 5 categorias (Continuous Delivery, Architecture, Product and Process, Lean Management and Monitoring, Cultural) em times de desenvolvimento de software, baseado no resultado de pesquisas.
Apesar de ter gostado mais da primeira metade do livro, acredito ser completamente necessário para todas as pessoas que trabalham em times de desenvolvimento, não só para refletir sobre as práticas colocadas neste livro, como para potencialmente entender contexto e influenciar pessoas para aplica-las.
Um bom livro para entender um pouco sobre práticas ágeis e como elas se aplicam dentro de times de desenvolvimento, assim como algumas diferenças de comportamento ou tempo investido em situações diversas entre times de baixa e alta performance, entendimento de cultura e motivação - potenciais situações que podem levar a insatisfação e burnout.
Apesar de ter gostado do livro, uma coisa me chamou atenção e me despertou a vontade de ter novamente a pesquisa considerando diversidade: apenas 6% das pessoas entrevistadas são mulheres, 3% não binárias ou outros. 77% não se considera de grupos minoritários (oprimidos), 12% se considera. Porém os autores são explícitos que fizeram teste para evitar viéses.
Tam olarak isminin hakkını veren bir kitap. Okurken kendimden geçtim adeta. Yine mi haklıyım, bunu da mı en doğru biliyorum şeklinde. 🤪🤪 İşin şakası bir yana kitabı kısım kısım uygulayarak anlatmaya çok çalıştığım oldu ama bütün olarak bu şekilde ele almak gerekiyor. Mühim olan şöyle bir organizasyon oluşturabilmekte. Yoksa bu kutulardan sorumlu olduğunuzu en şahane hale getirin bir şey değişmiyor:
This book is a quick read and I think does a good job on showing how software delivery is tied to organizational performance. The book also ties in snippets from many other sources that if you had read many devops books you can quickly tie the larger point they are referencing, but if you haven't you will still make it through fine. I just found having the deeper context gave you a greater appreciation for the point they were trying to make in the book.
The main factors for software delivery performance they call out are: -lead time (commit to prod) -deployment frequency (how often you go to prod) -mean time to restore (how fast can you recover an outage or issue) -change fail percentage (listed but found not to be significant per the book.)
There is more depth about the items above, but i will leave that for you to discover in the text.
Another item i wanted to call out that was noted in the text is that external bodies (CABs) "..simply doesn't work to increase the stability of production systems..."
Another nugget which to me seems obvious, but to those not emersed in devops could gloss over is the concept of how gathering customer direct feedback leads to a more engaged workforce. The book discussed how having an engaged workforce leads to better company performance. It also mentioned that teams that understood how their work impacted the customer were more engaged. Well if a team is directly querying the customer for feedback per the lean startup movement on their product than it should be easy for them to connect how their product impacts the customer. Thus giving them line of sight to work their doing and how it's benefiting the customer and thus ultimately leading to an engaged workforce. If the teams are running a waterfall or other scaled methods where requirements are given or told to them, this method would lead to a disengaged workforce since they aren't connecting directly with the customer.
The last part of the book I want to call out is the transformational leadership piece where they called out 5 things: -vision (clear understanding of where we are going) -intellectual stimulation (challenges team to think about old problems in new ways) -inspirational communication (make employees be proud of being part of the unit/team) -supportive leadership (considers personal feelings before acting) -personal recognition (personally compliments the team when they do outstanding work)
The reason I gave the book a 4 was that i thought it could have given me more. Part1, Appendix A and Appendix B is really all of the book you need to read. Part2 is all about the statistics used to create part1 and i just didn't think it was needed. Part 3 was a single chapter on ING-Netherlands, that could have been longer in my opinion.
It's a good book that is a quick read that provides many references to other books that are on my lists either to read or have been read, enjoy.
This entire review has been hidden because of spoilers.
On the surface, it seems to be an easy-to-read book that advocates lean practices and backs them up with data. Unfortunately, it doesn't deliver in implementation. It's an amalgamation of the excellent, yet difficult to read Lean Enterprise: How High Performance Organizations Innovate at Scale or any of Gene Kim's keynotes from the DevOps Enterprise Summit.
Don't get me wrong, there are good things in this book. This is a great book to give to a non-tech exec who wants to be in the loop with the DevOps movement. It even tells us how to ship faster! Most of it, though, goes through the results of the State of DevOps survey, even dedicating a couple of dozen pages describing how a survey works (Interesting, but not relevant to the subtitle of the book). If you need to be convinced on the what is a high performer and what makes them a high performer, get this book.
But if you know the what and are looking for the how, you can easily substitute it with the DOES videos. Unfortunately for me, I have already seen them.
The book is good but overrated. The first part is the best, where it clarifies the findings, the second part explaining the science behind the data collection should be just an appendix, third part taking ING-Netherlands as an example is a mistake, ING-Netherlands cannot be used as a model, they have one of the worst culture and development environment.
The book made the mistake of mixing correlation with causation in many sections of part 1, despite their deep analysis of data, they fell into it.
Also, the study spent a lot of effort in data collection and analysis just to discover very obvious output, can you imagine a 4-year analysis to discover that using repo management like Git is important for reliability and delivery! Or 3 years of analysis to discover that experimentation and continuous learning increase employee satisfaction! Really!
The outcome of the study is very expected, and nothing is genuine. This does not need a full book! A blog post is enough. Save your time and Jump to Appendix A, it has all the beef in one small chapter.
I liked "Accelerate", a book that uses scientific research to show how certain practices and capabilities lead to high performing technology organisations.
The book was divided into three parts. The first part - results of research - was the most interesting and useful one to me. The second part - a general guide on how to perform research - wasn't that interesting as I knew a lot of it already. It felt unneeded. The third part - an example of how the best practices were implemented at one specific company - was ok.
I recommend "Accelerate" to most managers and leaders at technology organizations. It's a necessary book and I'm glad it exists.
I want to believe the findings presented in this book (in fact, I already believed these things before reading). Unfortunately, the repetitive, drawn-out and vague science-y handwaving does not convince.
It would perhaps have been better to not try to support the findings by repeatedly referring to appendices which explain very little apart from basic scientific method. A list of statistical tests used in a study (e.g. "we used a t-test") does not help to assess the validity of a study. I had expected to find in these appendices at least a list of the questions asked in the surveys used, and perhaps some summary statistics of the results.
Useful lean concepts are explained in a way that one can adapt and transform the organization and increase team performance. The book is focused in a small amount of generic lean concepts without digging into various implementation variants and this makes it comprehensive as a good handbook. While the first three halves are elevating knowledge on the DevOps governance the remaining part wastes reader's time in researching methodologies and survey methods clarifications and justifications, which in the end of the book there are no take-aways or aspects to remember. For students or scholars this information may be useful, whereas for professionals attempting to enhance their knowledge capacity this part becomes trivial. Author dedicates the last part into ING case study and how it transformed. Although tools and examples are insightful, there is no reference onto how virtual teams can implement similar practices and thus become effective.
In the first part of book, authors discussed the results of their research program and outlined why technology is key value driver and differentiator for all organization today. Authoress’s research shows that technical practices of continuous delivery have a huge impact on many aspect of an organizations. Continuous delivery improve both delivery performance and quality, also helps improve culture and reduce burnout and deployment pain. This book provides research-backed, quantifiable, and real-world principles to create world-class, high performing IT teams enabling amazing business outcomes. There is a good activity list to improve the performance of organization at the end of the book.
Disappointing. And a bit annoying. And repetitive. But not wholly without value. This may actually work better as a reference book. And I'm looking forward to talking to coworkers specifically about the chapter on Leaders and Managers. I'm not sure it would be helpful or reasonable - but I would have liked to have seen the actual questions and answers from the various years - perhaps there is a pointer to this in a digestible fashion online. Reading this straight through felt a bit like a slog. 2.5 of 5.
More a research report than a book - and I enjoyed it thoroughly. Not only was I impressed by the research outcome, but by the way the research was conducted as well. Both, outcome and process, are described in the book.
As former SRE highly recommend this for non technical leads and product managers. It has interesting statistical analysis on development time relation to low, medium and high performers (the faster deployment the more high performers org has), deployment even impacts how engineers feel, advocates the need for SRE/devops.
Accelerate is the kind of manual for engineering leaders, and it provides a group of knowledge about how to build high performing teams. As a researcher, I love the aim of publishing academic work without being tedious. The book has three parts. The first one presents the results of the survey conducted during four years of investigation. The authors discussed why software delivery performance (measured by lead time, deployment frequency, meantime to restore, and change fail percentage) matters and how it drives organizational performance measures like profitability, productivity, and market share, as well as non-commercial measures like efficiency, effectiveness, customer satisfaction, and achieving mission goals. The authors pointed out that Lean management and other technical practices impact culture. Regarding culture, one quote that I like about culture change is: "what my . . . experience taught me that was so powerful was that the way to change culture is not first to change how people think, but instead to start by changing how people behave — what they do." Another connection presented in the first part is that continuous delivery practices enhance delivery performance, impact culture, and reduce burnout and deployment pain. The fundamental principles of continuous delivery are: - Build quality in; - Work in small batches; - Simplify and automate repetitive work - Relentlessly pursue continuous improvement; - Everyone is responsible. Talk about agile without introducing software engineering is so awkward. The book bolsters that we must talk about software quality, delivery flow pipeline, and technical capabilities; otherwise, it's just noise without result. Based on that, the authors highlighted aspects of architecture for high performing teams: - Make large-scale changes to the design of their system without the permission of somebody outside the team; - Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams; - Complete their work without communicating and coordinating with people outside their team; - Deploy and release their product or service on-demand, regardless of other services it depends upon; - Do most of their testing on-demand without requiring an integrated test environment; - Perform deployments during regular business hours with negligible downtime. Instead of "introducing" agile frameworks, the book advises that we should explore capabilities from lean product management which are: - Limit work in progress; - Visual management; - Feedback from production; - Lightweight change approvals; - Gather & implement customer feedback; - Team experimentation. The final advice presented in the first section showed that managers who want to avert employee burnout should concentrate their attention and efforts on: - Fostering a respectful, supportive work environment that emphasizes learning from failures rather than blaming; - Communicating a strong sense of purpose; - Investing in employee development; - Asking employees what is preventing them from achieving their objectives and then fixing those things; - Giving employees time, space, and resources to experiment and learn. In part two, the authors compiled the methodological approach behind the research explaining the analysis methods and the design decisions. I love how they demonstrated that the results are statistically accurate and how they designed the model's constructs. In part three, they conclude with a discussion of organizational change management using ING as a study case. The key takeaway from the findings is that business agility asks learning capabilities and establishes new behaviors and new ways of thinking that build new habits that cultivate new cultures. My key takeaways from the book are: - Focus on promoting organizational learning; - Provide teams with time for improvement and innovation; - Focus on quality, protect teams to ensure quality; - Establish small, cross-functional, multi-skilled teams; support bridging structures so teams can easily communicate and collaborate; - Align, measure and manage to flow (matrixed, cross-functional value stream organization structure); - Apply disciplined problem solving to prioritized problems, analyze to identify root causes; - Eliminate unnecessary controls, invest instead in process quality, and team autonomy and capability; - Visualize and analyze workflow, identify obstacles to flow; - Engage with and learn from customers and teams; - Reduce technical debt; - Integrate unit tests, regression tests, and automation tests as part of every commit and build.
Unfortunately I read a physical copy of this book, so my notes are scrawled across 5 pieces of paper instead of neatly categorised in Goodreads, making it much harder to share the gems.
I deeply appreciated the rigour brought by this book. So many books about software and software development are wishy-washy rubbish presenting ideas as best practices with no more than 0 to 2 case studies or examples of high performance; Accelerate brings a level of rigour and research I've rarely seen in software before and definitely never in a book (usually only in dense literature.) Must read for anyone working in software.
This book feels like a mix of everything: some very good recommendations based on multiple surveys, the scientific explanation about the outcome of the surveys and a case study. Besides that I really like the message of the book and appreciate the values to create an accelerated environment I wasn't impressed by the book. It often stays very high level and jumps straight into the next topic. Probably a good read for newbies in software development but not so much if you're already familiar with all the mentioned ideas.
this should be mandatory reading for every software engineer. it scientifically proves how practices (e.g. lean approach, user-centric, CI/CD, trunk-based dev) can improve software metrics (the ones that matter), as a side-effect, people's happiness is positively affected.
This is a glorified statistics report. I haven't read "The State of DevOps" report yet, but I imagine it said all this book said, in a more succinct manner. What they had to say was important, and I agree with their research that if the technology in your organization doesn't follow these practices, you'll be left behind.
But oh my goodness, how they said it. It was awful; you can tell these folks are used to writing statistical reports. They laboriously said "This is what we will show you. This is what we are showing you. This is what we showed you" to the point I wanted to claw out my eyes. They also use very generic terms that don't hold their specific meaning very well. For example, immediately they define 24 practices (but call them capabilities) of organizations with an innovative culture. I hate the use of "capability" used as more of a noun than an adjective: "capability" should be the degree to which you can accomplish X, not X itself. (They should've used "practices" or "indicators".) Similarly, they discuss Westrum's organization construct, which to me is on a spectrum; you either fall to the left/poor/pathological ranking on the construct, or you fall to the right/good/generative ranking. I guess they say that generative company cultures are Westrum organizations. *shrug*
The diagrams were simple enough to be inane, as they were little boxes with arrows that repeated what the text said without any further illumination. I also found that they explained the wrong things; I didn't need to be reminded of the difference between primary and secondary research, but a definition of what they considered to be lead time would've been helpful. And though it was helpful to discuss latent constructs and manifest variables, they didn't need to define manifest variables twice within three pages. (I think they needed a human, not a statistician, to write this book.)
The third part was alright. It was necessary, to flesh out their statements into a Real Book, and illustrate how their findings can work in a real company. ING sounds like a fun place to work.
Publishing the book seems like a cash grab. And, Jeff Sutherland's Art of Doing Twice the Work in Half the Time was a more engaging read. I'd say their both content is on the same level of importance, though. That goes to show you how important writing and presentation are.
The second section is an exhaustive (at least, it was exhausting to read) treatise on how to conduct statistically significant surveys. I nearly rated this book as two stars because of this section. It’s clear the authors are extremely sensitive to questions about the legitimacy of their findings because they spend so much time explaining surveys in general. Personally I found it boring and would have found the rest of the book more compelling if they had left this section as a short appendix.