Chapter 2: An Honest Comparison of SDLC Models: Waterfall, Iterative, Agile/Scrum, Kanban, Lean, Spiral, DevOps

Why this matters

Most engineers can name several SDLC models but few can honestly compare them, because most discussion of this topic (especially "Agile vs. Waterfall") is delivered as advocacy rather than an honest accounting of trade-offs. Waterfall, specifically, gets an unfairly one-sided reputation — it's a genuinely reasonable choice in specific, real contexts, not simply "the outdated way everyone has moved past." This chapter gives every model a fair, honest hearing.

Waterfall: sequential, complete-each-stage-before-the-next

[BEGINNER] Waterfall moves through the core stages (Chapter 1) strictly in sequence — requirements fully gathered and signed off before design begins, design fully completed before implementation begins, and so on — with no planned return to an earlier stage.

Requirements (complete) -> Design (complete) -> Implementation (complete) -> Testing (complete) -> Release
(each stage fully finishes and is formally approved before the next stage begins at all)

Genuine strengths: works well when requirements are genuinely stable and well-understood upfront (a well-specified regulatory compliance system, a contract with fixed, detailed specifications agreed before work begins), and its heavy upfront documentation provides strong traceability and accountability — valuable in regulated industries (aerospace, medical devices, government contracting) where audits and formal sign-offs are a hard requirement, not a nice-to-have.

Genuine weaknesses: extremely costly to change course once implementation has started, since going back to revise requirements or design after downstream work has begun means discarding significant sunk investment; provides no working software until very late in the process, meaning a fundamental misunderstanding of requirements isn't discovered until it's most expensive to fix.

[SENIOR INSIGHT] The honest, balanced take: Waterfall's reputation as "the bad old way" comes specifically from its poor fit for software with evolving, poorly-understood-upfront requirements (which describes most commercial software products) — but for the genuinely stable-requirements, high-compliance-burden contexts it actually fits, it remains a reasonable, sometimes mandated choice, not a mistake.

Iterative and incremental development

[BEGINNER] Iterative development repeats the full cycle (requirements → design → implementation → testing) multiple times, each iteration producing a more complete, refined version of the software — rather than one single pass through the full sequence. This is the conceptual bridge between Waterfall and Agile: it keeps Waterfall's stage structure but repeats it in smaller cycles, surfacing misunderstandings much earlier than a single-pass Waterfall project would.

Iteration 1: Requirements(subset) -> Design -> Implement -> Test -> [working, partial software]
Iteration 2: Requirements(refined) -> Design -> Implement -> Test -> [more complete software]
Iteration 3: ... (repeats, each cycle adding/refining functionality)

Agile/Scrum: fixed-length iterations with defined ceremonies

[BEGINNER] Scrum is the most widely adopted specific Agile framework: work is organized into fixed-length sprints (commonly 1-2 weeks), with a defined set of ceremonies structuring each sprint:

Sprint Planning (start of sprint: what will we build this sprint?)
      |
Daily Standup (each day: brief sync on progress/blockers) -- repeated daily throughout the sprint
      |
Sprint Review (end of sprint: demo completed work to stakeholders)
      |
Sprint Retrospective (end of sprint: what went well, what should change for next sprint)
      |
      -> back to Sprint Planning for the next sprint

Genuine strengths: frequent, regular delivery of working software provides fast feedback on whether requirements were actually understood correctly; the retrospective builds in explicit, regular process improvement; fixed sprint length creates a predictable rhythm for stakeholders.

Genuine weaknesses: the ceremony overhead (planning, daily standups, review, retrospective) is real and can feel burdensome for very small teams or highly exploratory work where the rigid sprint boundary doesn't match the actual pace of discovery; poorly-run Scrum (ceremonies followed as ritual without genuine engagement) produces exactly the "process theater" Chapter 1 warned about, with none of the framework's real benefits.

Kanban: continuous flow, no fixed iterations

