What is the waterfall methodology?
Waterfall is a sequential, phase-based project management methodology where each phase must be completed before the next begins. The canonical waterfall sequence is: requirements gathering, system design, implementation, testing, deployment, and maintenance. Each phase produces deliverables that become the input for the next phase, and progressing to the next phase implies that the current phase is complete and approved.
Waterfall originated in manufacturing and construction, where changing the design after pouring the foundation is catastrophically expensive. The methodology was adapted to software development in the 1970s and was the dominant approach for decades. Its core assumption is that requirements can be fully understood and documented before any code is written - and that the cost of changing requirements increases exponentially the later in the process you are.
In waterfall, the project manager's primary job is maintaining the plan. Gantt charts track dependencies between phases, milestones mark phase completions, and change requests follow a formal process that evaluates impact on schedule and budget. The emphasis is on documentation, predictability, and control.
Strengths of waterfall
- Predictable timeline. When requirements are stable and the work is well-understood, waterfall produces reliable delivery estimates. Each phase has a defined duration, and the total project timeline is the sum of phases plus buffer.
- Clear accountability. Phase gates create natural checkpoints where stakeholders review and approve work. There is no ambiguity about what has been completed and what remains.
- Thorough documentation. Because each phase requires documentation before proceeding, waterfall projects produce comprehensive specs, design docs, and test plans. This is valuable for compliance, regulatory audits, and onboarding new team members.
- Stakeholder alignment. Non-technical stakeholders often prefer waterfall because it maps to their mental model of projects: plan it, build it, ship it. The language of phases and milestones is intuitive.
Weaknesses of waterfall
- Late feedback. Users and stakeholders do not see working software until the testing or deployment phase - often months after the project started. If the requirements were misunderstood, the discovery happens too late to course-correct cheaply.
- Change resistance. Changing requirements mid-project means revisiting previous phases. A requirement change discovered during testing may require reworking the design and reimplementing features, cascading through the timeline.
- Integration risk. Components built in isolation during the implementation phase may not work together. Integration testing at the end of the build phase regularly surfaces architectural problems that were invisible during design.
- False precision. Detailed upfront estimates for novel software work are often wrong by 2x to 5x. Waterfall treats these estimates as commitments, creating a gap between the plan and reality that widens throughout the project.
What is agile?
Agile is a family of iterative, incremental methodologies that prioritize working software, customer collaboration, and responding to change over comprehensive documentation and rigid planning. The term encompasses multiple frameworks - scrum, kanban, XP (Extreme Programming), SAFe - united by a shared philosophy articulated in the Agile Manifesto.
The core agile insight is that software requirements are inherently unstable. Users do not know what they want until they see a working version. Technology constraints are not fully understood until you start building. Market conditions change while you are developing. Therefore, the most effective approach is to deliver small increments of working software frequently, gather feedback, and adapt the plan continuously.
Agile in practice: scrum and kanban
The two most widely adopted agile implementations are scrum and kanban.
Scrum organizes work into fixed-length sprints (one to two weeks) with four prescribed ceremonies: sprint planning, daily standup, sprint review, and retrospective. It defines three roles: Product Owner (prioritizes the backlog), Scrum Master (facilitates the process), and Development Team (builds the increment). Scrum's strength is cadence - it creates a regular rhythm of planning, building, and reflecting that keeps the team aligned.
Kanban takes a lighter approach: continuous flow, no sprints, no prescribed roles, no required meetings. Work is managed through WIP limits and visual board management. Kanban's strength is flexibility - it starts with your current workflow and improves it incrementally without imposing a new structure. For a deep dive into kanban principles and setup, see our kanban methodology guide.
Strengths of agile
- Early feedback. Working software is delivered every one to two weeks (scrum) or continuously (kanban). Stakeholders see real progress and can redirect before significant investment is wasted on the wrong thing.
- Adaptability. Changing requirements are expected, not punished. The backlog is reprioritized regularly, and the team always works on the most valuable item available.
- Reduced integration risk. Small, frequent deliveries mean continuous integration. Architectural problems surface immediately, not at the end of a six-month build phase.
- Team autonomy. Agile teams are self-organizing. Developers pull work based on capacity and expertise rather than being assigned tasks by a project manager. This increases ownership and job satisfaction.
Weaknesses of agile
- Difficult to estimate long-term. Because scope evolves continuously, predicting when a large initiative will be complete is harder. Agile gives you accurate short-term forecasts (this sprint) but fuzzy long-term ones (this quarter).
- Ceremony overhead (scrum). Four meetings per sprint consume meaningful engineering time. For small teams (two to four people), the overhead-to-work ratio can be unfavorable.
- Requires discipline. Agile without discipline becomes chaos - no planning, no tracking, just a backlog that grows unbounded and a team that works on whatever feels interesting. The methodology requires active backlog management, regular reflection, and process enforcement.
- Stakeholder frustration. Executives trained in waterfall find agile's lack of fixed milestones and long-range commitments uncomfortable. Managing this expectation gap is a real organizational challenge.
How do agile and waterfall compare side-by-side?
| Dimension | Waterfall | Agile |
|---|---|---|
| Planning | Comprehensive upfront | Incremental, continuous |
| Requirements | Fixed at project start | Evolve throughout |
| Delivery | One release at project end | Frequent increments |
| Feedback timing | Late (testing/deploy phase) | Early (every 1-2 weeks) |
| Change cost | High (rework previous phases) | Low (reprioritize backlog) |
| Documentation | Extensive, required per phase | Lightweight, as needed |
| Team structure | Role-based, hierarchical | Cross-functional, self-organizing |
| Risk profile | Back-loaded (late discovery) | Front-loaded (early discovery) |
| Best for | Stable requirements, regulated | Evolving requirements, competitive |
When does waterfall make sense?
Despite agile's dominance in software, waterfall remains the right choice in specific contexts:
- Regulated industries. Medical device software (FDA 510(k)), defense systems (DO-178C), and financial compliance systems often require formal phase-gate reviews with documented evidence of completeness at each stage. Agile can work in these environments, but it requires significant adaptation to satisfy regulatory auditors who expect waterfall artifacts.
- Fixed-scope contracts. When a client contract specifies exact deliverables, acceptance criteria, and a delivery date, the project is inherently waterfall-shaped. Scope changes trigger formal change orders with cost and timeline impact assessments.
- Hardware-coupled software. When software must ship with physical hardware (embedded systems, IoT devices, manufacturing equipment), the hardware timeline constrains the software timeline. You cannot iterate on firmware after the circuit board is manufactured.
- Well-understood, repeatable projects. If your team has built the same type of system multiple times (CRM implementations, ERP configurations, standard e-commerce builds), the requirements are known and waterfall's predictability is a genuine advantage.
When does agile win?
Agile outperforms waterfall whenever one or more of these conditions exist:
- Evolving requirements. If stakeholders are still discovering what they need - which is nearly always the case for new products, startups, and market-facing software - agile's iterative approach prevents building the wrong thing for six months.
- Competitive markets. Speed to market matters more than comprehensive planning. Shipping a minimum viable feature in two weeks beats shipping a perfect feature in six months when competitors are iterating weekly.
- Continuous deployment. If your infrastructure supports multiple deployments per day, batching delivery into quarterly releases wastes your deployment capability. Agile (particularly kanban) lets you ship as fast as your pipeline allows.
- Cross-functional teams. When developers, designers, and product managers work together on the same feature, agile's collaborative structure (shared backlog, daily communication, joint demos) produces better outcomes than waterfall's phase-based handoffs.
The hybrid middle ground
Most organizations operate somewhere between pure waterfall and pure agile. The hybrid approaches are not compromises - they are practical adaptations that take the best elements of each methodology.
Water-Scrum-Fall
The most common hybrid. High-level planning and release milestones follow a waterfall structure (quarterly roadmap, release dates, phase-gate reviews), while the build phase uses scrum sprints or kanban flow. Leadership gets the predictability they want; the engineering team gets the flexibility they need.
Agile with documentation gates
For teams in regulated industries that want agile's feedback benefits, this hybrid adds waterfall-style documentation checkpoints to an otherwise agile process. Each sprint produces not only working software but also the compliance documentation required for the next regulatory review.
Kanban with periodic planning
The lightest hybrid. Work flows continuously through a kanban board, but the team meets biweekly for a planning session to reprioritize the backlog and align on the next two weeks of focus. No sprint commitments, no velocity tracking, no burndown charts - just a regular touchpoint for priority alignment layered on top of continuous flow.
Why most software teams land on kanban
For software teams practicing continuous delivery - which is most modern teams - kanban emerges as the natural methodology. It provides the visibility and structure of waterfall (everything is visible on the board, flow metrics track progress) without the rigidity. It provides the adaptability of agile without the ceremony overhead of scrum.
Kanban works because it starts from where you are. There is no transformation, no new roles, no new meetings. You visualize your current workflow, set WIP limits, and improve incrementally. The board is both your planning tool and your tracking tool. Real-time sync keeps it current. The activity log provides accountability. Multi-board views give leadership the portfolio visibility they need.
If you are evaluating methodologies for your team, start with kanban. It has the lowest adoption cost and the fastest time to value. If you later find that your team needs sprint-level planning cadence, add it - kanban is compatible with periodic planning without requiring a framework change. For details on how to implement kanban principles and set up boards, see the kanban methodology guide. For a broader view of the project management landscape, return to the project management pillar guide.
If you are comparing specific tools for implementing your chosen methodology, our Jira vs Flux comparison breaks down how each tool handles kanban, sprint planning, and cross-project tracking.