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.

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

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.

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

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.