Table of Contents

1. What is Waterfall
2. Philosophy and Core Principles
3. The Waterfall Phases
4. Roles and Responsibilities
5. Documentation and Deliverables
6. When to Use Waterfall
7. Alignment with AAA Cycle
8. Hybrid Approaches
9. Common Pitfalls and Red Flags

What is Waterfall

Formalized by Winston W. Royce in 1970 paper “Managing the Development of Large Software Systems.” Ironically, Royce actually argued against the pure waterfall approach in the same paper, but it became the dominant methodology for decades.

Waterfall is a sequential software development methodology where each phase must be completed before moving to the next. Progress flows in one direction (like a waterfall), with formal gates between phases.

Core Philosophy:

• Sequential, linear progression through phases
• Comprehensive upfront planning and requirements
• Extensive documentation at each phase
• Formal approval gates between phases
• Change is costly after requirements phase

Key Characteristics:

Sequential phases:

Requirements → Design → Implementation → Testing → Deployment → Maintenance

Each phase produces deliverables:

• Requirements phase → Requirements document
• Design phase → Design specifications
• Implementation phase → Source code
• Testing phase → Test reports
• Deployment phase → Deployed system

Formal gates:

• Phase cannot begin until previous phase complete
• Formal sign-off required to move forward
• Changes after sign-off require change control process

Why Waterfall Emerged

Historical context (1950s-1970s):

Waterfall emerged from manufacturing and construction industries:

• Building a bridge: Design everything upfront, changes expensive
• Manufacturing: Retooling production line costly
• Physical constraints make iteration impractical

Applied to software (1970s-2000s):

Early software development adopted this approach because:

• Software seen as similar to engineering disciplines
• Deployment was expensive (ship physical media)
• Changes required re-releasing products
• Tools primitive (no automated testing, deployment)
• Computing resources scarce (expensive to iterate)

Why it dominated:

• Management understood it (familiar from other industries)
• Predictable (plan everything upfront)
• Clear accountability (phase ownership)
• Extensive documentation (audit trail)

Historical Context

Royce’s original paper (1970):

Winston Royce described the waterfall model but warned against using it:

• “I believe in this concept, but the implementation described above is risky and invites failure.”
• Recommended iteration between phases
• Emphasized prototyping and customer involvement
• Suggested risk mitigation through incremental approaches

Despite warnings, waterfall became standard:

• Managers liked predictability
• Contractors liked fixed-bid projects
• Government and military standardized on it (DOD-STD-2167)
• Became dogma in many organizations

Waterfall’s decline (2000s-present):

Waterfall fell out of favor due to:

• High failure rates (projects over budget, late, wrong features)
• Inability to adapt to changing requirements
• Late discovery of problems (testing at end)
• Rise of Agile methodologies
• Internet era requires faster iteration

Modern context:

Waterfall still used in:

• Highly regulated industries (FDA, aerospace, defense)
• Hardware-software integration projects
• Projects with truly stable requirements
• Contractual obligations requiring waterfall
• Organizations with waterfall-mandated processes

Philosophy and Core Principles

Predictive Planning

What it means:

Plan the entire project upfront. Know requirements, design, timeline, and budget before starting development.

Traditional project management:

• Define scope completely (what will be built)
• Estimate effort and timeline (how long)
• Lock in budget (how much)
• Execute according to plan

Why this was valued:

• Management can make informed decisions
• Stakeholders know what they’re getting
• Budget and timeline predictable
• Risk theoretically reduced through planning

Reality:

• Requirements change during development
• Estimates often wrong (software complexity hard to estimate)
• Late discovery of issues (integration, performance)
• “Iron triangle” tension (scope, time, cost)

Comprehensive Documentation

What it means:

Extensive documentation at every phase. Documentation is primary deliverable, not just byproduct.

Types of documentation:

Requirements phase:

• Business requirements document (BRD)
• Functional requirements specification (FRS)
• Use cases and user stories
• Acceptance criteria

Design phase:

• System architecture document (SAD)
• Database design specifications
• Interface specifications (APIs, UI)
• Security design

Implementation phase:

• Code documentation (inline comments, API docs)
• Developer guides
• Technical specifications

Testing phase:

• Test plans and test cases
• Test reports and defect logs
• Traceability matrices

Deployment phase:

• Deployment guides
• Operations manuals
• Training materials
• Maintenance documentation

Why documentation emphasized:

• Knowledge transfer (people leave)
• Audit trail (compliance requirements)
• Contract fulfillment (deliverable proof)
• Future maintenance (understand system)

