I always use to say: “Software currently rules the world.” Almost every aspect in our (digital) life has to do with software: The apps you use on your smartphone, the mail/hosting services you rely on, online shopping, train tickets, in general everything that somehow adds value to your life. Competition among organizations is driven by speed, the ability to deliver new features to the customers, stable products, security within their eco-systems and many other aspects. And what do they have in common? If you ask me: Software.

Key takeaways

Introduction

Usually I don’t do book reviews. I just tend to collect my notes and thoughts in my Zettelkasten. But this time I wanted to share some insights, write them down and convince you why you should read this book. Accelerate is not about software engineering nor entirely about DevOps. It does have something to do with the Agile manifesto but from a more data-driven, scientific point of view. To be more precise, the authors analyzed over many years factors that enabled teams to deliver software (features) in short cycles while still limiting technical debt and having a stable and secure deployment process.

Big picture

If you want to skip the details, just have a look at this diagram and try to understand how software delivery is impacted by different areas.

image
Accelerate Big Picture

Speed

Why is speed so important? Because it does make a difference how fast you can “conquer” a market and deliver value to your customers. Or as the authors put it:

Business as usual is no longer enough to remain competitive. Organizations in all industries, from finance and banking to retail, telecommunications, and even government, are turning away from delivering new products and services using big projects with long lead times. Instead, they are using small teams that work in short cycles and measure feedback from users to build products and services that delight their customers and rapidly deliver value to their organizations. These high performers are working incessantly to get better at what they do, letting no obstacles stand in their path, even in the face of high levels of risk and uncertainty about how they may achieve their goals.

At the heart of this acceleration is software.

– Accelerate

Software delivery performance

Research presented in the book has found 24 key capababilities that seem to drive software development performance. If you are a high-performer or a low-performer merely depends on the capabilities you, your team and your organization focus on. The authors have defined 5 categories for these capabilities:

Before we go into deep discussion, let me try to summarize why capabilities matter more than maturity.

Capabilities vs Maturity

Lots of mature organizations think they own a quite big piece of cake when it comes to market share. While relying on that, they tend to become less innovative, have complicated internal processes (slows down the overall development process), lose talented high-performers (who wants to work in a slow, process-heavy environment?). Instead they should focus on certain capabilities in order to drive continuously improvement.

Once organizations arrive at a mature state, they see their journey as accomplished and declare themselves done. However, this way they don’t adapt to technological changes and those within the business landscape. High-performing organizations are always striving to be better and never consider themselves as done or mature.

Technology leaders need to deliver software quickly and reliably to win in the market. For many companies, this requires significant changes to the way we deliver software. The key to successful change is measuring and understanding the right things with a focus on capabilities—not on maturity.

– Accelerate

Mature organizations not only have a bad time to keep up with new technologies but they also prescribe the same set of technologies for every set of teams in order to progress. The better approach would be to take into consideration current context, used systems, goals and constraints and focus on the capabilities that will give the teams the most benefit. This way different parts of the organization are allowed to take a customized approach to improvement.

Maturity models also tend to define a static level of technological, procedural and organizational abilities to be achieved. What is good enough and high-performing today, might no longer be good enough next year.

Measuring performance

Most organizations focus on “old-school” technical measures like lines of code, velocity which measure some performance locally (in general within a limited scope) rather than on a more global one. Developers (and DevSecOps folks as well) are supposed to solve business problems and therefore focus on a global outcome and not output. It doesn’t matter how many lines of code your team has, how often you deploy, how many Security tools you have implemented within your CI/CD pipeline. If it doesn’t help to achieve organizational goals, then you’re focussing more on the output rather than outcome.

Software Delivery Performance

Since it should be clear by now that the faster you are able to deliver your software to your customers, the more you’re confident you’re doing the right things, the book defines 4 criterias for software delivery performance:

How fast is fast?

After presenting the criterias, let’s have a look at some raw numbers.

Table 1: Software Delivery Performance in 2017
2017 High Performers Medium Performers Low Performers
Deployment Frequency on demand (multiple times per day) Between once per week and once per month Between once per month and once every 6 months
Delivery Lead Time < 1 hour Between one week and one month Between one month and 6 months
MTTR < 1 hour < 1 day < 1 day
Change fail rate 0-15% 0-15% 31-45%

As you can see high-performers have a quite high deployment frequency and most important the delivery lead time is extremely fast.

How to accelerate

Now that you knwo the key metrics when it comes to software delivery performance how do you actually accelerate and start changing your organization? Of course you can

Let’s dissect each one piece by piece.

Change culture

In order to understand which changes are good for your organizations, sociologist Ron Westrum has defined a model on importance of organizational culture. Before he was researching on human factors in system saftey, especially in the context of accidents in technological domains that were highly complex and risky (aviation and healthcare). From his point of view organization culture is vital because it defines how information flows through an organization. He defines following types of organizations:

Orgnization types

In Westrum’s theory information flow within an organization has a huge impact on its performance:

Change technical practices

Among the software and tools you use within your team, there is one capability that seems to have a big impact on your overall performance: Continuous Delivery.

Continuous Delivery

Continuous Delivery is a set of capabilities to enable changes of all kinds (features, configuration changes, bug fixes, experiments) go into production “safely”, “quickly” and “suistanably”. There are some principles:

In order to implement CD following foundations should be created:

During their research the authors have identified following key drivers for continuous delivery:

Change architecture

As I’ve mentioned previously a loosely coupled architecture enabled high-performers to better build and maintain systems. No matter what kind of systems you are building there should be little communication required between delivery teams in order to get work done. Futhermore the architecture of your systems should enable teams to test, deploy and change systems without depending on other teams. Communication channels should not be ignored completely. However, they should be used for discussing high-level shared goals and how to achieve/implement them. Fine-grained decision-making on a technical level should only take place within the teams - unless you are required to discuss technical stuff with other members as well. Also important: Let the teams chose tools and technologies. (Good software) architects should focus on concepts, engineers and outcomes, not on technical discussion and concrete tools/technologies.

{{< notice info >}} Also check out my bookmarks and notes on architecture. I also recommend reading The Clean Architecture and The Clean Code. {{< /notice >}}

Change product management

If you’ve noticed already, the book title mentions The Science of Lean Software and DevOps. While most of you probably know what DevOps is about, what is Lean Software? The term itself (Lean) derives from Lean Management and used to be Toyota’s approach to car (manufacturing):

How can these methods be applied to software engineering? Well, let’s have a look at some characteristics:

Make people happy

While technical practices have an impact on the ability to deliver software quickly, they can also help to reduce stress and anxiety related to the fear of breaking something. When people are not confident that their changes will break anything in production, their productivity and motivation decline. In order to reduce deployment pain and reduce the risk of a burnout, the authors recommend to:

Have strong leadership

While leader != manager, leadership should be about inspiring and motivating people surrounding you. Even more: A transformational leadership should affects a team’s ability to:

These are the characterstics of a good transformational leader (Rafferty and Griffin 2004):

Conclusion

DevOps and Agile are already used by many organizations as part of their transformation strategy. They encourage a culture of transparency, shared responsability, faster feedback and automization. Accelerate is the scientific, data-driven approach to put all pieces together, to show you how they depend on each other and finally achieve a better organizational performance. And while software is at the heart of most modern companies it is essential to have a solid, stable and secure software delivery process.

For me this book was definitely one the most influencial ones I’ve read in the past years. You might also check out other books by Gene Kim (he is one of the authors) if you’re interested in DevOps, Agile transformation and successful user stories. Beside that I also recommend the Google SRE books.