Data Analysis Isn't the Problem: Decision Latency Is

Here's a misconception that drives me up the wall: that your project's success hinges on whether you pick Agile or Waterfall. It's neat, it's comfortable, and it's wrong. The evidence has been staring us in the face since at least 2020, and most teams still haven't looked at it.

The Myth of the Magic Methodology

Let's get the obvious out of the way. The Standish Group's CHAOS Report, which has tracked over 50,000 projects, found that 35% succeed, 46% are challenged, and 19% fail outright (Standish Group CHAOS Report). That's sobering enough. But when you break those numbers down by methodology, Agile projects succeed 42% of the time versus a paltry 13% for Waterfall (Standish Group CHAOS Report). Those figures are often trotted out as proof that Agile is the answer. If you're nodding along, stop. Because the same report contains a far more interesting – and uncomfortable – finding.

The CHAOS 2020 data identified decision latency as the single biggest success factor, not methodology. A staggering 75% of projects with good decision latency succeed, while only 21% of those with bad latency do (Standish Group CHAOS Report). That's a bigger gap than any methodology comparison. Yet we keep arguing about sprints vs. phases, about ceremonies and artifacts, while the real lever sits untouched.

Imagine You're a Data Analyst at a Bank

Let's make this concrete. Imagine you're a data analyst at a mid-sized bank, and you've been asked to lead a project to build a new fraud-detection model. Your team of four analysts and two engineers has been told to follow Agile, because the higher-ups read a blog post once. You run two-week sprints, you do daily stand-ups, and you have a product owner who's in another time zone. The first sprint, you discover that the data you need from the core banking system isn't accessible without a security review that takes three weeks. In a healthy Agile setup, you'd raise this at the daily stand-up, the product owner would make a call, and you'd pivot. Instead, because decision latency is bad, the product owner says, “Let's discuss it in the next sprint review.” That's two weeks lost. You also realize that your team is spending more time updating the Jira board than actually inspecting the data, because the definition of “done” is a wall of tickets, not a working model.

Now, is the failure here because you chose Agile? No. It's because your organization's decision-making processes are slow. The CHAOS data suggests that if you fixed that, you'd be better off than if you'd switched to Waterfall. And yet, the same report shows that 71% of organizations use Agile or Scrum, and 57% use hybrid approaches, while only 17% use waterfall only (Standish Group CHAOS Report). We've all jumped on the bandwagon, but we haven't changed how we decide.

The Numbers That Should Keep You Up at Night

If you're still skeptical, look at the adoption numbers. The 17th State of Agile Report, based on 788 respondents, found that 71% use Agile in their software development lifecycle, but only 11% are “very satisfied” with it, and 33% are “somewhat satisfied” (Digital.ai). That's a lot of lukewarm. Even worse, 97% say they practice Agile, but 83% admit their organization is not a high-Agile competency organization (Standish Group CHAOS Report). We're deluding ourselves.

So what does good decision latency look like in practice? It means that when a team member discovers a blocker, a decision is made within hours, not weeks. It means that the product owner isn't a committee, because the Scrum Guide is explicit that the Product Owner is one person, not a committee, and remains accountable for the Product Backlog (Scrum Guide 2020). It means that the team has the authority to adapt their sprint plan when new information emerges, because Agile is iterative and responsive to change (Atlassian).

In our fraud-detection project, a high-latency environment would have the product owner (the one person) empowered to say, “Okay, let's reorder the backlog and focus on the data we can access now, and we'll deal with the security review in parallel.” That's a decision that takes ten minutes. It doesn't require a steering committee.

How to Fix It, Not Just Talk About It

Here's my specific recommendation: stop auditing your methodology and start auditing your decision latency. Ask yourself, for any project, how long does it take from the moment a team member raises an issue to the moment a decision is made? If it's more than a day, you have a problem. And don't just measure it; fix it. Give your product owners real authority. Make sure they're not a committee, because the Scrum Guide says they're one person (Scrum Guide 2020). And if you're not using Scrum, at least adopt its empirical pillars of transparency, inspection, and adaptation (Scrum Guide 2020). Those pillars are the antidote to latency: you can't adapt if you don't inspect, and you can't inspect if you don't have transparency.

I'm not saying methodology doesn't matter. Waterfall's 13% success rate is abysmal, and Agile's 42% is better. But the gap between good and bad decision latency is 54 percentage points (75% vs 21%), which dwarfs the 29-point gap between Agile and Waterfall. So if you only have time to fix one thing, fix your decisions. Your project might not be perfect, but you'll be a heck of a lot better off than the 19% who fail outright because they couldn't decide fast enough.

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