Downsides:

• Documentation becomes stale (not updated)
• Effort spent documenting instead of building
• Documents don’t capture tacit knowledge
• Over-documentation (nobody reads it)

Phase Gates and Sign-Offs

What it means:

Formal approval required to move to next phase. Each phase produces deliverables that stakeholders review and approve.

Phase gate process:

Phase Work → Deliverable Produced → Stakeholder Review → Sign-Off → Next Phase

Example: Requirements → Design gate:

• Requirements document produced
• Stakeholders review requirements
• Formal sign-off meeting
• Approval granted (or revisions requested)
• Design phase begins

Why gates exist:

• Ensure quality (catch issues before moving forward)
• Stakeholder alignment (everyone agrees on requirements)
• Accountability (sign-off creates commitment)
• Risk mitigation (don’t proceed with flawed requirements)

Downsides:

• Delays (waiting for approvals)
• False sense of security (sign-off doesn’t mean requirements correct)
• Change resistance (“we already signed off”)
• Blame shifting (“you approved it”)

Change Control

What it means:

Changes after requirements sign-off go through formal change control process. Changes are expensive and discouraged.

Change control process:

1. Change request submitted (what needs to change, why)
2. Impact analysis (effort, cost, schedule impact)
3. Change advisory board (CAB) reviews
4. Approval or rejection decision
5. If approved: Update documents, schedule, budget
6. Implementation

Why change control exists:

• Prevent scope creep (uncontrolled expansion)
• Manage expectations (stakeholders understand cost)
• Maintain traceability (document all changes)
• Protect budget and timeline

Downsides:

• Slow (weeks or months for approval)
• Discourages necessary changes
• Encourages “requirements padding” (ask for everything upfront)
• Adversarial (change seen as problem, not learning)

The Waterfall Phases

Phase 1: Requirements Gathering and Analysis

What happens:

Gather all requirements from stakeholders. Document everything the system must do.

Activities:

1. Stakeholder interviews

• Who will use the system?
• What problems does it solve?
• What features are needed?
• What are constraints?

2. Requirements documentation

• Business requirements (high-level objectives)
• Functional requirements (what system must do)
• Non-functional requirements (performance, security, usability)
• Constraints (budget, timeline, technology)

3. Requirements validation

• Review with stakeholders
• Ensure completeness (nothing missing)
• Resolve conflicts (contradictory requirements)
• Prioritize (must-have vs. nice-to-have)

Deliverables:

• Requirements specification document
• Use cases or user stories
• Acceptance criteria
• Traceability matrix

Duration: Typically 1-3 months depending on project size

Sign-off: Stakeholders formally approve requirements

Key challenge:

Stakeholders often don’t know what they want until they see it. Requirements gathered at this phase may be incomplete or wrong, but waterfall assumes they’re correct.

Phase 2: System Design

What happens:

Translate requirements into technical design. Define architecture, database schema, interfaces, and components.

Activities:

1. High-level design (architecture)

• System architecture (components, layers)
• Technology stack selection
• Integration points (APIs, databases)
• Security architecture
• Deployment architecture

2. Detailed design

• Database schema (tables, relationships, indexes)
• API specifications (endpoints, payloads)
• User interface mockups (screens, workflows)
• Component specifications (classes, modules)
• Algorithms and data structures

3. Design reviews

• Peer review by senior engineers
• Architecture review board
• Security review
• Performance analysis

Deliverables:

• System architecture document (SAD)
• Database design document
• Interface specifications
• UI/UX designs
• Technical specifications

Duration: Typically 1-3 months

Sign-off: Technical leadership and stakeholders approve design

Key challenge:

Design based on requirements that may be incomplete or misunderstood. Design decisions made without implementation feedback (may not work as planned).

Phase 3: Implementation (Development)

What happens:

Write code according to design specifications. Build the system.

Activities:

1. Coding

• Implement components per design
• Follow coding standards
• Write inline documentation
• Unit test individual components

2. Code reviews

• Peer review code
• Ensure adherence to design
• Check code quality
• Verify standards compliance

3. Integration

• Integrate components
• Build complete system
• Resolve integration issues
• Prepare for testing phase

Deliverables:

• Source code
• Code documentation
• Build scripts
• Developer guides

Duration: Typically 3-12 months depending on project size

Sign-off: Code complete, ready for testing

Key challenge:

Developers often discover design flaws during implementation. In waterfall, going back to design phase is expensive and discouraged. Result: Workarounds and technical debt.