[BEGINNER] Kanban visualizes work as it flows through stages on a board (commonly: To Do → In Progress → In Review → Done) with an explicit work-in-progress (WIP) limit on how many items can occupy each stage simultaneously — rather than organizing work into fixed-length sprints, work items flow continuously, pulled into the next stage as capacity allows.

[To Do] --pull--> [In Progress (WIP limit: 3)] --pull--> [In Review (WIP limit: 2)] --pull--> [Done]

Genuine strengths: no artificial sprint-boundary pressure — a piece of work moves forward exactly when it's ready, not when a sprint happens to end; the WIP limit directly, visibly surfaces bottlenecks (if "In Review" is perpetually full, that's an immediate, visible signal review capacity is the constraint); fits well for support/maintenance work with unpredictable, continuously-arriving priorities (bug reports, ad hoc requests) that don't fit neatly into sprint-sized planning.

Genuine weaknesses: the lack of fixed iteration boundaries can make it harder to create the predictable planning/demo rhythm stakeholders sometimes need; without discipline, WIP limits can be quietly ignored under pressure, at which point Kanban's core visualizing/bottleneck-surfacing benefit is lost entirely.

Lean: eliminating waste as the central organizing principle

[BEGINNER] Lean software development (adapted from Lean manufacturing) organizes around explicitly identifying and eliminating "waste" — anything that doesn't directly contribute value to the customer: unnecessary process overhead, unfinished work sitting idle, features built but never used, excessive handoffs between people/teams. Lean isn't a specific process structure (like Scrum's sprints or Kanban's board) so much as a set of principles that can inform how any other model is actually run — a Scrum team and a Kanban team can both apply Lean thinking by regularly asking "what here is genuinely necessary, and what's waste we've just gotten used to."

Spiral: risk-driven, repeated risk analysis at each cycle

[BEGINNER] The Spiral model combines iterative development with explicit, formal risk analysis as a required step in every cycle — each iteration ("spiral") begins by identifying and analyzing the biggest risks facing the project at that point, then plans the iteration's scope specifically around addressing or mitigating those risks, before proceeding to design/build/test.

