The setup

After I publish this blog post I’ll start my new job with Armakuni. As part of their onboarding process they get you a copy of the book Accelerate. There was no need for them to buy me a copy because I already had the book, and have already read it. But I thought it will be a good idea to re-read it and do a review of it.

Context

When reading this book, written by Nicole Forsgren, Jez Humble and Gene Kim, I was already aligned with their conclusions. Or as Fowler puts in the foreword, there is a lot of confirmation bias on the findings.

But what that book was of most interest to me, is that there was a proper multi-year study behind it, which is something we tend to lack in our field.

Statistics

I am in no position to talk about statistics, nor the specifics methodology used to reach their conclusions. But I know that they have done their research, that the methods used are standard (for example, YouGov uses also the Likert scale), and, most importantly, with their information and techniques published, other people can try to replicate (or disprove) their findings (an absolutely important part of science).

It is that last fact that gives me the most confidence about their results (other than all three having a storied career).

The findings

Now we go to the parts that I can talk about. As I mentioned before, there is some confirmation bias in here. Most, if not all, the recommendations that they give are things that I have found in the past to be useful and to be proven on my personal experience.

We have the most basic finding: speed and stability are not a trade-off of each other. That it is, increasing speed doesn’t mean decreasing stability, increasing stability doesn’t mean decreasing speed. In fact using good processes and tools, both things can go hand in hand.

The four metrics

Less start with the caveat, all metrics can be gamed. So whenever you introduce a new one, you need to monitor constantly its use, to make sure that is giving you the information and benefits you expect.

Having said that, the four metrics that they introduce are quite interesting. First, because they are very easy to calculate. Second, because they, in part cover each other: If you deploy multiple times, but yet you deploy nothing, the measure is not useful. But if you are decreasing at the same time the lead time for something to be deployed live … now you have two metrics that work with each other.

The four metrics are easy beacons to rally around; I consider them the home point, a focal point, from where you want to go exploring techniques, tooling and ideas and come back and see if those explorations improve the metrics or not (and why, why is always important).

The Westrum model

I have talked about before how impressed I was with the Teal organizational model. Part of the model is that it requires to have what Ron Westrum calls a Generative culture.

I am not surprised that they talk about it here. Without it, you can achieve things, but are completely dependant in who is at the top of the company. While in a generative culture, more people can help and improve the system, making the loss or change of any person less problematic.

Limitations

They talk about several limitations, or common traps. For me, the most important, is that you can’t overcome the people at the top. If they are aligned with the whole idea, then things can happen. If they are not, doesn’t matter what you do, any improvement will become a battle, and any gains will quickly disappear.

I like as well the fact that they mention that there is no one-size-fits-all. The exact implementation of ideas is quite dependent on the teams involved, and their position along the journey. Nowadays I consider the retrospective the only important meeting, as from there, a team will be able to explore, change and adapt as they need.

The Core

One nugget in the middle of the book: the core of your software should be in-house. At some point I should write a blog post with a couple of cases that irk me a tiny bit. But this is so important. Whatever is the core of your business, if software manages it, then you want the people creating and maintaining that software to be part of your company. You need to be in control. Otherwise, you end in situations where the necessary knowledge about the system to fix or improve something is gone.

Complexity

Another small nugget in the book is the idea that teams and development form a complex system. Which has consequence like, for example, usually there is not a single person to blame, but that there has been a system failure.

Is the third time in the last month or so that I seen the idea of complicated vs complex, which is what underpins the Safety I vs Safety II of Erik Hollnagel.

The appraisal

This is a great book, is clear in what they set to achieve, how they went about it, and the specifics findings they had. It gives you myriad of ideas and pointers for you to investigate and then implement. It provides a way forward for any (software) company that wants to improve and become better.

The prose is easy to follow, the explanations of what they are doing are simple, when a new concept is introduced it gets explain (for example, identity). Seems to me that a lot of effort has been made to make this reading a pleasant experience.

I understand why a company like Armakuni has it as a book that they want all their people to read. And if you are in software development this is a must have/read book.