This question has been following me around since 2024.

Not in the abstract, theoretical way that questions tend to follow consultants around. In the uncomfortable, sits-across-the-table-from-you way. Executives who have spent years and significant money on Agile transformations are now looking me in the eye and asking, with varying degrees of exhaustion and frustration:

I understand why they are asking. The pandemic years (2020–2023) triggered a surge of Agile investment across industries. Consultants were hired. DevOps pipelines were rebuilt. Employees were trained and certified. Org structures were redesigned with squad models and tribes and guilds borrowed from companies they admired. And now, a few years on, many of these executives are sitting with a gnawing feeling that something is not quite right. They just cannot articulate what.

I want to try to help articulate it.

Let me start with an analogy that I find myself coming back to constantly.

Imagine you are an Olympic sprinter. You have been training for months. How do you know you are getting faster? You measure your speed. Obsessively. You track your times, compare splits, analyse your form on video. You do not just assume you are faster because you bought better running shoes.

And yet, this is exactly what most companies do after an Agile transformation. They point to cosmetic indicators and call them evidence.

The team is using Jira. The team holds a Daily Scrum over Zoom. The organisation has adopted the Spotify model with squads and tribes. Most employees have an Agile certification framed on their desk or listed on their LinkedIn profile.

None of these things tell you whether your company is agile. Not even close. A sprinter does not get faster by wearing the most expensive shoes. A company does not become agile by adopting the vocabulary of agility.

And there is something even more important I want to say about speed, because I think this is where the misunderstanding runs deepest.

Many companies believe agile is primarily about being fast. About shipping faster, releasing faster, moving faster. But moving faster in the wrong direction is not progress. It is just a more efficient way of going somewhere you did not want to go.

Agility must always be tied to increasing business value. Speed without value is just expensive urgency.

Here is something I have never been able to shake, even early in my career.

The traditional measure of project success is the project triangle: delivered on time, on scope, on budget. And I understand why it appealed to people. It is clean. It is measurable. It gives you three boxes to tick.

But I have watched organisations complete projects that hit every corner of that triangle and still fail their customers. And I have seen projects that missed every deadline and budget line and changed the world.

A product delivered on time might already be irrelevant when it arrives, because the market shifted while the team was heads down building it. Features delivered on scope might be features nobody actually needs, because the scope was defined six months ago by people who have not spoken to a customer since. A product delivered on budget does not automatically generate ROI, because budget adherence and customer value have almost nothing to do with each other.

Let me tell you about a holiday that taught me this more viscerally than any framework ever could.

In 2019, my wife and I went to Venice. We had planned that trip meticulously, six months in advance. Day by day, hour by hour. I was proud of that itinerary. It was a beautiful itinerary.

Then it rained. Three days straight. Relentless, grey, Venetian rain that had no interest in our plans.

Every outdoor activity we had planned was gone. All that careful preparation, sitting in the hotel room, useless.

We had a choice: grieve the itinerary, or adapt. We adapted. And on one of those rainy afternoons, completely unplanned, we found ourselves at a Vivaldi concert in the very building where he once worked. I did not know that was going to be the moment I remember most from that trip. But it was.

Agility is not about abandoning planning. It is about knowing when the plan needs to change, and having the courage to change it in pursuit of something more valuable than the original idea. That is what the project triangle completely misses. It rewards adherence to the plan. Agility rewards adaptation to what actually matters.

This is the question I get asked most often in workshops, and I am glad people ask it, because it means they are genuinely trying to measure the right things rather than just the familiar ones.

My answer is the Evidence-Based Management (EBM) framework from Scrum.org.

EBM gives us four Key Value Areas (KVAs) to measure. I want to explain them the way I explain them in workshops, because I think abstraction is the enemy of understanding.

Think of your organisation as a car on a road trip.

Current Value is where you are right now on the map. The blue dot on Google Maps. What value is your product currently delivering? Metrics like revenue per employee, customer satisfaction, product cost ratio, and customer usage index help you answer this. They tell you whether the thing you built is actually being used and whether it is worth something to the people using it.

