What do you think?
Rate this book
The Science Behind DevOps
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.
113 pages, Paperback
Published January 1, 2017
3683 people are currently reading
15561 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 706 reviews
May 11, 2019
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.
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.
May 25, 2018
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.
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.
September 6, 2018
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.
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.
May 25, 2019
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 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.
April 19, 2018
Ergh, no.
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.
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.
July 12, 2021
Important research data but not an enjoyable read.
March 11, 2019
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.
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.
July 31, 2020
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.
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.
June 21, 2022
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.
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.
December 3, 2020
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.
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.
May 28, 2018
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.
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.
August 4, 2019
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.
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.
December 29, 2020
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.
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.
March 17, 2023
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:
Not: goodreads resmin çözünürlüğünü bozuyor. Şu abi bir yazısında eklemiş, oradan bakılabilir: https://jlottosen.wordpress.com/2020/...
Not: goodreads resmin çözünürlüğünü bozuyor. Şu abi bir yazısında eklemiş, oradan bakılabilir: https://jlottosen.wordpress.com/2020/...
March 24, 2019
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.
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.
September 14, 2018
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.
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.
January 12, 2019
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.
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.
May 31, 2021
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.
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.
March 31, 2020
The book provides a good toolbox on DevOps, Agile and Lean principles to follow when building a high-performance team and organization. The 2-page high-performance team, management and leadership practices table summary is particularly useful which I'm planning to use in work improvements, also the questionnaire for measuring organizational culture and the statement that we must consciously "create" time for our teams to deal with improving improving the work (which in long term is supposed to be more important than doing the work). The main thing that I was not impressed with was that while the conclusions and recommendations were cited to be based on extensive research and review of many organizations in the industry, form all of this data I would have expected much more interesting examples but there were very few (ING Bank and Sky Betting and Gaming) that are already over-used in DevOps scene and not presented in a very inspiring manner. Because of this it felt that the recommendations were "lacking a soul" (from other hand I might also be spoiled by Phoenix and Unicorn Project books).
Questions for measuring culture:
*Information is actively sought.
*Messengers are not punished when they deliver news of failures or other bad news.
*Responsibilities are shared.
*Cross-functional collaboration is encouraged and rewarded.
*Failure causes inquiry.
*New ideas are welcomed.
*Failures are treated primarily as opportunities to improve the system.
Lean Management components:
*Limit WIP
*Visual Management
*Feedback from Production
*Lightweight Change Approvals (peer review)
Lean Product Development principles:
*Work in small batches.
*Make flow of work visible.
*Gather and implement customer feedback
*Team experimentation.
Transformational leadership:
*Vision
*Inspirational communication
*Intellectual stimulation
*Supportive leadership
*Personal recognition
“The five most highly correlated factors are: Organizational culture. Strong feelings of burnout are found in organizations with a pathological, power-oriented culture. Managers are ultimately responsible for fostering a supportive and respectful work environment, and they can do so by creating a blame-free environment, striving to learn from failures, and communicating a shared sense of purpose. Managers should also watch for other contributing factors and remember that human error is never the root cause of failure in systems. Deployment pain. Complex, painful deployments that must be performed outside of business hours contribute to high stress and feelings of lack of control.4 With the right practices in place, deployments don’t have to be painful events. Managers and leaders should ask their teams how painful their deployments are and fix the things that hurt the most. Effectiveness of leaders. Responsibilities of a team leader include limiting work in process and eliminating roadblocks for the team so they can get their work done. It’s not surprising that respondents with effective team leaders reported lower levels of burnout. Organizational investments in DevOps. Organizations that invest in developing the skills and capabilities of their teams get better outcomes. Investing in training and providing people with the necessary support and resources (including time) to acquire new skills are critical to the successful adoption of DevOps. Organizational performance. Our data shows that Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance. At the heart of Lean management is giving employees the necessary time and resources to improve their own work. This means creating a work environment that supports experimentation, failure, and learning, and allows employees to make decisions that affect their jobs. This also means creating space for employees to do new, creative, value-add work during the work week—and not just expecting them to devote extra time after hours. A good example of this is Google’s 20% time policy, where the company allows employees 20% of their week to work on new projects, or IBM’s “THINK Friday” program, where Friday afternoons are designated for time without meetings and employees are encouraged to work on new and exciting projects they normally don’t have time for.”
“Technology managers, like so many other well-meaning managers, often try to fix the person while ignoring the work environment, even though changing the environment is far more vital for long-term success. 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 Last but not least, employees must be given the authority to make decisions that affect their work and their jobs, particularly in areas where they are responsible for the outcomes.”
“We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, 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. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
“We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.”
“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).”
“Knowledge is power, and you should give power to those who have the knowledge.”
“Westrum’s theory posits that organizations with better information flow function more effectively.”
“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.”
“What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.”
“much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes.”
“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. A good leader affects a team’s ability to deliver code, architect good systems, and apply Lean principles to how the team manages its work and develops products. All of these have a measurable impact on an organization’s profitability, productivity, and market share.”
Questions for measuring culture:
*Information is actively sought.
*Messengers are not punished when they deliver news of failures or other bad news.
*Responsibilities are shared.
*Cross-functional collaboration is encouraged and rewarded.
*Failure causes inquiry.
*New ideas are welcomed.
*Failures are treated primarily as opportunities to improve the system.
Lean Management components:
*Limit WIP
*Visual Management
*Feedback from Production
*Lightweight Change Approvals (peer review)
Lean Product Development principles:
*Work in small batches.
*Make flow of work visible.
*Gather and implement customer feedback
*Team experimentation.
Transformational leadership:
*Vision
*Inspirational communication
*Intellectual stimulation
*Supportive leadership
*Personal recognition
“The five most highly correlated factors are: Organizational culture. Strong feelings of burnout are found in organizations with a pathological, power-oriented culture. Managers are ultimately responsible for fostering a supportive and respectful work environment, and they can do so by creating a blame-free environment, striving to learn from failures, and communicating a shared sense of purpose. Managers should also watch for other contributing factors and remember that human error is never the root cause of failure in systems. Deployment pain. Complex, painful deployments that must be performed outside of business hours contribute to high stress and feelings of lack of control.4 With the right practices in place, deployments don’t have to be painful events. Managers and leaders should ask their teams how painful their deployments are and fix the things that hurt the most. Effectiveness of leaders. Responsibilities of a team leader include limiting work in process and eliminating roadblocks for the team so they can get their work done. It’s not surprising that respondents with effective team leaders reported lower levels of burnout. Organizational investments in DevOps. Organizations that invest in developing the skills and capabilities of their teams get better outcomes. Investing in training and providing people with the necessary support and resources (including time) to acquire new skills are critical to the successful adoption of DevOps. Organizational performance. Our data shows that Lean management and continuous delivery practices help improve software delivery performance, which in turn improves organizational performance. At the heart of Lean management is giving employees the necessary time and resources to improve their own work. This means creating a work environment that supports experimentation, failure, and learning, and allows employees to make decisions that affect their jobs. This also means creating space for employees to do new, creative, value-add work during the work week—and not just expecting them to devote extra time after hours. A good example of this is Google’s 20% time policy, where the company allows employees 20% of their week to work on new projects, or IBM’s “THINK Friday” program, where Friday afternoons are designated for time without meetings and employees are encouraged to work on new and exciting projects they normally don’t have time for.”
“Technology managers, like so many other well-meaning managers, often try to fix the person while ignoring the work environment, even though changing the environment is far more vital for long-term success. 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 Last but not least, employees must be given the authority to make decisions that affect their work and their jobs, particularly in areas where they are responsible for the outcomes.”
“We found that external approvals were negatively correlated with lead time, deployment frequency, and restore time, and had no correlation with change fail rate. In short, 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. However, it certainly slows things down. It is, in fact, worse than having no change approval process at all.”
“We found that where code deployments are most painful, you’ll find the poorest software delivery performance, organizational performance, and culture.”
“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).”
“Knowledge is power, and you should give power to those who have the knowledge.”
“Westrum’s theory posits that organizations with better information flow function more effectively.”
“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.”
“What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes and enable the behaviors we care about. What is important is enabling teams to make changes to their products or services without depending on other teams or systems.”
“much of what has been implemented is faux Agile—people following some of the common practices while failing to address wider organizational culture and processes.”
“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. A good leader affects a team’s ability to deliver code, architect good systems, and apply Lean principles to how the team manages its work and develops products. All of these have a measurable impact on an organization’s profitability, productivity, and market share.”
January 28, 2022
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.
October 12, 2019
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.
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.
May 13, 2019
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.
September 26, 2018
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.
June 11, 2023
- il faut lire qu’une partie sur trois
- ça décrit littéralement mon job
- il y a tellement de concepts j’aurais aimé un peu plus d’histoires pour savoir comment ils en sont arrivés là
En tout cas, un must read si on est Head of Delivery
- ça décrit littéralement mon job
- il y a tellement de concepts j’aurais aimé un peu plus d’histoires pour savoir comment ils en sont arrivés là
En tout cas, un must read si on est Head of Delivery
March 8, 2021
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.
Read
October 8, 2020Accelerate 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.
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.
November 2, 2020
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.
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.
May 24, 2020
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.
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.
July 8, 2021
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.
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.
November 27, 2020
The great accomplishment of this book is connecting concrete continuous delivery principles to company success based on research. Apart from this, I didn't learn much.
Displaying 1 - 30 of 706 reviews