Why Your Agile Is Failing: The Decision Latency Fix

Only 35% of software projects succeed, according to the Standish Group CHAOS Report. That's a sobering number, but the real shocker is that the methodology you pick matters less than how you make decisions. CHAOS 2020 found that 75% of projects with good decision latency succeed, versus just 21% with bad latency. Decision latency—the time between recognizing a problem and acting on it—is the hidden killer of projects.

We've all been there: a sprint is going sideways, the product owner is unavailable, and the team waits three days for a clarification. That's bad latency. And no amount of Scrum or Kanban will save you if your organization can't decide fast.

Imagine you're a delivery lead at a mid-sized company. Your team has been "doing Scrum" for a year, but velocity is flat, and the product owner is constantly frustrated. You've got the standard artifacts—product backlog, sprint backlog, increment—and you're holding all the ceremonies. But something is off. The 17th State of Agile Report found that 83% of organizations say they're not high-Agile competency, even though 97% claim to practice Agile. You're in that 83%.

Let's walk through a realistic scenario and see how the facts apply.

The Setup: A Team Stuck in Ceremony

Your team of nine developers, a product owner, and a Scrum master has been together for six months. You're doing two-week sprints, which is typical (Atlassian Scrum notes sprints typically last one to four weeks). But your product owner is also the head of product for three other teams, so they're rarely available. You have a backlog that's been refined, but stories are still vague, and every sprint planning meeting turns into a negotiation about what "done" means.

You're following the Scrum Guide: you have your three roles, five events, and three artifacts. But you're not reaping the benefits. The Scrum Guide says Scrum is founded on transparency, inspection, and adaptation—but if decisions take days, you can't adapt.

The Real Problem: Decision Latency

The CHAOS data is clear: decision latency is the biggest success factor, not whether you use Agile or Waterfall. Waterfall projects succeed only 13% of the time, while Agile projects succeed 42%—but that still leaves 58% of Agile projects challenged or failed. Why? Because teams adopt the ceremonies but not the mindset. They hold a daily stand-up (15 minutes, as per the Scrum Guide) but don't actually remove blockers.

In our scenario, the team is blocked on a UI design decision. The sprint goal is at risk. In a low-latency organization, the team would make the call themselves or escalate to someone who can decide in an hour. In a high-latency organization, they file a ticket and wait two days. The difference is the difference between success and failure.

Why Agile Frameworks Often Fail to Help

Agile frameworks like Scrum give you structure, but they don't give you authority. The Scrum Guide says a Scrum Team is self-managing and cross-functional, but it also says the Product Owner is one person who remains accountable for backlog management. If that one person is a bottleneck, you have a problem.

The 17th State of Agile Report found that organizational resistance to change and insufficient leadership understanding are the top reasons Agile isn't scaling. In our scenario, the leadership doesn't trust the team to make decisions, so every change request goes through a long approval chain. The team is following Scrum, but they might as well be following Waterfall, because the approval process is sequential.

The Fix: Reduce Latency with Delegation and Feedback

Here's what we'd actually do: push decision-making down to the lowest possible level. The Scrum Guide says the Developers are responsible for sizing and decomposition—so let them also decide how to handle minor scope changes within a sprint. For bigger decisions, institute a rule: any blocker gets escalated to a decision-maker within one hour. That's an aggressive target, but it's what good latency looks like.

We also need to shorten feedback loops. The Agile Manifesto values working software over comprehensive documentation, and one of its principles is to deliver working software frequently, from a couple of weeks to a couple of months. If you're only reviewing at the sprint review, that's a two-week loop. But you can shorten it with continuous integration (CI). Martin Fowler describes CI as a practice where each team member merges changes at least daily, and every push triggers an automated build. That gives you feedback in minutes, not weeks.

Comparing Options: Scrum, Kanban, or Hybrid?

When you're looking to fix latency, you have choices. Scrum gives you fixed-length sprints and a defined structure, but Kanban focuses on continuous flow and limiting work in progress. Many teams combine them—for example, using Scrum for feature work and Kanban for bug fixes (Atlassian Agile). The table below compares the two based on key factors.

In our scenario, switching to Kanban might help because it exposes bottlenecks—the WIP limit forces you to stop starting new work and focus on finishing. But the real fix is not the board; it's the culture.

A Worked Example: The UI Design Block

Let's say the team is blocked because the product owner hasn't approved a design change that affects three stories. In a low-latency setup, the team would have a conversation with the product owner at the daily stand-up (which is, after all, a 15-minute event for the Developers to inspect progress). They'd agree on a minimal viable design that meets the sprint goal, and the product owner would approve it on the spot, or delegate approval to the UI lead. The team proceeds, and the sprint goal is saved.

In a high-latency setup, the team sends an email, waits for a response, and two days later the sprint is blown. The difference is not the framework—it's the decision latency. The CHAOS data shows that 75% of projects with good decision latency succeed, so this isn't a minor nicety; it's the difference between success and failure.

What I'd Actually Do

Here's my opinion, and I'll be blunt: if you're not fixing decision latency, you're wasting your time with Agile. I'd start by measuring it. Track the time from when a blocker is raised to when a decision is made. Aim for under one hour for non-critical decisions, and under 24 hours for critical ones. If you can't do that, you need to restructure your decision-making.

In practice, that means giving your team more authority. The Scrum Guide says the Developers are responsible for sizing, but I'd go further: let them decide how to handle small scope changes within a sprint, as long as the sprint goal is met. For larger changes, have a fast escalation path to the product owner. If the product owner is overloaded, consider a product owner team—but the Scrum Guide says the Product Owner is one person, not a committee, so you need to give that person more support, not replace them.

Also, shorten your feedback loops. Adopt continuous integration if you haven't already—it's a practice that's been around for decades (Fowler). And consider using Kanban for your support work to reduce cycle time. The 17th State of Agile Report found that 34% of respondents create their own framework or don't follow a mandated one—so don't be afraid to blend.

Finally, remember that Agile is not a silver bullet. The Standish Group's CHAOS Report shows that even Agile projects fail 19% of the time (if you look at all projects, not just Agile vs. Waterfall). The difference is how you handle the unexpected. Good decision latency is a skill, and it can be learned. Start by making faster decisions, and you'll see your project success rate climb.

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
• Atlassian (Agile) - https://www.atlassian.com/agile
• Martin Fowler (Continuous Integration) - https://martinfowler.com/articles/continuousIntegration.html
• Agile Manifesto - https://agilemanifesto.org/