Phase 4: Testing and Quality Assurance

What happens:

Verify the system works according to requirements. Find and fix defects.

Activities:

1. Test planning

• Define test strategy
• Create test plans
• Write test cases (based on requirements)
• Prepare test environments

2. Testing execution

• Unit testing: Individual components
• Integration testing: Components working together
• System testing: Entire system
• User acceptance testing (UAT): Stakeholders validate

3. Defect management

• Log defects found
• Prioritize defects (severity, impact)
• Fix defects
• Retest after fixes

Deliverables:

• Test plans and test cases
• Test execution reports
• Defect logs and resolution
• UAT sign-off

Duration: Typically 1-3 months

Sign-off: Stakeholders accept system (UAT passed)

Key challenge:

Testing at the end means late discovery of issues. Integration problems, performance issues, and fundamental design flaws discovered here are expensive to fix. Pressure to accept defects due to timeline.

Phase 5: Deployment

What happens:

Deploy system to production. Make it available to users.

Activities:

1. Deployment planning

• Deployment strategy (big bang, phased, parallel)
• Rollback plan
• Training plan
• Communication plan

2. Deployment execution

• Data migration (if applicable)
• System installation and configuration
• User training
• Go-live

3. Cutover

• Switch from old system to new
• Monitor closely
• Support users
• Address issues

Deliverables:

• Deployed system
• Deployment report
• Training materials
• Operations documentation

Duration: Days to weeks

Sign-off: System in production, users trained

Key challenge:

“Big bang” deployment is high risk. Issues discovered after deployment affect all users. Rollback may not be feasible if data has been migrated.

Phase 6: Maintenance and Support

What happens:

Fix bugs, make minor changes, support users.

Activities:

1. Bug fixes

• Users report issues
• Developers fix bugs
• Deploy patches

2. Minor enhancements

• Small changes and improvements
• Governed by change control

3. Support

• Help desk support
• User questions
• System monitoring

Duration: Ongoing (years)

Key challenge:

Most of software’s total cost is maintenance (60-90%). Waterfall projects often under-budget maintenance. Changes expensive due to lack of automated tests and rigid architecture.

Roles and Responsibilities

Project Manager

Responsibilities:

• Create project plan (timeline, milestones, budget)
• Track progress against plan
• Manage resources (people, budget)
• Report status to stakeholders
• Manage risks and issues
• Enforce phase gates

Key artifacts:

• Project plan (Gantt chart, timeline)
• Status reports
• Risk register
• Issue log

Business Analyst

Responsibilities:

• Gather requirements from stakeholders
• Document requirements
• Validate requirements
• Manage requirements changes
• Bridge business and technical teams

Key artifacts:

• Business requirements document (BRD)
• Functional requirements specification (FRS)
• Use cases
• Requirements traceability matrix

System Architect / Technical Lead

Responsibilities:

• Design system architecture
• Make technology decisions
• Review technical designs
• Ensure design meets requirements
• Guide development team

Key artifacts:

• System architecture document (SAD)
• Technical specifications
• Design diagrams
• Technology selection rationale

Developers

Responsibilities:

• Implement design
• Write code per specifications
• Unit test code
• Document code
• Participate in code reviews

Key artifacts:

• Source code
• Unit tests
• Code documentation
• Developer notes

QA / Testers

Responsibilities:

• Create test plans and test cases
• Execute tests
• Log defects
• Verify fixes
• Conduct user acceptance testing

Key artifacts:

• Test plans
• Test cases
• Test execution reports
• Defect logs
• UAT sign-off

Stakeholders / Product Owner

Responsibilities:

• Define requirements
• Provide business context
• Review and approve deliverables
• Participate in UAT
• Accept final system

Key artifacts:

• Requirements sign-off
• Design approval
• UAT acceptance
• Final sign-off

Documentation and Deliverables

Required Documentation

1. Project Charter

• Project objectives and scope
• Stakeholders and roles
• High-level timeline and budget
• Success criteria

2. Requirements Specification

• Business requirements
• Functional requirements
• Non-functional requirements (architectural characteristics)
• Constraints and assumptions
• Acceptance criteria

3. System Architecture Document

• Architecture overview
• Component descriptions
• Technology stack
• Integration points
• Security architecture
• Deployment architecture

4. Detailed Design Specifications

• Database schema
• API specifications
• UI mockups and workflows
• Component designs
• Algorithms and data structures

5. Test Documentation

