Stop Blaming Your Agile Framework. Your Real Problem Is Decision Latency.

I once worked with a team that followed Scrum to the letter. They had daily standups, sprint reviews, and a beautifully maintained backlog. Yet every sprint ended with the same frustration: things didn't get done. The product owner would ask for a feature, the developers would build it, but then it sat in review for weeks because the marketing lead couldn't decide if the copy was 'on brand.' The team was agile in name, but their decisions were stuck in molasses.

This isn't an isolated story. The Standish Group's CHAOS 2020 report, which analyzed 50,000 projects, found that decision latency—the time between recognizing a decision is needed and actually making it—was a bigger predictor of success than whether you used Agile or Waterfall. Projects with low decision latency succeeded at a rate of 75%, while those with high latency only succeeded 21% of the time. That's a bigger gap than the one between Agile (42% success) and Waterfall (13% success). So before you blame your process, take a hard look at how fast decisions actually get made in your organization.

Why We Keep Chasing Frameworks

We love a shiny new framework. The 17th State of Agile Report (Digital.ai, 2024) says 71% of organizations use Agile in their software development lifecycle, but only 11% are 'very satisfied.' That's a massive gap. Why do we keep adopting methods that don't deliver? One reason is that frameworks give us a sense of control. We think if we just follow the Scrum Guide to the letter—three roles, five events, three artifacts—we'll get better outcomes. The Scrum Guide itself warns that Scrum is 'purposefully incomplete,' but we still treat it as a silver bullet.

The reality is that methodology is only part of the equation. As Martin Fowler put it in 'The New Methodology,' agile methods are adaptive and people-oriented, not predictive and process-oriented. That means the human element—especially decision-making—determines whether a framework works. If leaders can't make fast, informed decisions, no Sprint length or Kanban board will save you.

What Decision Latency Actually Means

Decision latency is the time between recognizing that a decision needs to be made and actually making it. In a traditional organizational hierarchy, decisions about scope, priorities, or technical direction often have to travel up several levels and back down. That latency kills agility. The CHAOS 2020 data shows that good decision latency correlates with success far more than any process choice. But what does good decision latency look like in practice?

It means the Product Owner—who the Scrum Guide says is 'one person, not a committee'—has the authority to make priority calls without waiting for a steering committee. It means developers can change a requirement when they discover a better approach, instead of sticking to a plan because changing it would require a change request. It means the team can adapt its Definition of Done when they find a quality issue, rather than waiting for a quarterly review.

In short, decision latency is about pushing decision-making authority down to the people who have the most context. That's why Scrum's cross-functional, self-managing teams—typically ten or fewer people—work better than larger, siloed groups. The smaller the team, the faster decisions move.

Why Agile Often Fails to Scale

You might think that scaling Agile would fix these issues, but the evidence says otherwise. The 17th State of Agile Report found that only 43% of larger companies say enterprise Agile works well, compared to 52% of small organizations. And the two main reasons for scaling failure are organizational resistance to change and insufficient understanding among leadership. That's not a framework problem; that's a decision-making problem.

Frameworks like SAFe, LeSS, and Scrum@Scale each try to address scaling differently. SAFe claims over 2 million trained professionals, LeSS emphasizes redesigning the organization, and Scrum@Scale extends core Scrum. But they all require a shift in how decisions are made. If leaders don't understand agile principles—like the Agile Manifesto's value of 'responding to change over following a plan'—they'll keep making slow, top-down decisions that undermine the framework.

So what's the best practice? Stop asking 'Which framework should we scale?' and start asking 'Where are decisions being delayed?' Then remove those bottlenecks.

How to Reduce Decision Latency in Practice

Here are concrete steps to reduce decision latency, based on what actually works:

• Empower the Product Owner. The Scrum Guide is clear: the Product Owner is accountable for Product Backlog management, and that includes ordering the work. If your Product Owner can't make a priority call without escalation, you've got a latency problem.
• Shorten your feedback loops. The Agile Manifesto's first principle says to satisfy the customer through early and continuous delivery. If you're only releasing every six months, you're making decisions with outdated information. Aim for shorter cycles—even if that means breaking features down.
• Use metrics that matter. Don't just track velocity. Track cycle time (time from 'in progress' to 'done') and lead time. DORA's research shows that speed and stability are not tradeoffs; elite teams deploy 208 times more frequently and 106 times faster than low performers (Atlassian DevOps). That speed comes from fast decisions, not just automation.
• Run effective retrospectives. The Sprint Retrospective is your chance to 'plan ways to increase quality and effectiveness.' Use it to identify where decisions got stuck and fix that.

Now, an example: imagine a team using Scrum with two-week sprints. They have a Product Backlog item that's been refined, but the Product Owner can't decide whether to include a feature because the VP of Sales wants it and the CTO doesn't. The team spends three days waiting. That's three days of latency. If the Product Owner had the authority to make the call—and the VP and CTO trusted that authority—the team could start immediately. Over a year, that's dozens of decisions, each potentially saving days.

Why You Should Ditch the Framework Debate

We're wasting time arguing about Scrum vs. Kanban vs. SAFe. The Standish Group CHAOS 2020 data is clear: decision latency is the biggest success factor, not methodology. Even the Agile Manifesto, written by 17 practitioners in 2001, values 'individuals and interactions over processes and tools.' That's a direct statement that people and how they make decisions matter more than the process you follow.

Of course, frameworks are not useless. Scrum gives you roles and events that, if used correctly, can shorten feedback loops. Kanban visualizes workflow and limits WIP, which exposes bottlenecks—often decision bottlenecks. But no framework will fix a culture where decisions are slow and centralized.

Bottom line

The single best move you can make to improve your methodology is to stop obsessing over which framework to adopt and instead measure and reduce your decision latency. If you have to pick one metric to track, track the time it takes from a decision being needed to being made. Then remove the organizational obstacles that slow it down. Agility is not a process; it's a capacity to adapt quickly. And that capacity is built on fast decisions.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• Digital.ai (17th State of Agile) - https://digital.ai/press-releases/17th-state-of-agile-report-71-use-agile-in-their-sdlc-small-organizations-report-strong-business-benefits-medium-and-larger-sized-companies-continue-to-experience-barriers-in-successfully-scaling-a/
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html
• Agile Manifesto - https://agilemanifesto.org/
• Martin Fowler (The New Methodology) - https://martinfowler.com/articles/newMethodology.html
• DORA (dora.dev) - https://dora.dev/guides/dora-metrics-four-keys/