Deliver What Matters · LinkedIn

Learning Velocity Matters More Than Delivery Velocity

For years, we’ve worked to help government technology teams deliver faster. We have shorter release cycles, smaller batches, less work in progress, and faster feedback.

I spent a good portion of my career helping teams make this happen. But I came to believe we’re optimizing the wrong velocity.

The more important question isn’t how quickly can we deliver? It’s how quickly can we learn?

Those sound similar, but they lead organizations to behave very differently.

Fast Delivery Can Still Take You in the Wrong Direction

A team can become incredibly efficient at moving work through a delivery system. Requirements arrive, the backlog gets refined, developers build, testers test, and functionality reaches production with impressive predictability. That’s good execution.

But if the team immediately moves to the next requirement, what did the organization actually learn?

Maybe users loved what was delivered. Maybe they ignored it. Maybe it solved the problem. Maybe it created another one. Maybe the underlying assumption was wrong from the beginning.

A fast delivery cycle doesn’t answer any of those questions. It only gets us to the point where we can answer them. That’s an important distinction.

Delivery Creates the Opportunity to Learn

This is why I don’t think we should dismiss delivery measures. Lead time matters. Cycle time matters. Throughput can matter. These measures help teams understand whether work is flowing effectively and predictably.

My own guidance on product development metrics treats those measures as useful indicators of delivery performance, while distinguishing them from outcome measures that tell us whether the work actually produced meaningful impact.

The mistake is making faster delivery the destination .

Think about why we wanted shorter delivery cycles in Agile in the first place.

It wasn’t so we could close more tickets. It was so we could put something useful in front of people sooner, see what happened, and adjust.

Delivery speed matters because it can shorten the time between idea and evidence . That’s learning velocity.

How Long Does It Take You to Find Out?

Imagine two teams.

Team A releases ten significant capabilities in six months. The releases are on schedule, stakeholders are pleased, and the roadmap is steadily moving to the left.

Team B releases six in the same timeframe. If all we measure is delivery, Team A looks more successful.

But suppose Team B has a different rhythm. Before each meaningful change, the team identifies the problem, establishes the current condition, defines what it expects to improve, and captures the assumptions behind its proposed solution. After release, it looks at what actually happened and uses that evidence to decide what comes next.

Meanwhile, Team A is already working on capability eleven.

Which organization knows more about whether its investments are working? That’s the question I care about.

The Learning Cycle Is Bigger Than the Delivery Cycle

This is where I think many Agile implementations have lost the plot. We’ve become very good at measuring the time between “started” and “done.” We build dashboards around flow, track sprint performance, automate deployment pipelines, and celebrate increased release frequency.

But the learning cycle doesn’t end at deployment .

It looks more like this: Understand → Assume → Deliver → Observe → Learn → Adjust

If we measure only the middle of that cycle, we’re optimizing only part of the system.

A team that deploys every day but waits six months to understand whether anything improved doesn’t have a fast learning cycle. It has a fast deployment pipeline. Those aren’t the same thing.

What Would You Optimize Differently?

Once you start thinking in terms of learning velocity, some familiar practices take on a different purpose.

Smaller releases aren’t valuable simply because they’re smaller. They’re valuable because they can help us test assumptions sooner.

User research isn’t something that happens before development. It continues because we’re constantly trying to understand what changed.

Metrics aren’t primarily there to produce status reports. They’re there to help us make better decisions.

And the before-and-after stories I’ve written about recently aren’t documentation exercises. They’re forcing functions that make the learning cycle explicit.

Before we act, what do we believe will happen? After we act, what actually happened? Then, what did we learn? That’s the rhythm.

Measure How Fast You Learn

Government will always care about delivery. It should. We have commitments to meet, systems to maintain, policies to implement, and people depending on the services we provide. Improving delivery effectiveness remains important.

But faster delivery of an unvalidated assumption isn’t necessarily progress. Sometimes it’s just a faster way to be wrong .

A Product-Led organization tries to shorten the distance between an idea and the evidence needed to make the next good decision. That’s why learning velocity sits alongside outcomes over outputs and assumptions over requirements in the Product-Led mindset I’ve advocated.

So keep improving delivery. Just remember what faster delivery is supposed to enable.

The goal isn’t to get more things through the system. It’s to learn fast enough to keep making the system better.

How long does it take your team to know whether something you delivered actually worked?

Reply or comment—I read every one.

Read at the original source