Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim

Title: Accelerate: Building and Scaling High-Performing Technology Organizations
Authors: Nicole Forsgren, Jez Humble (Continuous Delivery), and Gene Kim (The DevOps Handbook)
Published: 2018 by IT Revolution
Pages: 288
My rating: 3/5 (part I of the book 4/5)
Goodreads.com rating: 4.15 (754 ratings)
Prerequisites: Some knowledge about DevOps is good but not mandatory
Whom I recommend: Developers, architects, and their managers
Tip: You don’t have to read the whole book, part I has the “main message”.

This book is about the famous State of DevOps Reports; some kind of recap from years 2014-17. What have they found, how have they improved the survey over years etc?

The subject of the book, DevOps, was the key thing why I chose to read this book. The other reason was that it is written by famous authors in the DevOps world (Continuous Delivery by Jez Humble and The DevOps Handbook by Gene Kim are both 5/5 must-read books for every developer).

The book has three parts: analyzing State of DevOps Reports (“what we found”), analyzing the research/surveys (“the research”) and “transformation”.

The first part is quite interesting, 4/5. There is all kind of things they’ve figured out from the State of DevOps reports. For example, what are common things within high performers? Is there some commonality how they use version control? Is there some difference in leadership or organizational culture between low and high performers? Why DevOps helps to perform better? Many of the findings are not that surprising (results are what we can guess). But the difference is that they have a material that proves it! (If you believe in statistics.)

The second part (“the research”) is an analysis of the survey they had made for the State of DevOps Report. It wasn’t really interesting, but it gave much more credibility to part one and the State of DevOps Report. They analyze questions and result deeply. They have done a lot of work on it! If you are a researcher or interested in statistics, this part is for you.

Third part, sorry but this was even boring, waste of time. To be honest I don’t even remember much of it. If you read the book, I suggest skipping this part. This is a case study from real life by other authors.

Effects of Continuous Delivery

I’ve been really interested in DevOps for a couple years, especially in continuous delivery (CD). Reason for this is in my history of manual (sometimes painful) deploys. That time I thought “doesn’t work on our organisation / project / code / programming language. After that, I have read few books about DevOps. I have been thinking more and more that CD is possible and it has powerful effects.

CD has a big part in the Accelerate, which is not surprising while the book is about DevOps. In this “chapter” of this blog post, I will give some kind of summary what effects does CD have according to the Accelerate (and thus also State of DevOps Reports).

Continuous delivery improves both delivery and performance quality.

Better Software Delivery Performance

In my opinion, this is an obvious effect of the CD, and this is the main reason to do CD in the first place. Few reasons why CD improves software delivery performance:

• Deployments aren’t big-bang updates,
  
• Able to do during normal working hours,
• Less time-taking manual work,
  
• Lower risk of human error and
  
• Same automated process for each environment.

In the research authors found that CD has a positive effects on these measurements:

• Delivery lead time,
  • Deploy new features faster to the customers.
• Deployment frequency, and
  • Deploy more often.
    
• Time to restore service.
  • Recover faster from failures.

So it is not only gut feeling that CD improves delivery performance, those are measurements that show that CD really improves delivery performance.

Less Deployment Pain

Our research found that improvements in CD brought payoffs in the way that work felt.

The editors of the book found that where deployments are most painfull, there’ll be poorest software delivery performance, organizational performance, and culture. From this we can conclude that it is worth to reduce deployment pain, especially if there is a lot of it.

With CD we can reduce this pain significantly. My experience from where deployment pain can consist of:

• Manual database migrations: “Did I remember to do all the migrations?”
• Manual configuration updates: “I surely did forget some configuration…”
• Inconsistent packages: “Should I also update package A? Or was it B? Last time I forgot to update some package but I don’t remember what it was.”
• Environment confusion: “Oh shit! I should’ve updated the test environment but I updated the production!”
  

Those are real pains that I have had during manual deployments in my career. CD can help with all of those and reduces the deployment pain so we don’t have to worry that much. At least it has helped me with all of those situations.

Less Burnout

The research in the book found that technical practices, like CD, reduces feelings of burnout. Deployment pain was mentioned one of the things that correlate with burnout.

Deployment pain can lead to burnout if left unchecked.

Less Rework

What is rework? Bugs, hotfixes, emergency patches, for example. Those make us do something again that we thought was already finished.

Continuous delivery predicts lower levels of unplanned work and rework in a statistically significant way.

Organizations with CD used 49% of their time on new work, while organizations without CD used 38% time on new work. Even if that isn’t a revolutionary difference, it is a statistically significant difference. I’d interpret that with CD there are fewer bugs in the software.

Strong Identification With The Organization

Employees in high-performing organizations were 2.2 times more likely to recommend their organization as a great place to work.

How does CD help to get stronger identity with the organization? One reason according to the book is that when employees are enabled to do their best work (which CD enables), they identify more strongly with the organization and are willing to go the extra mile to help it be successful.

One reason why CD improves job satisfaction according to Forsgren et. al was that it is better to let computers do (boring) repetitive tasks. Then employees can focus on things that make them satisfied with their work: use their knowledge in solving challenging problems.

Conclusion

In this blog post / book review I wanted to recap what impacts does CD have according to the Accelerate. If you got interested in the topic while reading this blog post I recommend you to read the book (or just part I).

Another interesting subject would have been to write what requirements there are for CD. The book covers that area really well. According to the authors, technical capabilities that are important for CD are:

• Version Control,
• Deployment Automation,
• Continuous Integration,
• Trunk-Based Development,
• Test Automation,
• Test Data Management,
• Shift Left on Security,
• Loosely Coupled Architecture,
• Empovered Teams,
• Monitoring, and
• Proactive Notification.

But if I write about those also I will practically rewrite the book. Interesting topics that I have to keep eye on my daily work! I could even write blog posts about all of them.

ps. I just read the Clean Architecture by Robert C. Martin (Uncle Bob). Loosely Coupled Architecture was the key point of it.