• Test strategy and approach
• Test plans (unit, integration, system, UAT)
• Test cases (linked to requirements)
• Test reports and metrics
• Defect logs

6. Deployment Documentation

• Deployment plan
• Installation guides
• Configuration guides
• Training materials
• Operations manuals

7. Maintenance Documentation

• System maintenance guide
• Troubleshooting guide
• Known issues and workarounds
• Change log

When to Use Waterfall

Waterfall Works Well For:

1. Highly regulated industries

FDA (medical devices):

• Extensive documentation required for approval
• Design history file (DHF) mandatory
• Validation and verification required
• Changes require regulatory approval

Aerospace and defense:

• Safety-critical systems
• Government contracts require waterfall
• Extensive testing and documentation
• Formal verification required

Financial services (some contexts):

• Regulatory compliance requirements
• Audit trails essential
• Formal change control processes

Why: Regulatory bodies require comprehensive documentation and formal processes that waterfall provides.

2. Fixed-scope, fixed-bid contracts

What it looks like:

• Client specifies exact requirements upfront
• Contract defines deliverables, timeline, cost
• Contractor builds to specification
• Changes require contract amendments

Why waterfall fits:

• Clear scope definition (what will be delivered)
• Predictable timeline and cost (bid accurately)
• Formal change control (protect margins)
• Documentation proves contract fulfillment

Examples:

• Government RFPs (request for proposals)
• Enterprise software implementations
• System integrations with defined interfaces

3. Hardware-software integration projects

Why waterfall fits:

• Hardware changes expensive (can’t iterate easily)
• Must define interfaces upfront
• Parallel development (hardware and software)
• Integration happens late (physical constraints)

Examples:

• Embedded systems (automotive, industrial)
• Medical devices
• Aerospace systems
• IoT devices

4. Projects with truly stable requirements

Rare but exists:

• Replacing existing system with known requirements
• Implementing established standards (compliance)
• Migrating data with defined schemas
• Building to existing specifications

Why waterfall works:

• Requirements won’t change
• No learning through iteration needed
• Extensive planning makes sense
• Predictability valued over flexibility

5. Organizations with waterfall mandates

Reality:

• Some organizations require waterfall
• Government agencies
• Large enterprises with established processes
• Contractual obligations

Strategy:

• Hybrid approaches (waterfall wrapper, agile inside)
• Agile-within-waterfall increments
• Documented agile (satisfy documentation needs)

Waterfall Does NOT Work Well For:

1. Projects with evolving requirements

Why waterfall fails:

• Requirements locked in early
• Change control discourages adaptation
• Late discovery that requirements wrong
• Expensive to change direction

Better approach: Agile methodologies (Scrum, Kanban, XP)

2. Innovative or exploratory projects

Why waterfall fails:

• Don’t know what to build upfront
• Learning happens through building
• Requirements emerge from experimentation
• Need flexibility to pivot

Better approach: Lean Startup, Shape Up, XP

3. Software-only projects (no hardware constraints)

Why waterfall unnecessary:

• Software is malleable (easy to change)
• Deployment easy and cheap (cloud, CI/CD)
• Feedback fast (users can test immediately)
• Iteration beneficial (learn and improve)

Better approach: Agile methodologies

4. Fast-moving markets

Why waterfall fails:

• Long planning cycles (months)
• Competitor moves faster
• Market changes before delivery
• Customer needs evolve

Better approach: Lean, Kanban, continuous delivery

5. Startups and product development

Why waterfall fails:

• Unknown product-market fit
• Need to experiment and learn
• Resources constrained (can’t afford waterfall overhead)
• Speed to market critical

Better approach: Lean Startup, Shape Up

Alignment with AAA Cycle

Waterfall’s sequential structure creates fundamental tensions with the AAA discipline, though some phases naturally support AAA principles.

How Waterfall Can Support AAA

Align Phase: Requirements Gathering

Waterfall’s extensive requirements phase can support alignment:

What works:

• Dedicated time for stakeholder interviews
• Documentation forces explicit communication
• Requirements review ensures shared understanding
• Sign-off gates prevent proceeding with misalignment

What’s needed:

• Requirements discovery, not just requirements capture
• Testing assumptions during requirements phase
• Iterative refinement within requirements phase
• Prototyping to validate understanding

Example: Enterprise system for financial services. Waterfall requires 3-month requirements phase. Team uses time well: interviews stakeholders, builds mockups, validates regulatory requirements, tests assumptions with prototypes. Requirements document reflects genuine alignment, not just wishful thinking.

