Methodology choice is a context decision, not a religion
Agile, Waterfall, Lean, PRINCE2, hybrid — the methodology wars are a category error. Pick the one that fits the work and move on.
The methodology wars are a category error. Methodologies are tools.
There is a particular flavor of LinkedIn argument — the Agile vs Waterfall one, the Scrum vs Kanban one, the SAFe is dead one — that has been recycling for a decade and shows no sign of stopping. The argument always presupposes that one methodology is correct and the others are mistakes. The argument is a category error.
Methodologies are tools. Some tools fit some contexts. Picking the methodology is the same kind of decision as picking the project's tech stack: a context decision, made once, defended on the merits, and reviewed only when the context materially changes. Teams that get this right spend roughly an hour a quarter on methodology. Teams that get this wrong spend the same hour every week and never converge.
This piece is the long-form anchor for the Methodologies & Frameworks pillar. It walks the six methodologies most teams actually choose between, the dimensions that should drive the choice, and the failure modes that surface when the methodology and the context disagree.
§1 — The six methodologies in regular use
Most teams will, in practice, only ever choose between six methodologies. The vendor ecosystem has more — every consultancy has a proprietary three-letter framework — but the underlying mechanics collapse to these six. We list them in roughly the order they were introduced.
Waterfall. Sequential phases, gate reviews between them, plan the whole thing upfront. The original. Suits work where the requirements are knowable upfront and the cost of late change is high (regulated, hardware, construction). Mocked in software, but software is not the only kind of project.
PRINCE2. Highly structured, governance-heavy, role-defined. UK government origin; popular in regulated environments and large public-sector engagements. Heavier than most software teams need; appropriate where audit trail and accountability dominate.
Scrum. Time-boxed iterations (sprints), small cross-functional teams, daily standup, retrospective at sprint end. Suits work where requirements evolve and the cost of late change is low (most B2B software). Most-misapplied: teams adopt the ceremonies, drop the discipline, end up with worse-Waterfall.
Kanban. Continuous flow, work-in-progress limits, visualize the queue. Lower-ceremony than Scrum. Suits ops-flavored work — support queues, content pipelines, infra teams — where work arrives unpredictably and prioritization happens at the queue level.
Lean. Eliminate waste, optimize the value stream, decide as late as possible. The most cross-discipline of the six (manufacturing roots, software adoption via Lean Startup). Suits cost-sensitive contexts where the question is should we build this before how do we build it.
Hybrid (sometimes "agile-fall"). Plan and gate the upfront phase like Waterfall; iterate the build phase like Scrum or Kanban. Disparaged in pure-Agile circles, but in practice it is what most enterprise software organizations actually run, regardless of what they claim on LinkedIn.
| Methodology | Best fit | Common failure | Cadence overhead |
|---|---|---|---|
| Waterfall | Hardware, regulated, construction | Late change costs more than the original work | Low (one big plan up front) |
| PRINCE2 | Public sector, audit-heavy | Process suffocates small teams | High (formal gates) |
| Scrum | B2B software, evolving requirements | Ceremonies without the underlying discipline | Moderate (sprint cadence) |
| Kanban | Ops, support, content pipelines | No mechanism for cross-team prioritization | Low (continuous flow) |
| Lean | Cost-sensitive, validation-driven | Treated as Scrum-with-different-vocabulary | Low (driven by experiments) |
| Hybrid | Enterprise software, mid-size shops | Gets called "Agile" while running like Waterfall | Moderate (varies by phase) |
§2 — The dimensions that actually drive the choice
Four dimensions decide which methodology fits. None of them is team preference. None of them is what worked at my last company.
Cost of late change. If shipping the wrong thing in month nine costs ten times what shipping it in month one would have, you want a methodology that front-loads decisions (Waterfall, PRINCE2). If late change is cheap (most software), you want one that defers decisions (Scrum, Lean).
Requirement stability. If you can write down what you want at month zero with confidence, plan the whole thing. If you are discovering the requirements as you build (most B2B software, all consumer software, anything user-research-driven), iterate.
Regulatory burden. Regulated work needs a paper trail. PRINCE2, Waterfall, and the regulated-Scrum variants (which exist) are the realistic options. Pure Kanban does not give you the artifact density an audit needs.
Team scale. Single team of 5-9 — Scrum or Kanban. Multiple teams shipping a coordinated product — SAFe (or one of the SAFe-likes) or a hybrid that adds explicit cross-team coordination on top of per-team Scrum. Past 200 engineers, you are doing portfolio management, not project management — see the Program Management pillar.
§3 — The five most common failure modes
The methodology mismatches we see in the wild are not random. They cluster.
Scrum-as-Waterfall. The team adopts sprint cadence and ceremonies but plans the whole quarter upfront, blocks scope changes mid-sprint, and treats the sprint review as a status report. The team is not doing Scrum; the team is doing Waterfall in two-week increments.
Kanban-as-no-process. The team adopts "continuous flow" but never sets WIP limits, never defines done, and ends up with a board where every card has been In Progress for six weeks. Kanban without WIP limits is a queue, not a methodology.
SAFe-as-religion. A consultancy installs SAFe, the org commits to all 47 ceremonies, and three quarters later the engineering teams are spending 30% of their time in PI Planning. SAFe works for some contexts (multi-team enterprise software with hard cross-team dependencies), but the ceremony density is the cost, not the benefit.
Hybrid-without-honesty. The org claims it runs Scrum but actually runs Waterfall with Scrum vocabulary. The dishonesty is the failure: leadership sets a fixed scope and a fixed date, the teams perform sprint planning around it, the dates slip, leadership blames the teams for not being agile. Calling the methodology what it actually is fixes 80% of this.
Lean-as-cost-cutting. Lean gets adopted as a euphemism for headcount reduction. The methodology is built around eliminating waste, which is not the same as eliminating cost. A Lean adoption that does not start with a value-stream map is not a Lean adoption; it is a budget cut wearing a methodology's clothes.
The methodology decision is a context decision, made once, defended on the merits, and reviewed only when the context materially changes. Teams that get this right spend an hour a quarter on methodology. Teams that get this wrong spend the same hour every week.
§4 — When to change methodologies
Methodology change is expensive. The team has to relearn the cadence, the rituals, the artifact set. Change for the wrong reason costs you a quarter; change for the right reason saves you a year.
The right reasons:
- The context changed. The product moved from build to operate, and Scrum's sprint cadence stopped making sense. The team scaled past the size where a single Scrum team can cover the work. The regulatory environment changed and audit-trail demands went up.
- The methodology never fit. A startup adopted SAFe at series B because the new VP had run it before. It has never fit. Reverting is the right call even though it looks like a step backwards.
- The methodology was adopted ceremonially. The team has been doing standups for two years and never once changed direction in response to one. The methodology is theater. Drop it (or actually do it).
The wrong reasons:
- A new VP wants their preferred methodology. This is the most common reason methodologies change in the wild. It is almost never the right reason.
- The team is having a bad quarter. Bad quarters have causes; methodology is rarely the cause. Diagnose first.
- A consultancy proposed it. Consultancies sell what they sell. The methodology that fits your context is the methodology that fits your context, not the methodology the consultancy is staffed to deliver.
§5 — Hybrid as the honest default
Most mid-size software organizations end up running a hybrid model — even when they claim otherwise. The honest version of this looks like:
- A discovery and charter phase run sequentially. The PM, the product lead, and a senior engineer write a charter that names the problem, the desired outcome, the budget envelope, and the methodology choice. Sequential because discovery's deliverable is agreement, which is hard to iterate on.
- A build phase run iteratively. Two-week or three-week cycles, working software at the end of each cycle, scope re-evaluated at the boundary. Iterative because the build's risk is building the wrong thing, which iteration mitigates.
- A stabilization and handoff phase run sequentially. Bug-fix and ops-handoff work that benefits from a single coherent push, not a string of partial states.
This is the model that survives most contact with reality in mid-size B2B software. Calling it hybrid — or agile-fall, or Wagile, or any of the half-dozen disparaging names — is fine. Calling it Scrum when it is not, is the failure mode.
Where methodology choice intersects the rest of project work
§6 — How to use this pillar
The rest of the Methodologies & Frameworks pillar walks each methodology in depth — what it is, when it fits, what it produces in artifacts, and the most common ways teams misapply it. Read the methodology you are currently running first, the one you are considering second, and skip the others until the context shifts.
The meta-rule: pick the methodology that fits the work, defend the choice in writing, and review only when the context materially changes. Most of the rest is theater.