Scrum vs. Kanban vs. Waterfall: What the Case Studies Really Show

Imagine you're leading a team that's been asked to deliver a new customer portal. You've read the agile hype, but your stakeholders are comfortable with the old way: gather all requirements, design the whole thing, then build and test in one long sequence. You have to choose a methodology. Do you stick with the familiar waterfall, or jump to Scrum? Maybe Kanban? The choice feels like a leap of faith, but it doesn't have to be. We've been in that spot, and we've learned that case studies—not vendor promises—are the only honest guide.

The Waterfall Myth

Let's start with the model that still dominates many project plans. Waterfall is sequential: requirements, design, implementation, testing, deployment, each phase finished before the next begins (Atlassian). It's neat on paper, but it's built on a myth. The 1970 paper by Winston Royce that's universally cited as the origin of waterfall never even uses the word 'waterfall'—and it actually argues against a one-way sequence. Royce said doing everything in a single sequence is unrealistic, that iteration between steps is better, and that testing comes too late. His remedy? 'Do it twice'—build a prototype first (Hebrew University). The paper we treat as the bible of waterfall is really a warning against it.

Scrum: The Empirical Engine

Scrum, in contrast, is built on empiricism: transparency, inspection, adaptation (Scrum Guide). It organizes work into sprints of one to four weeks, with a product backlog, sprint goal, and daily standups. The Scrum Team is cross-functional and self-managing, typically ten or fewer people, with one Product Owner and one Scrum Master (Scrum Guide). It's not a prescriptive process; the 2020 Guide calls itself 'purposefully incomplete' (Scrum Guide).

But does it work? The Standish Group's CHAOS data says yes—and no. Across over 50,000 projects, 35% succeed, 46% are challenged, and 19% fail (Standish). When you break it down by methodology, Agile projects succeed at 42%, while waterfall succeeds at just 13% (with 28% failing) (Standish). That's a stark difference. Yet the same report found the biggest success factor isn't methodology at all: it's decision latency. Projects with good decision latency succeed at 75%, versus 21% with bad latency (Standish). So Scrum is better than waterfall, but only if you're making good decisions quickly.

Kanban: The Flow Contrarian

Then there's Kanban, which doesn't use sprints or roles at all. It visualizes the workflow on a board, limits work in progress (WIP), and manages flow continuously (Atlassian). The four principles are simple: visualize, limit WIP, manage flow, improve (Atlassian). Kanban is less prescriptive than Scrum, making it attractive for teams that need flexibility, like a support team handling bug fixes while a Scrum team builds features (Atlassian).

Kanban's strength is its focus on flow metrics—cycle time, lead time, throughput, WIP (Atlassian). We've seen teams reduce cycle time dramatically just by limiting WIP. But Kanban doesn't force the discipline of retrospectives or the role clarity that Scrum does. For a team new to agile, Kanban can feel like just a board, not a methodology.

Head-to-Head: What the Evidence Says

Let's compare the three on the criteria that matter: success rate, adaptability, and decision-making. The CHAOS data gives us the only hard numbers. Agile (which includes Scrum and Kanban) beats waterfall on success rate. But the decision latency finding cuts across all methods—it's about how you run the project, not which label you put on it. In practice, we've seen waterfall teams with excellent communication succeed, and Scrum teams with poor leadership fail. The methodology is a container; the process inside matters more.

The table makes it clear: Agile wins on raw success, but the difference isn't as simple as 'Scrum is better than Kanban.' Both are agile. The real question is fit. For teams that need a clear framework and are willing to adopt roles and ceremonies, Scrum is the way. For teams that need continuous flow without the overhead, Kanban is better. Waterfall is only defensible in highly regulated environments where requirements are truly fixed and change is impossible—but even then, Royce's critique stands.

What I'd Actually Do

If I were starting a new software project today, I'd choose Scrum—but with a heavy dose of Kanban thinking and a relentless focus on decision latency. Here's why: Scrum gives you the skeleton—sprints, roles, ceremonies—that forces regular inspection and adaptation. The evidence from CHAOS is clear that agile beats waterfall, and Scrum is the most popular agile framework (71% of organizations use agile/Scrum, per PMI Pulse 2024). But I wouldn't be dogmatic. I'd keep the board visible, limit WIP even within a sprint, and measure cycle time as a leading indicator (Atlassian). And I'd make sure the Product Owner has the authority to make decisions quickly—because that's what separates the 75% from the 21% (Standish).

For a team that's already doing Scrum but struggling with flow, or a support team that can't commit to sprints, I'd switch to Kanban. It's not a downgrade; it's a different tool. The worst thing you can do is force Scrum onto a team that doesn't need it, or stick with waterfall because it's comfortable. The case studies are in: agile works, but only if you're honest about your decision-making. Start with Scrum, steal Kanban's flow practices, and measure your decisions as carefully as your velocity.

Sources

• Atlassian (Agile) - https://www.atlassian.com/agile
• Standish Group CHAOS Report - https://www.standishgroup.com/
• 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
• Atlassian (Kanban) - https://www.atlassian.com/agile/kanban
• 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/