Agree Phase: Design Sign-Off

Design phase can establish clear agreements:

What works:

• Detailed specifications document what will be built
• Formal review and approval process
• Clear scope boundaries
• Written record of agreements

What’s needed:

• Agreement on outcomes, not just technical specs
• Success criteria beyond “built per spec”
• Explicit acceptance criteria
• Change control process that allows realignment

Example: Design specifies database schema, API contracts, UI wireframes. Stakeholders review and approve. Team has clear agreement on what “done” means. However, agreement includes provision: if implementation reveals design flaws, team will pause and realign rather than blindly following flawed spec.

Apply Phase: Implementation and Testing

Waterfall’s implementation phase can apply agreements:

What works:

• Build what was agreed in design phase
• Testing validates implementation matches specification
• Formal acceptance criteria
• Traceability from requirements to implementation

What’s needed:

• Quality is part of agreement, not afterthought
• Pause mechanism when discovery invalidates design
• Testing throughout, not just testing phase
• Continuous stakeholder visibility

Example: Implementation follows design specifications. Testing validates each component. However, team discovers security vulnerability in architectural approach. Rather than proceeding to meet schedule, team pauses, realigns with stakeholders on security requirements, updates design, continues. Honors true agreement (secure system) not just documented agreement (original design).

Where Waterfall Fundamentally Conflicts with AAA

Conflict 1: Late discovery, costly realignment

Problem:

• Requirements frozen before implementation begins
• Design approved before code written
• Learning happens during implementation (too late)
• Change is expensive and discouraged

AAA requires:

• Continuous realignment as understanding evolves
• Discovery throughout the process
• Easy adaptation based on learning
• Realignment is expected, not exceptional

Why waterfall fails here: Waterfall’s entire philosophy assumes you can know everything upfront. Phase gates prevent easy realignment. By the time you learn critical information (during implementation), you’ve already committed to requirements and design. Realignment requires formal change requests, re-approval, schedule delays.

No real reconciliation: This is fundamental tension. If your project allows late discovery and requires easy realignment, waterfall is wrong methodology. Use iterative approach.

Conflict 2: Agreement becomes contract, not shared commitment

Problem:

• Requirements document becomes legal artifact
• Changes trigger blame (“you signed off on this”)
• Stakeholders disengage after sign-off
• Focus on contract compliance, not outcomes

AAA requires:

• Agreement based on shared understanding
• Continuous stakeholder engagement
• Focus on outcomes, not compliance
• Realignment when learning demands it

Why waterfall fails here: Waterfall documents create false sense of certainty. Stakeholders sign off thinking “we’re done with requirements.” Team builds to spec thinking “we have approval.” When reality differs from plan, focus becomes “who approved this?” not “what should we do now?”

Partial reconciliation: Include explicit clause in waterfall contracts: “This specification represents our current understanding. We will pause and realign if implementation reveals fundamentally different reality.” Make realignment process lightweight. Keep stakeholders engaged throughout implementation.

Conflict 3: Testing phase discovers problems too late

Problem:

• Testing happens after implementation complete
• Integration issues discovered late
• User acceptance at end of process
• No opportunity to adjust based on feedback

AAA requires:

• Continuous validation of understanding
• Testing assumptions early
• Stakeholder feedback throughout
• Course correction before significant investment

Why waterfall fails here: Separating testing from implementation means you build for months without validating. By testing phase, you’ve invested heavily in potentially wrong solution. User acceptance testing at the end means users see product for first time when it’s “done.” Too late for meaningful course correction.

Partial reconciliation:

• Prototype during requirements phase (test usability assumptions)
• Incremental development within implementation phase
• Continuous integration and automated testing
• Stakeholder demos during implementation (not just at end)

This is basically “waterfall with agile practices” - see Hybrid Approaches below.

Conflict 4: Sequential phases prevent parallel learning

Problem:

• Can’t start design until requirements complete
• Can’t start implementation until design complete
• Learning from implementation can’t inform design
• No feedback loops between phases

AAA requires:

• Iterative refinement
• Learning informs earlier decisions
• Parallel exploration of design and implementation
• Feedback loops throughout

Why waterfall fails here: Waterfall assumes linear progression: understand → design → build. Reality: building teaches you what you need, design reveals requirement gaps, implementation exposes design flaws. Sequential phases prevent this natural learning.

No real reconciliation: This is fundamental to waterfall. If your project benefits from parallel learning and feedback loops, use iterative methodology. Waterfall appropriate only when learning can genuinely happen sequentially.

