Stop Chasing Frameworks: The Real Best Practice Is Decision Latency

You've been lied to. Not maliciously, but persistently, by every Agile coach, Scrum trainer, and Kanban evangelist who ever told you that the secret to project success is picking the "right" framework. They'll sell you SAFe, LeSS, or Scrum@Scale, and they'll hand you a stack of metrics to track. But here's the uncomfortable truth hidden in the Standish Group's CHAOS data: the methodology you choose matters far less than how quickly you make decisions. The real best practice isn't a framework at all—it's decision latency.

The Myth of the Methodological Silver Bullet

Walk into any software organization and you'll hear the same debate: "We need to go Agile," or "Waterfall is killing us," or "We should try Kanban for our support team." The Standish Group CHAOS Report, which has tracked over 50,000 projects, found that Agile projects succeed at a 42% rate versus Waterfall's 13% (Standish Group CHAOS Report). That sounds like a slam dunk for Agile. But dig deeper into the same report, and you'll find that the biggest success factor isn't the methodology at all. It's decision latency—the speed at which you can make and act on decisions. Projects with good decision latency succeed at a 75% clip, while those with bad latency succeed only 21% of the time (Standish Group CHAOS Report). That's a bigger gap than the one between Agile and Waterfall. So why are we still arguing about frameworks?

Waterfall Was Never the Enemy It's Made Out to Be

Let's get one thing straight: Waterfall isn't inherently evil. It's a sequential, linear process where each phase—requirements, design, implementation, testing, deployment—must finish before the next begins (Atlassian (Agile)). It's easy to mock. But here's a history lesson: Winston Royce's 1970 paper, universally cited as the origin of Waterfall, never even uses the word "waterfall." In fact, Royce argued that doing everything in a single sequence is unrealistic, and he recommended building a prototype first—"do it twice"—to avoid late testing failures (Hebrew University (Royce waterfall slides)). The pure Waterfall model is a strawman that never had a real champion. So when the CHAOS Report shows Waterfall projects failing 28% of the time versus Agile's 19%, it's not because Waterfall is inherently broken. It's because the world changed, and Waterfall's lack of feedback loops makes it slow to adapt—slow to make decisions.

Agile's Own Dirty Secret: Adoption Without Competence

Now, before you start feeling smug about your Scrum board, consider this: 71% of organizations use Agile/Scrum, according to the PMI Pulse 2024 (Standish Group CHAOS Report). The 17th State of Agile Report found that 97% say they practice Agile, yet 83% admit their organization is not a high-Agile competency organization (Standish Group CHAOS Report). That's a massive gap between saying and doing. And only 11% of respondents in that same State of Agile report are "very satisfied" with their Agile approach (Digital.ai (17th State of Agile)). Why? Because they've adopted the ceremonies—the sprints, the stand-ups, the retrospectives—without adopting the mindset. They've bought the framework but not the underlying principle of rapid, informed decision-making.

Agile isn't a prescriptive process. As the Atlassian guide notes, it's a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement (Atlassian (Agile)). The Agile Manifesto itself, signed by 17 people in 2001, values individuals and interactions, working software, customer collaboration, and responding to change—not specific practices like two-week sprints or daily stand-ups (Agile Manifesto). If you're doing Scrum by the book but your team can't make a decision without waiting for a committee, you're not agile. You're just doing slow Scrum.

The Counter-Argument: "But We Need Structure"

You might be thinking, "Sure, speed matters, but my organization is chaotic. We need a defined framework to keep things from falling apart." That's a fair point. Frameworks like Scrum provide structure: three roles, five events, three artifacts (Atlassian (Scrum)). Scrum's empirical pillars are transparency, inspection, and adaptation (Scrum Guide 2020). That structure can indeed help teams become more efficient. But here's the problem: structure can also become a crutch. If you're so focused on following the Scrum Guide—timeboxing your Sprint Planning to eight hours for a one-month sprint, making sure your Daily Scrum is exactly 15 minutes—that you're missing the bigger picture, you've lost the plot. The 2020 Scrum Guide itself says the framework is "purposefully incomplete" (Scrum Guide 2020). It's not a complete solution; it's a skeleton. The flesh and blood must come from your team's ability to make good, fast decisions.

