Unpacking Agile Transformation: The System of Delivery

So if we agree that Agile Transformation is worth talking about, we need a better way of talking about it. A clear way to differentiate between what we are trying to build and what it takes to get there.

You see, over the past 20 years, the general hypothesis has been to train people on Agile methodologies and trust everything else will emerge. Teams will magically form. Dependencies will magically break. Culture will magically shift. The idea is that you teach folks how the process is supposed to work, and they will inspect and adapt and remove impediments along the way. I’ve seen in real life that the critical impediments, those which must be removed, often aren’t within the team’s purview that needs them changed. The net effect is that we bastardize the process to accommodate the disfunction.

Through our work at LeadingAgile, we’ve come to believe there are three core systems necessary to instantiate and sustain an Agile enterprise. A fourth system addresses how to structurally engage the organization, align the players, and enlist the support of the people in the organization. It’s only by understanding and deploying these three (four) critical systems that we get long-lasting, systematic change.

The first system we are dealing with in this post, we call the System of Delivery.

A System of Delivery is what we typically think about when we think about Agile methodologies. It’s the process and governance mechanisms we use to manage the flow of work through the system. Think about things like how we write user stories,  how we estimate work, how we run planning cadences, how we deal with technical concerns, and how we measure done.

At scale, it’s about how we coordinate multiple teams to deliver integrated deliverables, how we handle planning, what we do with dependencies, and how we release products to market, and on what cadence. We might go far enough up the organization and address how we handle strategy articulation, budgets, product funding, and compliance.

While processes and governance are necessary to manage the flow of value, it is an incomplete representation of the operating model.

Agile requires… to some extent… an organizational design that reduces dependencies, eliminates bottlenecks and focuses on throughput over utilization. A design that seeks responsiveness to markets over trying to predict an unknowable future. This has implications for how we form teams at the work surface, what we form them around, what structures and cadences do we use to feed them work, and who feeds them work on what interval.

We have to address who makes investment decisions and who resolves conflicts. Who gets to make decisions and when.

Finally, we have to decide what we measure and how. How do we assess organizational performance and throughput? How do we define, track, and report on our OKRs and KPIs? How do we really know if we are delivering against the most important things to our business?

All this stuff is System of Delivery. It’s really about having a clear understanding of what we want the organization to look like when we are done. It’s about clearly defining the enterprise’s operating model and how it will allow us to deliver with greater Business Agility. It’s about defining a reliable system that our organization can delegate into to achieve its goals. Once we understand where we are going, we can start to talk about how to get there.

This is where the System of Transformation comes in… and we’ll deal with that in my next post.