Flexibility vs. Concrete: Agile/Scrum vs. Waterfall

There are two dominant philosophies for organising the SDLC. One builds a complete blueprint before pouring a single drop of concrete. The other builds a room at a time, shows it to the client, and adjusts based on feedback. Understanding both is essential — not just for interviews, but for understanding why your team makes the decisions it does.

Learning Objectives

By the end of this lesson you will be able to:

• Describe the Waterfall methodology and its key characteristics
• Describe the Agile philosophy and the Scrum framework
• Compare the two methodologies across key dimensions: flexibility, client involvement, and risk
• Explain how QA's role changes between Waterfall and Agile

Waterfall — Build It All, Then Show It

Waterfall is the original approach to software development. Like constructing a building, it follows a strict sequence: each phase must be fully complete before the next begins.

Requirements → Design → Development → Testing → Deployment → Maintenance
       ↓              ↓              ↓           ↓              ↓
    Complete       Complete       Complete    Complete      Complete
   before next    before next   before next  before next

Key characteristics:

• Requirements are defined completely upfront and rarely change
• The client signs off on requirements at the beginning and doesn't see the product until the end
• Each phase produces documentation that feeds the next
• Testing happens as a single phase after all development is complete

When Waterfall works:

• Projects with fixed, well-understood requirements (e.g., building a regulated financial system with strict specifications)
• Hardware-dependent projects where changing direction mid-build is physically costly
• Government contracts with fixed scope and deliverables

The big problem: The client sees working software for the first time after 6–18 months of work. If their needs changed in that time (and they always do), the entire product may be wrong. Testing is compressed into one phase at the end, making it expensive and high-pressure.

The Waterfall QA experience: Imagine being handed 18 months of development to test in 6 weeks. All bugs discovered now require rework of code that was written months ago. This is the Waterfall testing phase.

Agile — Build a Little, Learn a Lot, Repeat

Agile is a set of values and principles (codified in the Agile Manifesto), not a specific process. Its core insight is this: in complex projects, requirements will change. Build for adaptability.

Four Agile values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Agile doesn't mean "no plan." It means shorter planning cycles with frequent checkpoints, so reality can correct the course.

Scrum — Agile in Practice

Scrum is the most popular Agile framework. You met its ceremonies in the previous lesson. Here's how it implements Agile values:

The Scrum cycle:

Product Backlog
      ↓
Sprint Planning (select 2-week scope)
      ↓
Sprint (Daily Standups)
      ↓
Working, tested increment  ← THIS is what you deliver every sprint
      ↓
Sprint Review + Retrospective
      ↓
(back to backlog with new priorities)

Key Scrum ceremonies you now know:

Head-to-Head Comparison

QA in Waterfall vs. Agile

Waterfall QA:

• Works from comprehensive requirements documents written months ago
• Has a defined, time-boxed testing phase
• Must test an entire system's worth of features in limited time
• Defects found late are extremely expensive to fix

Agile QA:

• Involved from day one: refines requirements, reviews designs, pairs with developers
• Tests a small slice of functionality each sprint
• Defects found within the sprint they were created — cheap to fix
• Contributes to regression testing coverage continuously

The difference is between being a gatekeeper at the end and being a quality partner throughout. Agile teams that use QA effectively catch bugs before they're built. That's the goal.

A Note on Real-World Teams

Most teams today describe themselves as "Agile" but practise something in between. They might use Jira (Agile tooling) but have waterfall-style long planning horizons. Or they might run sprints but rarely do retrospectives. This hybrid reality is sometimes called ScrumBut ("We do Scrum, but we don't do retrospectives...").

Your job as a QA engineer is to advocate for the practices that improve quality — regardless of what the team calls its methodology.

Summary

Next lesson: you'll see exactly how QA maps onto every phase of the SDLC — regardless of methodology.