The Four A’s: A Framework for Progressive Delivery

The following is an excerpt from the forthcoming book Progressive Delivery: Build the Right Thing for the Right People at the Right Time by James Governer, Kimberly Harrison, Heidi Waterhouse, and Adam Zimman.

The evolution of Progressive Delivery has been shaped by technological advances, much as physics has evolved to measure and manage forces of motion. Just as physicists use measurements of jerk to understand sudden changes in acceleration, there are four essential factors that help us measure and manage the technological jerks in our system: the four A’s—abundance, autonomy, alignment, and automation. The rise of virtualization, containerization, and cloud computing led to the abundance of computing and storage resources. This abundance of resources led to increased developer autonomy, which was further accelerated by Git, distributed contribution, feature flags, and the architecture trend from monoliths toward microservices.

As autonomy increased, so did the need for focus and alignment. Teams began to prioritize—and value—API-first development and enhanced observability. This more loosely coupled architecture led to both the opportunity and the need for more automation and better feedback loops to manage the vast increase in the scale of systems and the opportunity to better understand user behavior and needs.

We can express this relationship as an equation:

Progressive Delivery = (Abundance ^x Autonomy) / (Alignment ^x Automation).

Abundance and autonomy form the foundation of the developer experience, much like the electrical grid supports our modern life. The fluctuations of power generation and conduction are smoothed out, and we get steady, reliable resources to use. We then get to choose how to apply the power streaming into our homes and businesses so abundantly. In the same way, abundance and autonomy in software development allow us to think about more difficult and interesting problems. However, just as we use everything from circuit breakers to dimmer switches to control the flow of power, the forces of abundance and autonomy also need to be well-regulated to be useful and safe.

Your “goal” for Progressive Delivery is to balance your abundance and autonomy by leveraging alignment and automation. If abundance and autonomy are too pronounced compared to alignment and automation, teams tend to build brittle systems filled with features that never get used. Conversely, if you focus too much on the user experience without addressing developer needs, you end up knowing what the users need, but you are unable to deliver it fast enough.

In this way, abundance and autonomy are all about the developer experience, or the building side of a product, while alignment and automation are centered on the user experience, or the delivery of the product. We could simplify this as:

Progressive Delivery = Developer Experience / User Autonomy.

If abundance and autonomy are the electrical grid, delivering us power and potential, alignment and automation are the appliances that transform the energy into value. Voltage on a power line is not useful until we can convert it into light, heat, work, or video gaming minutes. Too much power and there’s a risk to safety and property. Too little and we can’t turn on a light or keep food cold. Alignment is what directs the current the way we want it. Automation makes our homes run without intervention and keeps us safe from mistakes or sudden surges. Without alignment and automation, we would be at risk of surprises or unwanted changes. 

Let’s examine each of these four pillars in detail:

Abundance

Abundance is a very large quantity of all the resources required to accomplish a task. In the context of Progressive Delivery, this centers around the developer experience. When building digital systems, this can be divided into compute resources, network bandwidth, and storage.

We can measure abundance both quantitatively (e.g., how long it takes to provision a server or database for a new project) and qualitatively (e.g., through developer surveys and interviews). Developer experience and abundance are interlinked. Abundance enables developers to work without friction, without waiting for permission to access resources.

Autonomy

Autonomy is the ability of an individual to act independently from others. When developing software, this independence means access to all necessary resources to complete a desired task. In order to have a Progressive Delivery environment, developers need to be able to innovate and build at their own pace.

To measure autonomy quantitatively, we can track how frequently developers are “blocked” or waiting for others to do their work. During some stages of growth or product expansion, the rate of blocking may naturally rise. We can also gain qualitative assessment through internal surveys.

Alignment

Alignment means focusing human and organizational resources responsible for developing software to all work in the same direction. In Progressive Delivery, alignment is one of the two ways to wrangle abundance and autonomy. Both alignment and automation are centered around the user experience.

We can measure alignment through qualitative user surveys and interviews, as well as by monitoring usage rates and patterns in feature adoption and workflow completion. The exact method for gathering quantitative and qualitative data about user impact will vary with the software and the users, but it should be as broad as the team can afford to capture multiple insights.

