- ✓Waterfall is most effective when requirements are stable, well-understood and unlikely to change significantly during development, making it a reasonable choice for regulated environments or projects with contractual fixed-scope requirements.
- ✓Agile methods excel in environments where requirements are expected to evolve, where early delivery of working software is valued, or where close collaboration between developers and users is possible throughout the project.
- ✓The Agile manifesto's four values (individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan) represent a genuine philosophical shift, not just a process change.
- ✓Hybrid approaches that combine elements of Waterfall and Agile are increasingly common in organisations that need the predictability of planned phases for governance and budgeting purposes alongside the flexibility of iterative development.
- ✓Understanding which SDLC to recommend in a given context, and being able to justify that recommendation with reference to the specific characteristics of the project, team and organisation, is a core competency for anyone in a technical leadership or consultancy role.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Hello and welcome back. Today we're going deeper on the Agile versus Waterfall question, which I know is a topic that generates strong opinions. Sam, why do people get so worked up about methodology choice?
Sam: Because it's not just a technical question: it touches on how teams are organised, how work is planned and measured, how decisions are made and what professional identity looks like for developers, project managers and the business stakeholders they work with. Waterfall and Agile aren't just different processes: they embody different philosophies about how complex work should be managed.
Alex: Let's look at the Agile philosophy in more depth. Because the Agile Manifesto is quite specific.
Sam: The Manifesto states four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The critical word is 'over': the Manifesto doesn't say processes, documentation, contracts and plans are without value, it says that the things on the left are more important. That nuance often gets lost.
Alex: And Scrum is the most widely used Agile framework. How does it work?
Sam: Scrum organises work into sprints, which are fixed time periods, typically two weeks, during which the team commits to completing a defined set of work items from a prioritised backlog. The sprint begins with a planning session, has a brief daily standup meeting throughout, and ends with a sprint review where the team demonstrates what was built to stakeholders, and a retrospective where the team reflects on how the sprint went and how they can improve. Three roles: the product owner who prioritises the backlog, the scrum master who facilitates the process, and the development team who do the work.
Alex: What are the scenarios where Agile genuinely works better than Waterfall?
Sam: Where requirements are expected to evolve. Where delivering working software to users early and getting feedback is possible and valuable. Where the team is co-located or able to communicate effectively in a distributed setting. Where the organisation has the cultural maturity to trust teams to self-organise rather than needing detailed upfront plans. And where the product being built is genuinely complex enough that iteration and discovery are necessary.
Alex: And where does Waterfall still make sense?
Sam: Where requirements are genuinely fixed and well understood, as in some regulatory or engineering contexts. Where there are hard constraints on scope, cost and timeline from the outset. Where the technical complexity is such that a coherent architecture needs to be designed before any implementation begins. And where the team or organisation doesn't have the cultural readiness for Agile to work in its full form.
Alex: What about hybrid approaches?
Sam: Very common in practice. Many organisations use a Waterfall-like approach for the early discovery and architecture phases, then switch to Agile for delivery. Or they use Agile for development but maintain more formal governance and documentation requirements. There's no shame in hybrid approaches: the goal is to find what actually works in your specific context, not to adhere to methodological purity.
Alex: Clear and balanced. Thanks, Sam. Next we'll look at behavioural design techniques.