Spiral 1: Identify risks -> Analyze/mitigate biggest risk -> Build/test a piece addressing it -> Plan next spiral
Spiral 2: Identify risks (informed by Spiral 1's outcome) -> Analyze/mitigate -> Build/test -> Plan next spiral
... (each spiral is larger in scope than the last, as major risks are progressively retired)

When it fits: large, high-uncertainty, high-stakes projects (major government/defense systems, novel technical territory) where the cost of an undiscovered major risk materializing late would be catastrophic — the explicit, repeated risk-analysis discipline is worth its real overhead specifically in these contexts; it's genuinely excessive overhead for a typical, lower-stakes commercial software project.

DevOps and continuous delivery: collapsing the boundary between building and operating

[SENIOR INSIGHT] DevOps isn't a stage-ordering model like the others in this chapter — it's a cultural and technical practice emphasizing tight integration between development and operations (traditionally separate teams/concerns), enabled specifically by automation (CI/CD pipelines, covered fully in Chapter 9) that makes release a frequent, low-risk, largely automated event rather than a rare, high-ceremony one. Continuous delivery (software is always in a deployable state, released frequently, sometimes many times per day) is DevOps's most visible practical manifestation, and it can layer on top of Scrum, Kanban, or nearly any other model in this chapter — it answers a different question (how does software get from "done" to "running in production," and how tightly are the people who build it involved in operating it) than the other models in this chapter, which mostly answer "how is work planned and structured."

A fair comparison table

Model	Best fit	Real cost
Waterfall	Stable, well-understood-upfront requirements; heavy compliance/audit needs	Very costly to change course; no working software until late
Iterative	Requirements that will be refined through feedback, moderate uncertainty	Requires discipline to actually revisit and refine each cycle
Scrum	Teams wanting a predictable rhythm and built-in regular retrospection	Real ceremony overhead; can become "process theater" if run poorly
Kanban	Continuous, unpredictable-priority work (support, maintenance)	Less inherent planning/demo rhythm; WIP limits need real discipline
Lean	Any model, as a supplementary "eliminate waste" lens	Not a complete process on its own — needs a structural model alongside it
Spiral	Large, high-uncertainty, high-stakes projects	Real overhead from formal risk analysis at every cycle; excessive for typical projects
DevOps/CD	Any model, as the release/operations layer	Requires real investment in automation (CI/CD) to do well

Common mistakes

1. Treating "Agile vs. Waterfall" as a simple better-vs-worse comparison rather than recognizing each fits a genuinely different context — Waterfall's poor fit for evolving requirements doesn't make it universally wrong for the stable-requirements, high-compliance contexts it was designed for.
2. Confusing DevOps/continuous delivery with a stage-ordering model like Scrum or Kanban — DevOps answers a different question (how software gets released and operated) and can layer on top of nearly any of the other models in this chapter.
3. Adopting Scrum's ceremonies without genuine engagement, producing exactly the "process theater" failure mode Chapter 1 introduced — ritual without the substance the ceremonies are meant to provide.
4. Applying Spiral's heavy, formal risk-analysis overhead to a typical, lower-stakes commercial project, or conversely, skipping formal risk analysis entirely on a genuinely high-stakes, high-uncertainty project where Spiral's discipline would have caught a major risk earlier.

Discussion / interview questions

1. "Is Waterfall always a worse choice than Agile methodologies?" Strong answer: No — Waterfall fits genuinely stable, well-understood-upfront requirements and heavy compliance/audit contexts well; its poor reputation comes from its mismatch with evolving-requirements software, which describes most commercial products, but that mismatch doesn't make it universally wrong for the contexts it actually fits.

2. "What's the difference between Scrum and Kanban, given both are considered 'Agile'?" Strong answer: Scrum organizes work into fixed-length sprints with defined ceremonies (planning, standups, review, retrospective); Kanban uses continuous flow with WIP limits and no fixed iteration boundaries — Scrum fits predictable, plannable work well; Kanban fits continuous, unpredictable-priority work (like support/maintenance) better.

3. "How does DevOps relate to the other SDLC models covered in this chapter?" Strong answer: DevOps isn't a stage-ordering model like Scrum or Waterfall — it's a cultural/technical practice (enabled by CI/CD automation) addressing how software moves from "done" to "running in production" and how tightly development and operations are integrated; it can layer on top of nearly any of the other models.

4. "When would the Spiral model's extra overhead (formal risk analysis every cycle) be worth it?" Strong answer: For large, high-uncertainty, high-stakes projects where an undiscovered major risk materializing late would be catastrophic (major government/defense systems, genuinely novel technical territory) — excessive overhead for a typical, lower-stakes commercial software project.

Chapter summary / cheat sheet

• Waterfall: sequential, stage-complete-before-next — fits stable requirements and heavy compliance needs; costly to change course.
• Iterative: repeats the full cycle at smaller scale, surfacing misunderstandings earlier than single-pass Waterfall.
• Scrum: fixed-length sprints with defined ceremonies (planning, standup, review, retrospective) — predictable rhythm, real ceremony overhead.
• Kanban: continuous flow with WIP limits, no fixed iterations — fits unpredictable, continuously-arriving work well.
• Lean: an "eliminate waste" lens applicable within any other model, not a complete standalone process.
• Spiral: iterative plus mandatory, formal risk analysis each cycle — fits large, high-uncertainty, high-stakes projects.
• DevOps/continuous delivery: a release/operations practice (not a planning-stage-ordering model) that layers on top of nearly any of the above, enabled by CI/CD automation.
• Every model is a genuinely reasonable choice in its right context — an honest comparison names the specific fit and specific cost of each, rather than declaring a universal winner.

---