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

I read this book to complete the DevOps picture from the manager's and the architect's point of view.As DevOps engineer and developer with 30 years of experience, I find hard to stomach the notion supported by this book that developers should be free to choose their tools. The book goes on to assure us that the upside of doing so far outweighs the downside. I strongly disagree.There is a thing called 'technical debt,' which is the sum of time and effort one has to pay to keep up with the tools one is 'married' to. To master a tool one has not only to learn the first version encountered but also those that follow in its evolution, and track new and discontinued capabilities during the course of the tool's life. This happens whether you learn C, Python, Java, or any other substantial language and tool in which one needs to remain proficient.Now imagine multiple projects using languages and tools at the whim of the team members. The overall list of technologies in use would be a long open-ended list in no time. What skill requirements do you pass on to HR to recruit new talent? How many candidates will be a good match for your large list of technical requirements?The argument in favor of such dangerous freedom is that otherwise developers may have to use tools they hate.Choosing the staff and the tools of a project requires careful consideration. It's at this point that you choose the best possible match. Consult the team members if you will, but it should not be up to them to decide, but to the project leader. Otherwise imagine if Team A chooses Confluence for documentation, while Team B uses Office 360, and yet Team C goes for TEX. After a few years you will have a rainbow of documentation formats. How is that better than having a consistent one?Developers like to use the tools they mastered, when not looking to learn a new one, and yes that is important, but what you do is to group people with skills pertinent to the project from the outset, so nobody will hate it.This notion that developers should be the ones choosing a project's technologies, really broke the spell of this book for me. How could they say that, and what sort of measurements did lead to such result?

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.

If Continuous Delivery, DevOps Handbook, and other like books are technical required reading, this book should be managerial required reading. Accelerate highlights the business value for maturing a DevOps capability by covering a new way to measure software delivery. The perspective I obtained from Accelerate is there is a science to identify the right work at the right time to create a smarter SDLC. The point is, it isn't really DevOps, but BizDevSecOps, working in a Generative culture of harmony bliss.

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.

The good:Change Approval Boards are statistically useless. The team making the change knows better. (If we believe the analysis.)Latent Measures in Surveys are importantYou cannot buy some other company's process and drop it in.You will have to experiment for yourselves.Definitions of Low, Medium, High performing teams.Problems with Surveys in DevOps occur when subjects think they will loose jobs over making processes more automated. (Believes anonymous feedback helps this -- doesn't get into any examples of getting one's lunch eaten.)The BadThe data is not public. It is just their word. Though, there is a great air of believability about the findings. In other words, this is not an open peer-reviewed paper, but, trying to pull intelligence out but keep the data hidden. This is the main reason I have marked four out of five stars.

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.

DevOps, roughly speaking, seeks to get IT workers to interact with each other more – particularly when they are in different functional roles. Authors Humble and Kim have led this movement and pioneered annual studies to ascertain its progress among practitioners of technology. In this book, they team together with Forsgren (a PhD who brings a rigorous knowledge of statistics and data collection to the table) to present their findings and explain their methods.IT professionals are notorious for trusting what a computer says over what their fellow humans say – even when the computational figures can be shown as inaccurate. They tend to distrust “subjective” surveys (even the most rigorous) over “objective” data sources. In this work, Forsgren runs head-first against that prevailing wind to sail cleanly into the harbor of first-rate technology organizations.In this work, these three authors share what to look for in high-performing organizations with technology centers. They distinguish those from characteristics of other clusters with mid-level or low performance. In an ever-changing, competitive tech environment, these findings, grounded in rigorous data collection and analysis, shine a light onto what to aspire towards in an IT group. Reading them can save needless experimentation as it confirms employees’ collective instincts as to the path forward.Information technology is now central to our lives in modern societies. Thus, it is important to just about every major corporation (i.e., a “vertical”). Those who manage, work in, or interface with technology sectors can benefit from learning what a healthy tech workforce looks like. That is this book’s main audience. Researchers about, teachers of, and students in computer science serve as another market as these groups learn about what modern workplaces look like in the “real world.”I’ve been a fan of the DevOps movement for a while now. I’ve worked in environments (academic research labs) that practice DevOps principles since 2001… well before the movement became organized. The ability to wear many hats and think through various functions just seems beneficial towards producing high-quality software. In recent years, Kim and Humble have articulated the foundations of this movement. In this book, Forsgren’s addition of grounding their theories in rigorous data analysis is welcomed and serves to transform the tech industry even further.

Great book for DevOps beginners to understand how it helps to deliver apps faster and better. I really enjoyed this book.

An excellent overview of the DevOps culture, based on detailed research and hands-on experience, with very actionable tips and advice.

It looks like a technical book but it is not, it is a strategy book.With digitalization getting stronger, this book will be powerful, not just a DevOps book.

This book is an essential read for engineers and leaders in legacy companies looking to transform and make technology a differentiator

Good summary for practical approach for effective software based organization management. Loved it.Will definitely read it again from time to time.

The book opens with 2 sections on best practices and observations from other real world organizations, and concludes with a section on what leadership must do to execute by looking at the ING organization

While this book relays some experimentation and statistics for “proof” it seems to be very superficial. If you’re looking for a book to validate your opinions then this might be helpful. Otherwise there are better books out there, some by these same authors.