Automation

Automation is the identification and implementation of programmatic processes for repetitive tasks. For Progressive Delivery, automation is the second way to focus on abundance and autonomy. Automation adds constraints by intentionally looking for repetitive manual tasks and creating code to reduce effort while ensuring consistency. After all, one of the goals of computing, and now AI, is to make automation easier and more effective. Adoption is easier when it’s automated and part of the workflow.

Measuring automation can be done through observability tooling, which looks at the frequency of pattern repetition as users navigate a workflow. Indirectly, user surveys can target questions about repetition and “too many steps” to accomplish frequent tasks.

Each of the four A’s of Progressive Delivery reinforces and enables progress in the others. None of them is something that can be fully finished. Moore’s Law continues to provide an abundance of resources. You can always automate a little more, or a realignment will reveal a way for a team to become more autonomous. Even autonomy continues to increase and expand in the face of coding assistants.

Change is a part of our lives every day. We tend to think of it as good change, like increases in capacity or learning, or bad change, like aging and decay. Change is stressful because it forces us to learn new habits and patterns and ways of doing things. The larger and faster a change is from a single point of view, the harder it is to adapt to it. Jared Spool, cofounder of Center Centre, said in the article “The Quiet Death of the Major Re-Launch,”

There’s another way to build a new architecture with a whole new site without the risks of a re-launch.…I explained that re-launches are a thing of the past. There was a time when sites launched in cycles, living from one major redesign to the next. Each new redesign would bring a whole new look, a whole new user experience.…However, the best sites have replaced this process of revolution with a new process of subtle evolution. Entire redesigns have quietly faded away with continuous improvements taking their place.

The way we build software has evolved to make it trivial to push changes to our users. But just because it’s easy to change things doesn’t always mean it’s the right time or situation to do so. This is where Progressive Delivery shines—by providing a framework that balances capability with responsibility, speed with sustainability.

In physics, understanding jerk helps engineers design better systems—from elevator controls to autonomous vehicles. Similarly, understanding the forces of technological change through Progressive Delivery helps us build better software systems that respect both the need for rapid innovation and users’ capacity to adapt to change. Modern software delivery works because we have an abundance of software and network resources, the autonomy to find the best path to solve a problem, the alignment to work within a distributed system, and the automation to preserve our energy for novel and challenging tasks. Through Progressive Delivery, we can ensure that this malleability serves both the creators and consumers of technology, making change not just possible but purposeful.

- About The Authors

James Governor

James Governor is the cofounder of RedMonk, the only developer-focused industry analyst firm. Based in London, he advises clients on practitioner-led technology adoption and engineering, open source, community and technology strategy. Governor is credited as having coined the term “progressive delivery.” Vermouth advocate. He lives in London.

Follow James on Social Media

• 

Kim Harrison

Kim Harrison is a sociologist focused on the development and adoption of new technology within the software industry. She enjoys working with early-stage startups that are developing new tools and methodologies for modern development teams. She specializes in strategic communications and community building. She lives in the San Francisco Bay area.

Follow Kim on Social Media

• 

Heidi Waterhouse

Heidi Waterhouse spent a couple of decades as a technical writer at Microsoft, Dell Software, LaunchDarkly, and many, many startups, learning to communicate with and for developers. She coauthored Docs for Developers: An Engineer’s Field Guide to Technical Writing. She is passionate about storytelling, finding business value, and the ROI of laptop stickers. When she’s not helping craft startup messaging, you can find her in her sewing room listening to a book. She lives in Minneapolis, Minnesota.

Follow Heidi on Social Media

• 

Adam Zimman

Adam Zimman is a VC advisor providing guidance on leadership, platform architecture, product marketing, and GTM strategy. He has over twenty years of experience working in a variety of roles from software engineering to technical sales. He has worked in both enterprise and consumer companies such as VMware, EMC, GitHub, and LaunchDarkly. Zimman is driven by a passion for inclusive leadership and solving problems with technology. His perspective has been shaped by a degree (AB) from Bowdoin College with a dual-focus in physics and visual art, an ongoing adventure as a husband and father, and a childhood career as a fire juggler.

Follow Adam on Social Media

• 
•