Method Selection: Scrum, Kanban, Waterfall, or Hybrid?

The methodology debate is mostly noise. Teams pick a brand, defend it for years, and never check whether it fits the actual work. This chapter gives you a decision tree based on the shape of the work, not the brand on the consultant's slide. By the end you should be able to pick a methodology in 5 minutes and explain why.

When does the methodology choice actually matter?

Three signals.

New team formation. A team starting up needs cadence and artifacts; picking the wrong one costs a quarter of friction before someone calls it.

Quarterly retrospective. Mid-quarter, you notice the methodology is fighting the work - sprints constantly broken by incidents, or Kanban WIP creeping up because someone needs sprint demos. The right time to switch is the next quarter boundary, not next Monday.

Cross-team coordination. When 3 teams work on one project, their methodologies must align enough to plan together. One team's velocity is incompatible with another team's cycle time.

If the team is stable, the methodology is working, and the work shape has not changed, do not change methodology.

What is the cost of using the wrong methodology?

Three failure modes.

Constant ceremony cancellation. Standups skipped, retros postponed, planning rushed. The team has voted with feet that the methodology does not fit; nobody has dared say it.

Hidden methodology gaming. The team nominally does Scrum but actually has cards moving through columns daily without sprint boundaries. They are doing Kanban with extra meetings.

Methodology blame. "We missed the date because Scrum is broken" / "We can't predict ship dates because Kanban is too fluid". The methodology is the scapegoat; the underlying issue (scope creep, capacity gap) gets ignored.

What is the decision tree for method selection?

flowchart TB
    Start[New project starting] --> Q1{Scope fully fixed<br/>by external constraint?}
    Q1 -->|Yes| Waterfall[Waterfall<br/>compliance, hardware, fixed-bid]
    Q1 -->|No| Q2{Work arrives<br/>continuously?}
    Q2 -->|Yes| Kanban[Kanban<br/>support, ops, platform]
    Q2 -->|No| Q3{Stakeholders need<br/>2-week visibility?}
    Q3 -->|Yes| Scrum[Scrum<br/>feature delivery]
    Q3 -->|No| Q4{Stable team,<br/>6+ week cycles OK?}
    Q4 -->|Yes| ShapeUp[Shape Up<br/>product-led work]
    Q4 -->|No| Scrum

Three questions, four answers. The questions are about the work, not the team. A team of seasoned Scrum practitioners doing support work should still consider Kanban — the work shape overrides preference.

What is the concrete fit-each-methodology summary?

# Method Selection Cheat Sheet

## Scrum
- Best for: feature delivery, stable team, predictable arrival
- Cadence: 2-week sprints
- Key artifact: sprint goal + backlog
- Pitfall: ceremony theatre at small scale
- Reference: [chapter 06](/tech-pm/scrum-essentials)

## Kanban
- Best for: continuous flow, mixed work types, interrupt-driven
- Cadence: continuous, weekly metric review
- Key artifact: board with WIP limits
- Pitfall: stakeholders missing the cadence
- Reference: [chapter 07](/tech-pm/kanban-flow)

## Waterfall
- Best for: fixed scope, regulated, hardware-bound
- Cadence: phase gates (discovery -> design -> build -> test -> launch)
- Key artifact: detailed spec, signed off
- Pitfall: discovery missing surprises that derail later phases
- Reference: see compliance-heavy case studies in industry literature

## Shape Up
- Best for: product company with stable autonomous teams
- Cadence: 6-week cycles + 2-week cool-down
- Key artifact: pitch + bet
- Pitfall: hard to explain to non-product stakeholders
- Reference: Basecamp's "Shape Up" book, free online

## Hybrid (Scrum + Kanban)
- Best for: team doing features + ops/support
- Cadence: Scrum for features, Kanban for ops, same team
- Key artifact: capacity split (e.g. 70% sprint, 30% Kanban)
- Pitfall: capacity bleeds between the two; ops eats sprint
- Reference: this chapter

The cheat sheet fits in any team's onboarding doc. New engineers read it, understand which methodology applies to which work, stop asking "why don't we just do X".

What does method selection look like at multi-team scale?

flowchart TB
    Org[Org-level: quarterly roadmap] --> TeamA[Team A: Scrum<br/>feature delivery]
    Org --> TeamB[Team B: Kanban<br/>platform support]
    Org --> TeamC[Team C: Waterfall<br/>compliance project]
    TeamA --> Sync[Bi-weekly cross-team sync<br/>40 min]
    TeamB --> Sync
    TeamC --> Sync

Different teams use different methodologies; the org-level layer is methodology-neutral, focusing on outcomes and dependencies. The bi-weekly sync uses a common artifact (status report) regardless of how each team got the work done.

The mistake at scale is enforcing one methodology org-wide. SAFe fails most often this way: a team whose work is genuinely continuous-flow is forced into PI-planning rituals that produce fiction.

What failure modes does method selection introduce?

• Methodology change every quarter. "Scrum isn't working, let's try Kanban." Two months later, "Kanban isn't working, let's try Shape Up." Mitigation: change at most once per year; the second cause of dysfunction is rarely the methodology.
• Hybrid drift. Team starts with 70/30 sprint/Kanban; ops pressure pushes it to 30/70 silently. Mitigation: track and report capacity split in the retrospective; if ops is now most of the work, switch fully to Kanban.
• Methodology theatre after rebrand. Team renames "Scrum Master" to "Delivery Manager" but does the same ceremonies. Mitigation: the methodology is the practices, not the titles.
• Cross-team thrash. Team A's sprint output is Team B's backlog. If A runs Scrum and B runs Kanban with no shared cadence, dependencies stall. Mitigation: explicit handoff cadence even if internal methodologies differ.

When is method selection a distraction?

When the team is small, stable, and shipping. If 3 engineers are delivering value every week with whatever they call their process, do not impose a brand. The discipline that matters is the artifacts (estimation, status, decision log), not the methodology label.

The methodology earns scrutiny when work shape changes substantially - team grows past 8, a major project starts, the team's mandate shifts.

Where should you go from here?

You have completed the methodology section. Next chapter: discovery and kickoff - the lifecycle starts. Methodologies tell you how to run a sprint; the lifecycle chapters tell you what happens at each phase of a project regardless of methodology.