Unrealised Value is the destination on the map. The red pin. Where could you be? What growth and opportunity exists that you have not yet captured? Market share, ROI potential, desired customer experience. This is the gap between where you are and where you could be if you kept improving.

Time to Market is the speedometer. How fast are you moving? Lead time, deployment frequency, mean time to value. These are the DORA metrics many engineering teams will recognise. Speed matters, but only in context of the other three.

Ability to Innovate is the engine condition. And this is the one most companies ignore, to their significant cost.

Let me tell you another story, because this one matters deeply to me.

A week before a long road trip from Brisbane to Sydney, my car broke down. Not a small problem. Major engine trouble. A gearbox that was failing. Wheel bearings that were going. Brakes that were worn. My mechanic looked at me with an expression that I can only describe as professional disappointment.

I still wanted to make that trip. I still wanted to drive fast on the highway and arrive on time. But driving a car in that condition at speed would have been reckless. Dangerous to my family. Even if I pushed it, the car would not have gone fast. And when I needed to brake suddenly, the consequences could have been catastrophic.

So I fixed the car first. Only then did I drive.

This is Ability to Innovate. And the number of organisations I encounter that are trying to drive fast in a broken car is, frankly, heartbreaking.

Teams are spread across multiple products simultaneously, unable to give proper attention to any of them. Technical debt has been accumulating for years, unaddressed, because there was always a new feature that felt more urgent. The Definition of Done gets quietly compromised, Sprint after Sprint, until it means nothing. Incidents keep interrupting delivery because the underlying system is fragile. Engineers are context-switching so often that deep work has become almost impossible.

And leadership is still pushing for faster Time to Market. More features. Shorter cycles. Higher velocity.

I understand the pressure. I feel it myself in this industry. But you cannot drive fast in a broken car. And you cannot achieve sustainable agility while ignoring the fundamental conditions that make agility possible.

Ability to Innovate is a shared accountability between the Scrum Master and the developers. It is not glamorous work. It does not produce features. It does not show up in a product demo. But without it, everything else eventually grinds to a halt.

One of the things I love about the EBM framework is that it maps directly to the accountabilities in Scrum, and it does so in a way that makes those accountabilities feel real rather than theoretical.

Current Value and Unrealised Value, the business value dimensions, map to the Product Owner. The Scrum Guide is direct about this: the Product Owner is accountable for maximising the value of the product. If the product is fast and high quality but the value is not increasing, that is a Product Owner conversation. It might mean the market analysis was off. It might mean strategic prioritisation needs to change.

Time to Market and Ability to Innovate, the delivery capability dimensions, map to the Scrum Master and developers. If delivery is slow, we look at Ability to Innovate first. If quality is being compromised for speed, that is a developer accountability. If the system conditions are preventing the team from doing their best work, that is a Scrum Master conversation.

None of these accountabilities work in silos. The entire Scrum Team is accountable for creating a valuable increment every Sprint. These distinctions exist not to create blame, but to create clarity. Because without clarity about accountability, everything becomes everyone's problem, which is another way of saying nothing is anyone's responsibility.

This is something I say in almost every workshop I facilitate, and I mean it in the most literal sense.

The EBM framework is not a certification you achieve. It is not a maturity level you reach and then sustain. Agility is a company's continuous capacity to increase value over time. Which means the question is never "are we agile?" It is always "are we more agile than we were yesterday?"

That framing shifts something important. It removes the pressure of achieving a fixed state and replaces it with the far more honest and far more achievable aspiration of continuous improvement. We can always be more agile than we were. That is not a criticism. It is an invitation.

I want to close with something direct, because I think some leaders need to hear it plainly.

If your organisation is not measuring its agility using meaningful metrics tied to actual business value, you are not making informed decisions. You are making assumptions. And assumptions are dangerous. As dangerous as driving a car at highway speed without a speedometer, without knowing if the engine is about to give out, without any sense of whether you are getting closer to your destination or further away.

Start measuring. Not because measurement is the point. The point is value, and the people you are trying to serve. But measurement is how you know whether you are actually moving toward them, or just moving.

And if your organisation would like to work through this together in an Evidence-Based Management workshop, reach out. I would love to be in the room for that conversation.