Teams argue about delivery methodologies as if they were tribes, Agile people versus Waterfall people, Scrum versus Kanban, when the honest truth is duller and more useful: each one is a different bet about how much you can know before you begin. Pick the method that matches your uncertainty, not the one with the best conference.

The quick version

  • Waterfall plans the whole thing up front and moves through phases in order. It works when requirements are stable and the cost of a late change is brutal, bridges, regulated hardware, fixed-scope contracts.
  • Agile is not a process; it is a set of values (the 2001 Agile Manifesto) about delivering working software early, welcoming change, and keeping plans short. Scrum and Kanban are two of the ways teams put those values into practice.
  • Scrum works in fixed timeboxes (sprints) with set roles and ceremonies; Kanban has no sprints, it visualises the workflow and limits how much is in progress at once, optimising for a smooth, fast flow.
  • Hybrid ("Water-Scrum-Fall") is what most large organisations actually run: plan and budget up front, build in sprints, release on a fixed schedule. It is a compromise, not a failure, but name the seams so they do not bite you.

The idea in depth

The whole field organises around a single trade-off. Spend more time planning up front and you reduce the chance of building the wrong thing twice, but you bet everything on a forecast made when you knew least. Plan less and adapt more, and you trade that certainty for the ability to change course cheaply. Every methodology below is a different place to stand on that line.

Waterfall stands at the planning end. It is usually traced to Winston Royce's 1970 paper "Managing the Development of Large Software Systems", which laid out the familiar sequence, requirements, design, build, test, operate, as a stepped flow. The twist the slogans forget: Royce presented that pure linear model and then immediately warned the approach was "risky and invites failure," arguing for feedback loops and an early prototype. Waterfall's reputation as a naïve straw man is partly unfair to the man whose diagram got borrowed. The lesson isn't "never plan up front." It's to ask honestly whether you can know the requirements before you build. When the answer is genuinely yes, a known compliance standard, a fixed physical spec, a phased plan is the responsible choice, not the old-fashioned one.

Agile stands at the adapt end, and it is worth being precise about what it is. In February 2001, seventeen practitioners met in Snowbird, Utah, and wrote the Manifesto for Agile Software Development: four value statements ("working software over comprehensive documentation," "responding to change over following a plan," and two more) plus twelve principles. Read it and you will notice it prescribes almost nothing, no sprints, no stand-ups, no roles. It is a statement of preferences for high-uncertainty work. Which is why "we do Agile," said as though it were a thing you install, misses the point. The useful question is which concrete practices express those values for your team, and that is where Scrum and Kanban come in.

Scrum gives Agile a skeleton. The current 2020 Scrum Guide by Ken Schwaber and Jeff Sutherland defines a deliberately minimal frame: one cross-functional team with three accountabilities (Product Owner, Scrum Master, Developers), a fixed-length Sprint (a month or less) that contains the other events, Sprint Planning, the 15-minute Daily Scrum, the Sprint Review, and the Retrospective. The rhythm is the point: every sprint forces a small plan, a working increment, and a moment to inspect and adapt. If your work is uncertain and your team is genuinely dedicated, that timebox earns its keep as a forcing function: ship something real every couple of weeks and let the feedback rewrite the plan.

Kanban takes a different route to the same goal, and its lineage is older. The word and the idea come from Taiichi Ohno's Toyota Production System, where physical cards signalled when to replenish work, pull, not push. David J. Anderson adapted it for knowledge work in his 2010 book Kanban: Successful Evolutionary Change for Your Technology Business. Kanban has no sprints and changes no roles; you start with how you work today, make the workflow visible on a board, and impose WIP limits, a hard cap on how many items can sit in each column. The counter-intuitive result is that limiting how much you start makes things finish faster, because half-done work is inventory that ages and hides problems. For a support, operations or steady-flow team, the first move is the cheapest one: cap work in progress before you change anything else, and watch your lead time fall.