When Waterfall Supports AAA (Rarely)

Waterfall can support AAA in very specific contexts:

1. Truly stable, well-understood requirements

If requirements genuinely won’t change (regulatory compliance, hardware constraints), waterfall’s upfront alignment makes sense. Extensive requirements phase ensures genuine alignment before commitment.

Example: Medical device software with fixed FDA requirements. Requirements are regulatory, not exploratory. Alignment means understanding regulations, not discovering user needs.

2. High cost of change encourages quality alignment

When changing course is extremely expensive (manufacturing dependencies, contractual obligations), waterfall forces quality alignment upfront. Better to spend 3 months on requirements than discover misalignment after 2 years of development.

Example: Spacecraft software. Can’t iterate after launch. Waterfall’s extensive upfront work (requirements, design, testing) ensures genuine alignment and agreement before irreversible commitment.

3. Distributed teams with limited communication

When real-time collaboration is difficult (extreme time zones, security constraints), comprehensive documentation supports asynchronous alignment. Requirements and design documents establish shared understanding without requiring continuous interaction.

Example: Defense contractor with distributed teams across multiple security domains. Face-to-face alignment difficult. Comprehensive documentation and formal reviews establish alignment.

Key Insight: Waterfall Works When Learning is Expensive

Waterfall supports AAA when:

• Cost of realignment is higher than cost of upfront alignment
• Learning can genuinely happen sequentially
• Requirements are stable and well-understood
• Changes are more expensive than extensive planning

Waterfall conflicts with AAA when:

• Learning happens during implementation (most software)
• Requirements emerge through building
• Rapid feedback and course correction needed
• Discovery reveals fundamentally different reality

For most modern software development, these conflicts make waterfall a poor fit with AAA. Use iterative methodologies (Lean, Kanban, Shape Up) that embrace continuous realignment.

Hybrid Approaches

Many organizations use hybrid approaches combining waterfall structure with agile practices.

Waterfall with Agile Phases

Structure:

• Requirements phase: Waterfall (comprehensive upfront)
• Design phase: Waterfall (architecture defined)
• Implementation phase: Agile sprints
• Testing phase: Continuous (integrated with sprints)
• Deployment phase: Waterfall (formal release)

Why this works:

• Architecture stable (defined upfront)
• Implementation flexible (sprints allow iteration)
• Satisfies stakeholders expecting waterfall
• Teams get benefits of agile

Challenges:

• Requirements still locked early
• Architecture may not support emerging needs
• Testing still somewhat late

Incremental Waterfall

Structure:

Break project into increments, each following waterfall:

Increment 1: Requirements → Design → Implement → Test → Deploy
Increment 2: Requirements → Design → Implement → Test → Deploy
Increment 3: Requirements → Design → Implement → Test → Deploy

Why this works:

• Reduces risk (smaller increments)
• Delivers value earlier (not waiting for entire project)
• Allows some learning between increments
• Still satisfies waterfall documentation needs

Challenges:

• Each increment still sequential
• Changes between increments difficult
• Integration challenges

Documented Agile

Structure:

• Work using Agile methodology (Scrum, XP)
• Produce waterfall documentation artifacts
• Map agile ceremonies to waterfall gates

Why this works:

• Team gets agile benefits (iteration, feedback)
• Organization gets documentation (compliance, audit)
• Satisfies stakeholders expecting waterfall artifacts

Challenges:

• Documentation overhead
• Tension between agile values and waterfall requirements
• Risk of “agile theater” (documentation without agility)

Water-Scrum-Fall

Structure:

• Water-fall: Requirements phase (traditional waterfall)
• Scrum: Development phase (agile sprints)
• Water-fall: Deployment and operations (traditional waterfall)

Why organizations do this:

• Business comfortable with waterfall planning
• Development team wants to work agile
• Operations wants formal deployments

Why it’s problematic:

• Not truly agile (requirements still locked early)
• Handoffs between phases (silos)
• Testing and deployment still late
• Known anti-pattern (coined pejoratively)

Better approach:

• Full agile adoption (DevOps for deployment)
• Or acknowledge it’s waterfall with sprints

Common Pitfalls and Red Flags

Pitfall 1: Late Discovery of Fundamental Issues

Problem:

Critical issues discovered in testing phase when expensive to fix.

What happens:

• Requirements misunderstood (built wrong thing)
• Design flaws (doesn’t scale, doesn’t work)
• Integration problems (components don’t work together)
• Performance issues (too slow, doesn’t handle load)

