Waterfall is the original structured project management methodology — a sequential, linear approach where project activities flow from one phase to the next like water descending a series of steps, with each phase fully completed and approved before the next begins. First formalised in manufacturing and construction engineering in the 1960s and 1970s, Waterfall reflects the engineering principle that problems are far cheaper to resolve in the planning phase than in the execution phase. A design error caught on paper costs an engineer's afternoon; the same error caught after tooling is manufactured costs a programme.

Waterfall's defining characteristic is its upfront completeness requirement: all requirements must be fully defined and documented before design begins; all design decisions must be finalised before construction begins; construction must be complete before testing begins. This sequential rigidity is not a limitation — it is the feature. For projects where the requirements are genuinely stable, where regulatory or quality standards mandate comprehensive documentation at each phase, and where downstream activities depend entirely on the correctness of upstream ones (you cannot change the die casting tool after 10,000 parts have been made), Waterfall's discipline prevents the most expensive category of project failures: discovering fundamental requirements errors at the point of delivery.

The Stage-Gate Process (Robert Cooper's product development framework) is Waterfall applied to new product development — the dominant framework in automotive, pharmaceutical, food and beverage, and aerospace product launches. Each stage (phase) delivers specific outputs evaluated at a Gate review, where a cross-functional management team decides whether to proceed, recycle (do the stage again with changes), hold, or kill the project. APQP (Advanced Product Quality Planning) in the automotive supply chain is Stage-Gate applied specifically to supplier new product launches — defining exactly what must be delivered at each gate and in what quality before the next phase is authorised.

Agile emerged from the software development community in the late 1990s as a direct challenge to Waterfall's assumption that requirements can be fully defined at the start. The Agile Manifesto (2001), signed by 17 software practitioners, articulated four value statements that fundamentally reoriented project management thinking: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. These four values — with 12 accompanying principles — describe an approach to project delivery that is the philosophical inverse of Waterfall's planning-first, build-after approach.

The practical foundation of Agile is the sprint — a fixed, short development cycle (typically 1–4 weeks) at the end of which working, demonstrable output is delivered to the customer or product owner for feedback. Rather than delivering everything once at the end of a long project, Agile delivers incrementally — each sprint adds value, each sprint's output is reviewed, and the product backlog (the prioritised list of remaining work) is updated based on what was learned. This creates a continuous feedback loop between the team and the customer that catches requirement misunderstandings immediately, when they are cheap to correct, rather than at project end when they are catastrophic.

The three most widely used Agile frameworks in engineering contexts are: Scrum (the most common — fixed-length sprints with defined roles: Scrum Master, Product Owner, Development Team; defined ceremonies: Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective), Kanban (continuous flow based on visual boards with work-in-progress limits — pulls work through the system rather than pushing batches; particularly effective for operational and maintenance work rather than project development), and SAFe (Scaled Agile Framework) (extends Agile to large organisations with multiple teams — used by Boeing, Lockheed Martin, and large automotive OEMs for coordinating hundreds of engineers across multiple workstreams on a single programme).

In real-world manufacturing and engineering organisations, most complex programmes do not fit neatly into either pure Waterfall or pure Agile. A new vehicle platform programme involves IATF 16949-compliant NPI processes (which are inherently Waterfall Stage-Gate) for mechanical and electrical components, concurrent Agile development sprints for the embedded software, and Lean daily management cadence on the production ramp. Pretending these must all follow the same methodology is both unnecessary and counterproductive. Hybrid project management deliberately combines elements of Waterfall and Agile at the right levels and in the right proportions for the specific project.

The most common hybrid patterns in manufacturing engineering are: Waterfall overall structure with Agile within phases — the programme follows Stage-Gate gates (Waterfall), but within each phase, teams use sprint cycles and daily standups to execute the phase deliverables (Agile). This gives the programme the documentation rigour and gate-controlled progression of Waterfall while allowing the execution flexibility and continuous feedback of Agile. Rolling Wave Planning — the near-term phases are planned in full Waterfall detail, while later phases are planned only at a high level (because the detailed requirements for those phases depend on what is learned in earlier ones). The plan is progressively elaborated as the project advances — a direct acknowledgement that more detail is available closer to execution. Agile R&D with Waterfall productionisation — used by Tesla, Philips, and many technology-intensive manufacturers: the research, design, and software development phases use Agile, while the manufacturing scale-up, validation, regulatory approval, and production launch phases use Waterfall/Stage-Gate.