flowchart TD
  Q{"Can you know most
requirements up front?"}
  Q -->|"Yes, stable, high cost of late change"| W(["Waterfall
phased plan, fixed scope"])
  Q -->|"No, uncertain, learning as you go"| A{"Is the work projects,
or a continuous flow?"}
  A -->|"Bounded projects,
dedicated team"| S(["Scrum
fixed sprints + roles"])
  A -->|"Continuous arrival
(ops, support, BAU)"| K(["Kanban
visualise flow, limit WIP"])
  Q -->|"Mixed, plan up front,
build iteratively"| H(["Hybrid
Water-Scrum-Fall"])
A first cut at choosing, driven by how much you can know up front and how work arrives, not by fashion. Leaders Loop

What the evidence does and doesn't say

It is tempting to claim Agile simply "wins." The honest position is narrower. The best-known empirical claim, from the Standish Group's CHAOS reports, is that agile projects succeed more often than waterfall ones; the figures are widely cited but the methodology behind them is proprietary and contested, so treat the direction as suggestive rather than settled. A more defensible body of evidence comes from the DORA / State of DevOps research, which measures delivery performance (deployment frequency, lead time, failure rate, recovery time) rather than crowning a methodology. Its consistent finding is that small batches, fast feedback and frequent delivery correlate with better outcomes, which is the mechanism underneath both Scrum and Kanban, not a vote for either brand.

An honest limitation. None of this proves a method works for your context. Scrum on a team that cannot be dedicated, or whose work arrives unpredictably, often degrades into theatre, stand-ups with no shippable increment. Kanban without genuine WIP limits is just a nicer to-do list. And Agile's own data has an awkward edge: many "Agile transformations" report the ceremonies without the outcomes. Measure the thing the method is supposed to improve, your lead time, your release frequency, your rework, and let that, not adherence to a framework, tell you whether it is working.

The methodology is the scaffolding. The thing worth measuring is whether work flows faster and changes get cheaper, not whether you held the right ceremony.

Hybrid: what most organisations actually run

Pure methods are rare in the wild. The common reality has a name, "Water-Scrum-Fall," coined by Forrester analyst Dave West to describe how enterprises plan and budget up front (the "water"), let teams build in sprints (the "scrum"), then push releases through a slow, gated deployment process (the "fall"). It is easy to sneer at, but it is often a rational response to real constraints: annual budgets, compliance gates, downstream teams that cannot release on demand. The danger is not hybridity itself; it is pretending the seams are not there. Name each one, where does the up-front plan hand over to the sprinting team, and where does the sprinting team hand over to the release process? then attack whichever seam is the real bottleneck. Usually it is the last one: teams that sprint beautifully and then wait six weeks to ship have an Agile middle bolted to a Waterfall end.

A worked example

Take a 40-person insurance company building a new claims portal. (Illustrative scenario; figures are for teaching, not a real client.) The instinct is to "go Agile" wholesale. The better instinct is to split the work by its uncertainty.

The regulatory engine, the rules that decide what a claim pays, is governed by law and an external auditor. The requirements are knowable and the cost of getting them wrong is enormous. That slice is treated Waterfall-style: specify it carefully up front, design, build, test against the regulation, sign off. The customer-facing portal is the opposite: nobody knows what will make claimants complete the form, and the team can learn weekly. That slice runs Scrum, two-week sprints, a working flow demoed every fortnight to real users, the backlog reordered by what the demos reveal. Meanwhile the live-running support team that maintains the existing system runs Kanban: a board, a WIP limit of, say, five items per person, and a relentless focus on lead time, because their work arrives as a stream of tickets, not a project.

flowchart LR
  P(["New claims portal
(one programme)"]) --> R(["Regulatory engine
→ Waterfall: spec, build,
audit, sign-off"])
  P --> C(["Customer portal
→ Scrum: 2-week sprints,
demo to real users"])
  P --> O(["Run & support
→ Kanban: board + WIP cap,
optimise lead time"])
  R --> X(["Hybrid release train
name the seams, attack
the slow handover"])
  C --> X
  O --> X
One programme, three methods, matched to how knowable and how steady each slice of work is. Leaders Loop

The result is not ideological purity; it is fit. The single number that proves it is the same one DORA cares about: how long does a change take to reach a real user, and how often does that go wrong? If the portal team's lead time keeps falling while the regulatory slice stays audit-clean, the mix is working. If the whole thing jams behind one quarterly release, the methodology was never the problem, the release process was.

Frequently asked questions

Is Waterfall always the wrong choice now?

No. Waterfall is a poor fit for uncertain, fast-changing work, which is most software, but it remains sensible where requirements are genuinely stable and a late change is ruinously expensive: regulated hardware, construction, fixed-scope contracts, safety-critical systems. The mistake is using it by default. Choose it on purpose, because the requirements are knowable, not out of habit.

What's the actual difference between Scrum and Kanban?

Scrum organises work into fixed-length sprints with defined roles and events; you commit to a batch of work for the sprint and protect the team from changes mid-sprint. Kanban has no sprints and changes no roles, you visualise your existing workflow and cap work in progress, optimising for continuous flow. Scrum suits bounded projects with a dedicated team; Kanban suits a steady stream of incoming work like operations or support.

Can you do both Scrum and Kanban together?

Yes, it is common enough to have a name, "Scrumban." Teams keep Scrum's cadence and roles while adding Kanban's board and WIP limits to expose bottlenecks. Henrik Kniberg's minibook Kanban and Scrum, Making the Most of Both is the standard reference; the two are tools, not rival faiths, and many teams blend them deliberately.

We "do Agile" but nothing improved. Why?

Usually because the team adopted the ceremonies without the outcomes the ceremonies exist to produce. Stand-ups, sprints and boards are mechanisms for delivering working increments early and adapting from feedback. If you are not shipping something real frequently, or not changing the plan when the feedback says to, you have the rituals without the value. Measure lead time and delivery frequency, not attendance.

How do I choose without starting a turf war?

Start from the work, not the brand. Ask how knowable the requirements are, how the work arrives (as projects or a continuous stream), and how late a change can be made cheaply. Let those answers point to a method, agree to measure the outcome it should improve, and review in a few weeks. Framing it as an experiment with a metric, rather than an identity, takes most of the heat out of the argument.

Related in the Toolkit

Methodology is the engine; the surrounding disciplines decide whether it delivers. How you govern the wider portfolio of work (project, program & portfolio management) sets the budgets and gates a hybrid model has to live inside, and the planning rhythm you adopt (sprint / PI / OKR planning) is where a method either connects to real outcomes or floats free of them.

Where to go next