Skip to content

Beyond the Sprint

Where Agile Thinking Becomes Continuous Innovation

Menu
  • Home
  • About
Menu

Why Traditional Metrics Sabotage Agile Delivery

Posted on March 28, 2023June 15, 2026 by Daniel Valiquette

The metric isn't wrong. It's measuring the wrong thing.

I have a problem with metrics. Not with measuring, I love measuring. My problem is what we measure and what we do with the number once we have it. In agile delivery, the traditional metrics don't fail because they're sloppy or imprecise. They fail because they're pointed at the wrong target. They measure one thing above all else: how closely you stuck to a plan. And in agile, the plan was never supposed to be the truth. It's a hypothesis. You're supposed to break it on purpose when reality tells you to.

So when your metric punishes you for breaking the plan, it isn't neutral. It's actively working against you. It rewards stubbornness and punishes learning. That's not a measurement problem. That's a sabotage problem.

What these metrics actually reward

Let me name the usual suspects, because they show up in every steering committee deck I've ever seen.

  1. Progress versus baseline. This one assumes the baseline is correct. The whole calculation only means something if the original plan was right. But what happens the day you discover the baseline was built on a bad assumption? The metric doesn't care. It keeps telling you to push forward, on schedule, toward the wrong outcome. It's a GPS that insists on driving you into the wall because the wall was on the route it calculated this morning. Nobody in their right mind follows that GPS. Yet we follow the chart.

  2. Resource utilization at 100 percent. This is a factory metric. It made sense when the job was to keep an expensive machine running without idle time. A team is not a stamping press. A team booked to 100 percent has zero slack to absorb the unexpected, and in delivery the unexpected isn't an exception, it's the weather. Aiming for full capacity guarantees the traffic jam. The first surprise that lands has nowhere to go, so it backs up behind everything else and the whole pipe seizes.

  3. Hours worked. This measures effort, never result. And the math is brutal when you think it through: the slower you are, the more hours you log, the harder you appear to be working. Reward hours and you reward slowness. You're paying a premium to the people taking the longest to get nowhere.

  4. Deviation from plan, treated as a defect. This is the parent of all the others. A traditional metric measures the gap between where you are and where the plan said you'd be, and it treats that gap as something to correct. In agile, deviating because you learned something is the win. It's the entire point. The metric punishes the exact behavior you're trying to build.

The real danger isn't that they're useless

If these numbers were just useless, I'd shrug and ignore them. Useless is cheap. The actual problem is that they're not inert. They create incentives, and the incentives are poisonous.

When your career, your reputation, or your team's funding depends on showing progress against a baseline, you learn fast what to do. You hide bad news. You inflate the percent-complete. You quietly redefine "done" so the bar moves with you. You never, ever stand up in front of the room and say the plan is dead, because the metric has no column for "we were wrong and we're better off for it."

I've watched good people do all of this. Not because they're dishonest, but because the system they're measured by told them, very clearly, that admitting reality is the worst possible move. You can't blame someone for playing the game you put in front of them. If you want different behavior, change what gets rewarded. People are rational. They optimize for the number you stare at.

What to measure instead: how fast you learn

Flip the whole thing. Stop asking "did we follow the plan" and start asking "what did we learn, and how fast."

The metric I actually care about is the delay between two moments: the moment someone says "I have an idea" and the moment the team can say "now we know whether it holds." That gap is your learning speed. Shrink it and everything else gets better. A team that's wrong quickly and corrects quickly will crush a team that executes a perfect plan flawlessly, because the second team is executing the wrong thing with great discipline.

Think about what learning speed rewards. It rewards small bets over big commitments. It rewards killing a bad idea early instead of nursing it to launch out of pride. It rewards saying "the baseline was wrong" out loud, because that admission is itself a unit of learning, the most valuable kind. A team optimizing for learning speed has every reason to surface bad news the second it appears. The faster the bad news arrives, the faster they win.

Compare that to a team optimizing for plan conformance, where bad news is something to bury until the next reporting cycle, and you see the difference isn't cosmetic. You're shaping two completely different cultures with your choice of number.

The test for any metric you keep

Here's the filter I run everything through. A good agile metric has to be able to reward a change of course. If the only way to score well on your metric is to keep going straight, throw it out. It doesn't matter how clean the dashboard looks or how much the auditors love it. A metric that can't reward a course correction is a metric that's quietly betting against your team.

Run your current set through that test. Progress versus baseline fails it. Utilization fails it. Hours worked fails it. Learning speed passes, because the whole point of learning is that it changes where you're going.

What this means if you're the one holding the budget

My spine on leadership hasn't moved, and it doesn't move here either. Give the team a crystal-clear objective. Give them the constraints they actually have to live inside: the quality bar, the budget, the visibility the organization needs, the points where they have to play nice with other teams. Then give them full autonomy on the how, and hold them accountable for the result, not the route.

Notice what's missing from that list. Compliance to a plan. The plan is a tool the team uses and rewrites as it learns, not a contract they're punished for breaking. The minute you measure them against the plan instead of the objective, you've told them the plan matters more than the outcome, and they'll behave accordingly. They'll deliver the plan and miss the point.

So audit your metrics like you'd audit your budget. For each one, ask a single question: would this number ever go up because the team admitted it was wrong and changed direction? If the answer is no, you're not measuring delivery. You're measuring obedience, and you're paying for it in every truth nobody dared to tell you.

Category: Agile and Scrum

Post navigation

Cross-Team Dependencies Are a Design Problem →

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Latest

Categories

  • Agile and Scrum
  • Project Management and Leadership

Archives

  • June 2026
  • November 2025
  • October 2025
  • October 2024
  • May 2024
  • October 2023
  • March 2023
©2026 Beyond the Sprint