Rebooting Accelerate, part 1: Looking beyond the hype

Whenever I hear “Accelerate IT” these days, it often gives me a buzzword vibe that sounds like a law of nature: Companies need to accelerate their IT by implementing DevOps principles and move to the cloud, or they will be outperformed by their competitors and then fail.
My problem with this very simple narrative is that it sounds like a wild oversimplification of the key takeaways of the 2018 book “Accelerate” [1] . Acceleration is a lot more than DevOps and cloud principles. In fact, I’d argue that the very meaning of acceleration will vary depending on the market or a company’s business model. Let’s take a step back and look beyond the hype: What are we actually trying to accelerate, and why?

This is part 1 of a two-part article series on accelerating IT. It makes an attempt to look beyond the “Accelerate” buzzword and its “faster = better” narrative by identifying common principles and motivations behind acceleration in the context of different business environments.

Part 2 looks closer at the challenge of delivering value faster. What skills and capabilities do we as tech people need to drive acceleration? To answer this question, I’ll come up with a holistic perspective that includes both technical, organisational, and cultural competencies.

TL;DR

Short on time? Here’s an ultra-short abstract of part 1:

• Although the buzzword and popular literature in the field might suggest otherwise, accelerating IT is a fairly broad term that addresses an entire organisation. Even more so, acceleration happens for different reasons, depending on the economy sector and an organisation’s business model.
• Moving away from IT, we can find examples where acceleration is beneficial for businesses in the fashion industry, academic research, and even the public administration sector, despite very different organisational goals.
• A common denominator that serves as a motivation for acceleration is the desire to shorten learning cycles in environments with high uncertainty or constant change with the goal of delivering value faster.

Accelerate: How it started…

Reading the first edition of “Accelerate” [1] a while back was a joyful experience for me. Through meticulous research, a team of very smart people proved that certain capabilities drive performance in tech-driven businesses. The authors carved out a broad spectrum of qualifications which include the classic DevOps skills, but also span across product development, management, and cultural capabilities. This resonated with me because it helped to put into words what me and many of my peers often observe in our projects: The delivery performance an organisation can achieve is determined by a complex set of factors. Technological expertise is an important cornerstone, but it doesn’t end here. There’s a lot more to it, and we should be aware of the other dimensions and address them as good as we can.

…and how it’s going

Fast forward to 2022: The term “Accelerate” pops up an awful lot in discussions, articles (and sometimes arguments), however it seems as if it has lost its broad meaning. It feels like it is all too often used as a buzzword to justify chasing after the latest DevOps trends:

Hey, you should deploy to production 20 times a day because that’s how you accelerate if you want to keep up with the competition!

When did “Accelerate” become such a narrow term? I have a feeling that the annual State of DevOps report [2] might play a role in this (don’t get me wrong, I’m a fan!). It allows us to compare our software delivery performance to thousands of other survey participants. Performance in the report is boiled down to the famous 4 DORA metrics. In addition to that, the report makes a few general statements saying that businesses in ever-changing markets need to be able to adapt quickly, and that implementing DevOps practices helps achieve that.
Besides this very technical perspective on acceleration, the report’s conclusions are based on a biased sample, too. The companies that took part in the survey are predominantly from the tech and banking sector, many of them with 10.000 or more employees. The report’s findings seem reasonable as companies like Google or Amazon are excellent examples for highly successful tech companies that are known for their excellence in software delivery. However, I guess that their success stands on a broader foundation than having optimised their business for excellent DORA metrics. Furthermore I’m not convinced that Google’s or Amazon’s company mindset is right for everyone. How does it look for companies from other industries, or for smaller businesses?

My question is: Can we find a way to return to a broader definition of “Accelerate” that fits tech as well as non-tech businesses and environments?

If so: How does acceleration look like depending on context and environment?
For answering this question, I took a step back and tried to look at businesses that differ a lot from our typical DevOps report survey participant.

Starting from scratch: Rebooting Accelerate

Let’s try to bring Accelerate back to its broader definition by looking at a few non-tech examples.

Fast and ultra-fast fashion

In the past decade, the fashion retailer Zara outperformed its rivals in terms of sales growth and profit by implementing a “fast fashion” business model . Fast fashion aims to bring current and upcoming fashion trends to stores with very short lead times of four to six weeks. This is achieved as follows:

• Products are designed in direct response to market signals, such as what sells well at stores or trade shows
• New designs are created decentrally by hundreds of designers and finalized only immediately before production, including the latest information on market trends
• Production is performed by direct manufacturing contractors located in Europe which allows for quick changes to production and delivery to stores

Despite its success over the past few years, Zara and others who have employed the fast fashion business model are under pressure by smaller companies that implemented an “ultra-fast fashion” business model, further reducing product development times significantly. Companies such as ASOS and Fashion Nova achieve this by reacting to data gathered from social media platforms and instant feedback from its users through their apps, producing small batches locally, and forgoing operating physical stores.
Fast and ultra-fast fashion retailers act quite differently according to a recent study published in the International Journal of Retail and Distribution Management [3] :

What’s interesting when comparing the two business models is that they optimize for different goals: Fast fashion retailers seek to produce at the cheapest possible price. They achieve this through mass-production in large batches. Ultra-fast fashion retailers optimize towards the shortest possible product development cycle at the cost of efficiency (and thus, higher prices). They achieve this through reduced batch sizes and a strong focus on quick learning by sourcing information from their online apps. Let’s look at both business strategies in some greater detail.

Economies of Scale vs. Economies of Speed