Why it happens:

• No working software until late
• Testing happens after implementation complete
• Integration happens late
• No feedback loops during development

Cost impact:

Cost of fixing defect:

• Requirements phase: 1x
• Design phase: 5x
• Implementation: 10x
• Testing: 20x
• Production: 100x

How to avoid:

• Prototyping during requirements/design
• Early integration (continuous integration)
• Incremental delivery (reduce batch size)
• Feedback loops throughout (not just at end)

Red flags:

• First integration in testing phase
• No prototypes or proof-of-concepts
• “Big bang” integration
• Stakeholders see nothing until UAT

Pitfall 2: Requirements Churn and Scope Creep

Problem:

Requirements change during project but waterfall resists change.

What happens:

Scenario 1: Change control prevents necessary changes

• Market shifts, competitors launch features
• Change request denied (expensive, timeline impact)
• Project delivers to obsolete requirements
• Result: Wasted effort

Scenario 2: Changes made anyway (scope creep)

• Changes made without formal process
• Timeline and budget impacted
• Blame game (“requirements weren’t clear”)
• Result: Over budget, late, contentious

Why it happens:

• Requirements unknowable upfront
• Business context changes during project
• Stakeholders learn what they want by seeing product
• Long project timelines (9-18 months)

How to avoid:

• Shorter project timelines (incremental)
• Accept that requirements will evolve
• Build flexibility into plan
• Agile methodologies embrace change

Red flags:

• Requirements locked for 12+ months
• No mechanism for change
• “Requirements are final” mentality
• Stakeholders afraid to ask for changes

Pitfall 3: Over-Emphasis on Documentation

Problem:

Effort spent on documentation instead of working software.

What happens:

• Months spent on requirements documents
• Design documents 100+ pages
• Documents don’t capture tacit knowledge
• Documents become stale (not updated)
• Nobody reads documents

Why it happens:

• Documentation seen as deliverable (contract fulfillment)
• “Cover your ass” culture (document everything)
• Mistaken belief documentation = understanding
• Phase gates require documentation

How to avoid:

• Document what’s valuable (decisions, rationale)
• Working software over comprehensive documentation (Agile value)
• Living documentation (code, tests, runbooks)
• Just-enough documentation

Red flags:

• Requirements document 200+ pages
• Weeks spent formatting documents
• Documents not read or used
• Documentation for documentation’s sake

Pitfall 4: Artificial Phase Boundaries

Problem:

Rigid phase gates prevent natural overlap and iteration.

What happens:

• Design can’t start until requirements 100% complete
• Implementation can’t start until design 100% complete
• Idle time waiting for phase gates
• No learning between phases

Why it’s problematic:

In reality:

• Requirements inform design
• Design informs requirements
• Implementation reveals design issues
• Testing reveals requirement gaps

Artificial boundaries prevent this learning.

How to avoid:

• Allow overlap between phases
• Iterate within and between phases
• Feedback loops from later phases to earlier
• Incremental delivery

Red flags:

• Teams idle waiting for phase gate
• No overlap between phases
• “Throw it over the wall” handoffs
• No iteration or feedback

Pitfall 5: Optimism Bias in Estimates

Problem:

Estimates made with incomplete information turn out wrong.

What happens:

• Requirements phase: Estimate entire project
• Based on incomplete understanding
• Complexity underestimated
• Contingency insufficient
• Result: Over budget, late

Why it happens:

• Pressure to provide estimate early
• Unknown unknowns (don’t know what you don’t know)
• Optimism bias (underestimate complexity)
• Political pressure (management wants low estimate)

Reality of software estimation:

• Cone of uncertainty (estimates improve with information)
• Early estimates have 4x variance (25% to 400% of estimate)
• Estimation improves as project progresses
• But waterfall needs estimate upfront

How to avoid:

• Ranges, not point estimates (50% to 150% confidence)
• Contingency based on uncertainty
• Re-estimate as information improves
• Empirical data (velocity) over speculation

Red flags:

• Point estimates required before design
• No contingency or ranges
• Estimates not updated as learning occurs
• “We need a number” pressure

Pitfall 6: Testing as Afterthought

Problem:

Testing phase at end means late discovery of issues and pressure to accept defects.

What happens:

• Testing starts after development complete
• Defects found late (expensive to fix)
• Timeline pressure (launch date approaching)
• Pressure to accept known defects
• Result: Poor quality or delayed launch

Why it happens:

