When the book “Accelerate: Building and Scaling High Performing Technology Organizations” by Nicole Forsgren, PhD, Jez Humble, and Gene Kim came out, there was lots of buzz in the software development world. It still continues up to this day because the book proved to be very useful for many different professionals.

It took me a while to finish reading it. The main reason for that was that I have to read every single page until the very last in order to “count” that I’ve read the book and the second part of “Accelerate” was not too fast of a read. “Accelerate” has 3 parts: what was discovered when it comes to high performing teams from the State of DevOps survey results from years 2014-2017, the research behind the results explaining all the methods used, and the third part contains a case study of a transformation which applies the findings in practice.

Despite it not being a summer flick-kinda read and taking me months to finish and digest, I find the book extremely useful for anyone in software development and not only. It combines a lot of data and scientific research to make conclusions about high-performing teams. I started joking that if you’re in consulting, you should give this book to your clients. Especially the stakeholders in companies who want to implement a digital transformation. In this post, I’ll share a few points that I liked in the book.

Building quality in is faster in the long run

In the past, I have heard arguments that certain quality practices or measures were not implemented because we wanted to deliver faster. We’re in a hurry, we have a deadline approaching. Well, it’s no surprise that there are folklore sayings about hurrying. For example, in Lithuanian, we say “The devil collects the work done in a hurry”. While a Welsh proverb states “More the hurry, more the obstacles”.

As a QA, I have had conversations where I was asked: “Look, the client wants to deliver this as fast as possible, how can you as a QA help doing that?”. The first time I was asked, I was puzzled, I did not know how to prove my value. It is challenging to show that even intangible work does help in the overall goal. Now, I can strongly say that if there’s no quality-first mindset in software development - even if in the short run the team may deliver faster, but it may become hard to maintain the product in the long run. In “Accelerate” the authors talk about continuous improvement rather than a prescribed formula. This can be done in dynamically changing environments embracing capability models and focusing on skills needed to remain competitive. If we build quality (and security which is a part of quality) in, then the delivery performance gets better. An inspiring list of principles is a Rugged Manifesto.

In order to survive the market, the environments have to be adaptable and for that they need to concentrate not only on speed but also quality because with that we can have sustainable products causing less pain in the long run. I was very happy to read this:

“By building quality in, you get both speed and stability.”

Yes! The book also goes into what capabilities can help us to build quality in, and how measuring outcomes over outputs is a more beneficial way to measure software delivery performance. This leads me to… 4 key metrics.

4 Key Metrics

We often fall into a trap to measure outputs over outcomes. Some examples of outputs are code test coverage, lines of code, or velocity. These measures can be very easily played, though. It also lacks a lot of context and dimensions on what actually the state of the project is. In “Accelerate” 4 data-proven suggested metrics are:

1) Lead time - the time from commit to code successfully running in production.
Working to improve this metric leads to faster feedback, and, faster and more confident delivery and fixes.

2) Deployment frequency - the number of deployments.
When we deploy often and smaller pieces of work, it increases team motivation, reduces cost, risks associated with big bang releases and may improve cycle time.

3) Mean time to restore (MTTR) - the time it takes to recover from a failure.
Mistakes do happen. How quickly can the team recover from a problem? The lower this number is, the more confident and empowered the team can be. Things do fail, the best teams just know how to recover faster.

4) Change fail percentage - the % of changes that lead to failure.
If you are pushing code to production, are there any frustrations on the way like flaky tests that make the build fail? That impacts the team’s happiness and performance greatly.

I find these metrics extremely useful. They are more objective and harder to rig. The only challenge is to make them accessible in projects. Usually, the spot where most of these can be measured is your Continuous Integration (CI) tool. For example, Go.CD has a plugin that provides those metrics using the data from the development pipelines.

If we have metrics like that, it changes how risk management should work in the projects as well. Often we witness a risk management theater: boxes are checked so that when something goes wrong, it can be said that at least we followed the process. Instead of that, risk management could monitor team delivery by monitoring stability and quality using 4 key metrics, and communicating to the management if teams need support implementing Continuous Delivery (CD) or lean manufacturing practices which are capabilities related to high-performance. This means that we also need transformational leadership.

Transformational leadership is necessary for high-performance

I recommend “Accelerate” especially for leadership positions because they play a vital role in how organizations work. Even if there is a high-performing team in the organization, not having leadership’s support the team may burn out, lose their motivation, or simply face obstacles like lack of tools or organizational limitations on the journey to deliver fast, quality software. Here I remember an anecdote about a company’s CEO asking another company’s CEO about their success in having high-performing teams: “Where did you hire such extraordinary talent from?”. The successful CEO said: “I hired them from you.” All employees want to do the best they can at work, the question is if they are having a great environment and support to be their best selves.

The authors in “Accelerate” present the Westrum organizational typology model and based on research the highest performers are found in generative organizations.

Westrum organizational typology model The Westrum organizational typology model: How organizations process information (Source: Ron Westrum, “A typology of organization cultures”)

Transformational leadership is necessary for high-performing organizations.

Five characteristics of a transformational leader (Rafferty and Griffin 2004):
1) Vision
2) Inspirational communication
3) Intellectual stimulation
4) Supportive leadership
5) Personal recognition

Do leaders have a clear vision? Is success based on correct measures? Are leaders transformational by getting the best out of the employees? Asking these questions can help leaders to embrace a learning mindset involving continuous improvement.

In the third part of the book, there is a case study contributed by Steve Bell and Karen Whitley Bell. I found it to be a great example of how much leaders can make a difference. Here’s a quote from that part:

“Our tribe lead, Jannes, went to the squads and said, ‘If the quality isn’t there, don’t release. I’ll cover your back.’ So, we felt we owned quality. That helped us to do the rights things” Too often, quality is overshadowed by the pressure for speed. A courageous and supportive leader is crucial to help teams “slow down to speed up,” providing them with the permission and safety to put quality first (fit for use and purpose) which, in the long run, improves speed, consistency, and capacity while reducing cost, delays, and rework.

Conclusion

“Accelerate” is a book that proves with data what builds and scales high performing technology organizations. It is full of condensed “secrets” of high-performing teams based on the research which serves as scientific proof of why certain capabilities and practices contribute to creating better, faster, and stronger software delivery.