Economies of scale (here: our fast fashion retailers) generally prefer efficiency over other factors. The general idea is to use machines and material as efficiently as possible, avoiding downtimes and production line adjustments. This can be achieved by producing items in large batches. Producing 10,000 identical items is usually cheaper than producing 10 different batches of 1,000 items. While this helps with cutting costs and idle times, it also reduces the ability to make quick adjustments (e.g. working in customer feedback or reacting to the latest market developments, as observed by Gregor Hohpe in [4] , chapter 35). Economies of speed favor quick learning and reducing product development cycles over maximum efficiency. This is essentially achieved by reducing batch sizes, allowing for easier adjustments.
Leaving the question aside whether the employment of fast and ultra-fast fashion is healthy in terms of ecological and socioeconomic impact, the fashion industry gives us a good idea of “acceleration”:

Given a market with fast-changing requirements (e.g. fashion trends), a company can generate an advantage over its competitors by reducing its product development lead time.

The fashion industry demonstrates that reducing lead times and shortening innovation cycles can translate into an advantage in the market over competitors.

No-consumer environments

Looking at the fashion industry, we have found an environment where we can observe (and somewhat define) acceleration. However, how does this narrative hold up against a completely different environment? How does it look in sectors without market pressure or product focus? Let’s take two examples from academic research and the public administration sector to get a feeling for the meaning of acceleration in these areas.

Academic Research

Quite different from the fashion industry, the research sector is largely independent from the private economy. Revenue doesn’t depend on business output, and there are no products to be delivered to customers. Nonetheless, there are fields of research where we can identify conditions that sound similar to what we can observe in markets with fast-changing requirements.
Researchers operate in environments with high uncertainty and limited funding. Here, according to [5] , software-assisted research work can be seen as a continuous cycle that consists of research, software development, and software operation. In this environment, accelerating research by reducing the time required to complete a learning cycle is considered beneficial for a number of reasons:

• Quick learning allows for fast course corrections: When developing mathematical models or creating a simulator for conducting geological research, there are usually no clear upfront requirements on what needs to be built. The models and simulations are therefore generated based on initial assumptions which are refined over time. The quicker new knowledge can be integrated into these models, the more effectively (and faster) refined models can be generated.
• Fast course corrections allow for an efficient budget use: In case of multi-year research projects, the available budget is limited, although it usually isn’t known beforehands which research goals are achievable. Having quick feedback on conducted experiments allows for effective selection of feasible goals that fit the budget and is therefore considered beneficial for overall project success.

Acceleration in this context could therefore be defined as “reducing the time to complete learning cycles”, and reducing the time to complete a cycle can be seen as beneficial for efficient budget use and research project success.

Public Administration

Quite similar to the research sector, the public sector doesn’t rely on investors’ money or sales revenue. However, according to works published by/for the German public administration sector ([6] and [7] ), public authorities in Germany face a number of challenges that sound similar to our previous findings in the research sector: Reacting to change in complex environments in a timely manner.

In the case of government agencies, this means reacting quickly and effectively to current developments. Two examples are the implementation of government stimulus programs due to the COVID-19 pandemic or the introduction of the 9-Euro public transport ticket to counteract the rapidly increasing cost of energy. Government departments translate the current government’s political agenda as well as responses to current developments into legislation. Implementing these is a downstream process that is often considered slow and too sluggish to effectively react to changes. This became especially apparent during the COVID pandemic, when lawmakers faced ever-changing, hard-to-predict situations that required rapid adjustments to both existing legislations as well as their downstream implementation. Government agencies have therefore increased their efforts to reduce the time required to react to changes. This development is primarily driven by the feeling that citizens and voters expect a state apparatus that is able to adapt and respond to change in a timely manner, and requires public authorities to learn and adapt skills to facilitate change better and more quickly.

Acceleration in this context can be defined as “reducing the time required to implement legislative change”. As this change is constant, this can also be seen as a continuous effort. Its main driver is the expectations of voters and the general public to have a capable state apparatus that meets their needs.

Finding a common denominator

For each of the examples we looked at, acceleration means different things and happens for different reasons. Although the observations from the fashion industry don’t necessarily translate into the research or public administration sector, we can observe that within all of these environments, the speed of implementing or reacting to change is seen as an important indicator towards reaching the desired goal. The following table makes an attempt to compare the three areas:

Conclusion

Looking at the different sectors, we can conclude that while the meaning of acceleration and the motivation for it is different according to context, we see a desire to shorten learning cycles in environments with high uncertainty or constant change. Although all of the examples were taken from vastly different environments with different rules and goals, we can identify that they have something in common: There is an artifact of value (a product, a feasible research goal, an enacted law brought into effect) that should be created as quickly as possible. As one could also put it: There is a general desire to deliver value faster.
With a better understanding about the “what” and “why” of acceleration I’d like to shed some light on the “how” in part 2 of this article series . What allows us to shorten learning cycles in environments of change? And what can we, as tech people, do about it?

I hope that you found this article useful. Thanks for reading!

References

• [1] Forsgren, Humble, Kim: Accelerate
• [2] DevOps Research and Assessment: Accelerate State of DevOps Report 2021
• [3] Camargo, Farias Pereira, Santiago Scarpin: Fast and ultra-fast fashion supply chain management: an exploratory research
• [4] Hohpe: The Software Architect Elevator
• [5] De Bayser, Azevedo, Cerqueira: ResearchOps: The case for DevOps in scientific applications
• [6] Gottschick, Holzmann-Kaiser, Kurrek: Cloud-Betrieb im öffentlichen Sektor: Selbstbedienung, automatisiert.
• [7] Bundesverwaltungsamt: Von DevOps zu LawOps: Qualität und Wirkung rechtlicher Regelwerke im Zeitalter der Digitalisierung