• Waterfall structure (testing is a phase, not continuous)
• No automated tests (manual testing slow)
• Integration happens late
• QA seen as separate from development

How to avoid:

• Test continuously (not phase at end)
• Automated testing (TDD, CI)
• Quality built in (XP practices)
• Developers own quality

Red flags:

• No testing until “testing phase”
• No automated tests
• QA team discovers defects, not developers
• Pressure to “accept” known defects for launch

Pitfall 7: “Requirements Were Approved” Blame Game

Problem:

When project fails, blame shifts to “requirements were signed off.”

What happens:

• Project delivers to requirements
• But requirements were wrong or incomplete
• Stakeholders: “This isn’t what we wanted”
• Project team: “But you approved requirements”
• Result: Finger-pointing, wasted effort, damaged relationships

Why it happens:

• Requirements unknowable upfront
• Sign-off seen as contract (absolves responsibility)
• Stakeholders don’t understand requirements until seeing product
• No collaboration after requirements phase

Reality:

Sign-off doesn’t mean:

• Requirements are correct
• Stakeholders understand fully
• Product will meet needs

Sign-off means:

• “This is our best understanding now”
• Should evolve as learning occurs

How to avoid:

• Continuous stakeholder involvement (not just requirements phase)
• Accept requirements will evolve
• Prototypes and MVPs for validation
• Agile methodologies (collaboration over sign-offs)

Red flags:

• “You signed off” used as defense
• Stakeholders surprised at demo
• No involvement after requirements phase
• Adversarial relationship

Pitfall 8: Death March

Problem:

Project behind schedule, team works unsustainable hours trying to catch up.

What happens:

• Project late (optimistic estimates)
• Management pressure to deliver on time
• Team works nights and weekends
• Quality suffers, burnout occurs
• Result: Poor quality, staff turnover, project failure

Why it happens:

• Unrealistic timeline (optimistic estimates)
• Scope creep (changes not managed)
• Late discovery of issues
• “Fixed date” mentality (can’t slip)

How to avoid:

• Realistic estimates with contingency
• Incremental delivery (reduce risk)
• Sustainable pace (XP value)
• Negotiate scope, not hours

Red flags:

• Regular overtime
• “Crunch time” for weeks/months
• Burnout and turnover
• Quality declining

Red Flags Summary

Process red flags:

• Requirements locked for 12+ months
• First integration in testing phase
• Documentation for documentation’s sake
• Rigid phase boundaries (no overlap)

Estimation red flags:

• Point estimates before design
• No ranges or contingency
• Estimates never updated
• Optimistic timelines

Quality red flags:

• Testing only at end
• No automated tests
• Pressure to accept defects
• QA separate from development

Cultural red flags:

• Blame culture (“you approved it”)
• Death march (unsustainable pace)
• Adversarial relationships
• No collaboration after requirements

Key Takeaways

Waterfall is sequential, documentation-heavy methodology:

• Six phases: Requirements, Design, Implementation, Testing, Deployment, Maintenance
• Each phase produces deliverables and requires sign-off
• Change expensive after requirements phase
• Predictive planning (plan everything upfront)

Waterfall works in specific contexts:

• Highly regulated industries (FDA, aerospace, defense)
• Fixed-scope, fixed-bid contracts
• Hardware-software integration
• Truly stable requirements (rare)
• Organizations with waterfall mandates

Waterfall doesn’t work for:

• Evolving requirements (most software projects)
• Innovative/exploratory projects
• Software-only projects (no hardware constraints)
• Fast-moving markets
• Startups and product development

Common pitfalls:

• Late discovery of fundamental issues (testing at end)
• Requirements churn and scope creep
• Over-emphasis on documentation
• Artificial phase boundaries
• Optimism bias in estimates
• Testing as afterthought
• Blame game (“you approved requirements”)
• Death march (unsustainable pace)

Modern alternatives:

• Agile methodologies (Scrum, Kanban, XP) for most software
• Hybrid approaches when waterfall required
• Incremental delivery to reduce risk
• Continuous feedback throughout

Historical note:

Even Royce (who formalized waterfall) warned against using it. Waterfall became dominant despite its flaws. Modern software development has largely moved past waterfall except where regulatory or contractual constraints require it.

If you must use waterfall:

• Keep phases short (incremental waterfall)
• Allow overlap between phases
• Prototype to validate requirements
• Continuous integration (not “big bang”)
• Just-enough documentation (not excessive)
• Build in contingency (estimates will be wrong)
• Maintain stakeholder involvement throughout