Comparison and Choosing a Methodology

The summary interview question: “given this team / project / constraints, what methodology would you pick?” The strong answer isn’t “Scrum” — it’s “depends on these factors, here’s how I’d decide.”

The four at a glance

Agile is the umbrella over Scrum and Kanban. Waterfall is the sequential alternative. XP, Lean, SAFe, etc. layer on top of these.

Choosing — the questions to ask

What’s the work shape?

How stable are the requirements?

What’s the team size and structure?

What’s the customer / stakeholder availability?

What’s the engineering maturity?

When you’d use Scrum

• Product development with evolving requirements.
• A stable team of 5–9 people.
• Available PO who can prioritize and clarify.
• Stakeholders who can attend sprint reviews.
• Work that fits in 2-week iterations (most product work does).
• Need for predictable demo cadence.

Indicators against Scrum:

• Highly interrupt-driven work.
• Unpredictable arrival of tasks.
• Fragmented team across many products.
• Stakeholders too busy for sprint reviews.

When you’d use Kanban

• Continuous-flow work (support, ops, content production).
• Maintenance on a mature product.
• Bug-heavy work without natural iteration boundaries.
• Mixed team (developers + support + ops).
• Team burned out on Scrum ceremonies.
• Need for visible flow and explicit policies more than iteration goals.

Indicators against Kanban:

• Need for cohesive iteration goals (Scrum’s Sprint Goal does this better).
• External stakeholder rhythms (need demos on a cadence).
• New teams without flow discipline.

When you’d use Waterfall

• Safety-critical certified software (avionics, medical devices).
• Fixed-scope, fixed-budget government / defense contracts.
• Hardware-software co-development with long lead times.
• Pure compliance implementations of external standards.
• Migrations to known target with stable requirements.

Even here: hybrid is often best. Outer Waterfall structure (phases, sign-offs); inner Agile execution.

Indicators against Waterfall (most modern software):

• Product discovery is part of the work.
• Iteration is needed to find product-market fit.
• Technology evolves during project lifespan.
• Customer collaboration is feasible.

Scrumban — the hybrid

Most teams informally land in “Scrumban”:

• Fixed cadence (sprints) for planning and review.
• WIP limits + pull-based flow within the sprint.
• Story points or no estimates (team’s choice).
• Retros from Scrum; metrics from Kanban.

Not formally defined; emerges from teams using “what works.” Avoid the trap of pretending it’s pure Scrum or pure Kanban — be explicit about which practices you’ve kept.

Hybrid Waterfall-Agile

The dominant pattern in enterprise:

[ Initiation ] — formal phase
[ Implementation ] — Agile / Scrum / Kanban inside
[ Acceptance / UAT ] — formal phase
[ Maintenance ] — ongoing

Procurement / contract / certification needs phases. The actual building uses Agile. Don’t fight either; deliver both.

Methodology vs practices

The methodology label matters less than the underlying engineering practices:

A team with these practices can be effective in Scrum, Kanban, or Waterfall. A team without them struggles regardless of label.

When interviewers ask “what methodology?” the engineering-focused answer is “we use X with Y practices” — the practices reveal the actual quality of work.

Red flags in interview answers

When candidates say:

• “We do Agile.” — what does that mean? Specifics.
• “We follow Scrum by the book.” — orthodoxy without context awareness.
• “We don’t need process.” — usually masks “we wing it.”
• “We have daily standups so we’re Agile.” — cargo-cult.
• “Methodology X is always best.” — context matters.

Strong answers:

• “We use Scrum with 2-week sprints, but support work happens on a parallel Kanban board so it doesn’t break sprint commitments.”
• “We started with Scrum; over time moved toward Kanban as our work became more support-heavy.”
• “Our team is small enough we skip most ceremonies and rely on async chat + a Kanban board + monthly retros.”

Specifics, evolution, awareness of trade-offs.

What interviewers are really asking

“What methodology do you use?” is often a proxy for:

1. Do you know the vocabulary? Can you discuss process intelligently?
2. Have you lived through it? Specifics vs textbook recitation.
3. Do you have opinions? Or do you parrot whatever’s popular?
4. Can you adapt? Or are you dogmatic about one approach?

The strongest interview answer is opinionated, context-aware, and grounded in specifics. “I’ve worked in Scrum and Kanban; for product development with PO availability I prefer Scrum; for support-heavy work I prefer Kanban; for new teams Scrum’s structure helps; we adapted ours over time.”

Common interview confusions

• “Agile means Scrum.” — Scrum is one Agile framework; Kanban, XP, Lean, others also exist. Agile is the philosophy.
• “Modern teams don’t use Waterfall.” — modern teams use hybrid (Waterfall outer, Agile inner). Pure Waterfall is rare for product dev; phased structure for certification / contracts is common.
• “Velocity comparison is fair.” — story points are team-relative. Comparing velocities across teams compares incompatible scales.

Interview angle

• “When would you choose Scrum over Kanban?” — feature development with iterative goals, stable team, available PO, stakeholders who can attend sprint reviews, work that fits in 2-week iterations. Kanban for support / ops / continuous-flow work.
• “When would you use Waterfall?” — safety-critical certified software, fixed-scope government contracts, hardware-software co-development, pure compliance work. Often hybrid: Waterfall framing for contract / sign-offs, Agile execution inside.
• “What’s Scrumban?” — informal hybrid: fixed cadence (sprints) for planning + review, WIP limits + pull within the sprint. Most real teams land here in practice.
• “How would you choose a methodology for a new team?” — ask about work shape (continuous vs iterative), customer availability, team size, requirements stability, regulatory constraints. The methodology should fit the context; no single answer.
• “What’s more important — the methodology or the practices?” — practices. CI/CD, automated testing, code review, feature flags, small batches matter more than the methodology label. A team with these practices succeeds in any methodology.
• “Tell me about your team’s process.” — be specific: cadence, ceremonies, what works, what was tweaked, what failed. Specifics + evolution + awareness of trade-offs beats orthodox recitation.