So What Actually Works? Decision Latency as the Best Practice

Let me be blunt: stop obsessing over whether you're doing Scrum or Kanban or a hybrid. The best practice is to shorten your decision latency—the time between recognizing a problem and acting on it. This aligns perfectly with the Agile principle of delivering working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale (Agile Alliance (12 Principles)). It also explains why Kanban, with its focus on continuous flow and limiting work in progress, can be a powerful tool for improving flow (Atlassian (Kanban)). When you limit WIP, you force decisions about what to do next and what to drop. You can't hide behind a backlog.

Here's a concrete example. Say your team is building a new e-commerce checkout feature. You've split it into user stories, each following the INVEST checklist—Independent, Negotiable, Valuable, Estimable, Small, Testable (Agile Alliance (INVEST glossary)). You estimate them in story points using planning poker (Atlassian (Story points)). But after the first sprint, the product owner realizes a competitor has launched a simpler checkout. If your team's decision-making process requires a steering committee meeting scheduled for next month, you're dead. But if your product owner—who, in Scrum, is one person, not a committee (Scrum Guide 2020)—can immediately reprioritize the backlog and have the team adjust, you'll survive. The framework didn't save you; your decision latency did.

How to Actually Improve Decision Latency

So, how do you cut decision latency? First, push decisions to the lowest possible level. In Scrum, the development team is cross-functional and self-managing (Scrum Guide 2020). Trust them to make technical decisions without asking permission. Second, make your feedback loops tight. This is where practices like Continuous Integration shine: every team member merges changes at least daily, and each integration triggers an automated build (Martin Fowler (Continuous Integration)). That way, if something breaks, you know within hours, not weeks. Third, measure the right things. DORA's research shows that speed and stability are not tradeoffs; elite teams deploy 208 times more frequently and are 106 times faster than low performers (Atlassian (DevOps)). Track your cycle time—the total time from "in progress" to "done"—and aim to shorten it (Atlassian (Agile metrics)).

Here's a comparison to help you see where to focus your energy:

Now, let me be clear: I'm not saying frameworks are useless. Scrum, for example, provides a solid starting point with its roles, events, and artifacts. But if you're only going to follow the rules without embracing the underlying values, you're wasting your time. The 17th State of Agile Report found that organizational resistance to change and insufficient understanding among leadership are the two main reasons Agile doesn't scale (Digital.ai (17th State of Agile)). That's not a framework problem; that's a culture problem. You can't solve a culture problem with a new process.

So, what's the one best move you can make starting tomorrow? Stop asking "What methodology should we use?" and start asking "How fast can we make a decision and act on it?" If you're in a leadership role, remove the bottlenecks. If you're on a team, push for the authority to make your own decisions. And then measure your improvement. The Standish Group's data is clear: decision latency is the biggest success factor. It's not the only factor, but it's the one most teams ignore. And it's the one you can control, regardless of the framework you choose.

The next time someone tries to sell you a new framework, remember: the framework is just a tool. The real best practice is to make decisions faster and better. That's the methodology that actually works.

Bottom Line

If you take away one thing, make it this: your methodology is not your savior. The Standish Group data shows that decision latency—not your choice of Agile, Waterfall, or anything in between—is the biggest predictor of success. Cut your decision latency, and you'll outperform teams that merely follow a framework by rote. That's the single best move you can make.

Sources

• Standish Group CHAOS Report - https://www.standishgroup.com/
• Atlassian (Agile) - https://www.atlassian.com/agile
• Scrum Guide 2020 - https://scrumguides.org/scrum-guide.html
• Hebrew University (Royce waterfall slides) - http://www.cs.huji.ac.il/~feit/sem/se09/2-waterfall.pdf
• 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/