- ✓Waterfall development is characterised by a rigid sequence of phases: requirements, design, implementation, testing, and maintenance.
- ✓Agile development delivers software in short iterations called sprints, with requirements refined continuously through stakeholder feedback.
- ✓Scrum is the most widely used Agile framework, organising work into two-week sprints with defined roles including Product Owner and Scrum Master.
- ✓Kanban provides a visual workflow management approach where work items flow through stages, with limits placed on work in progress.
- ✓Choosing between Waterfall and Agile depends on factors including how well requirements are understood, how frequently they change, and team experience.
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: Today we're doing a proper deep dive into Waterfall versus Agile. Sam, this is one of the most practically important debates in software development.
Sam: It really is, and it's important to understand that it's not a debate with a winner. Both approaches have genuine strengths, and the right choice depends entirely on the specific context of the project.
Alex: Let's start with what Agile actually means. It's thrown around a lot.
Sam: Agile is a philosophy or mindset, not a single methodology. It's defined by the Agile Manifesto, published in 2001 by a group of experienced developers who were frustrated with the rigidity of traditional approaches. The manifesto states four values: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. These values don't mean you ignore processes, documentation, contracts, or plans; they mean you prioritise the first item in each pair when trade-offs have to be made.
Alex: And Scrum is the most common Agile framework?
Sam: By far. Scrum organises work into short iterations called sprints, typically one to four weeks. At the start of each sprint, the team selects a set of items from the product backlog, a prioritised list of work, and commits to completing them during the sprint. At the end of the sprint, the team demonstrates the working software they've produced, reviews what went well and what needs improvement, and then plans the next sprint. The process is highly transparent and creates a rapid feedback loop with stakeholders.
Alex: What are the key roles in Scrum?
Sam: Three key roles. The Product Owner represents the business and is responsible for maintaining and prioritising the product backlog; they make decisions about what gets built and in what order. The Scrum Master facilitates the Scrum process, removes impediments that are slowing the team down, and helps the team improve its practices over time. The development team is a self-organising, cross-functional group that does the actual work.
Alex: And Kanban?
Sam: Kanban comes from lean manufacturing and provides a visual approach to managing workflow. Work items are represented on a Kanban board and move through columns representing stages: to do, in progress, done. A key principle is limiting work in progress: each column has a maximum number of items that can be in it at once, which prevents overloading and reveals bottlenecks. Kanban is more flexible than Scrum; you don't have sprints or defined team roles, and you can change priorities as new work arrives.
Alex: When would you choose Waterfall over Agile?
Sam: Waterfall suits projects where requirements are genuinely stable and well-understood upfront, where the technology is mature, where a fixed price and timeline are essential contractually, or where regulatory requirements demand comprehensive documentation before development begins. Government and defence projects often use Waterfall or formal variants of it for precisely these reasons.
Alex: And Agile?
Sam: Agile is better suited when requirements are likely to evolve, when rapid delivery of value is important, when close collaboration with users is feasible, and when the team is experienced with self-organisation. Most commercial software product development falls into this category.
Alex: Brilliant. Really useful contrast. Thanks Sam. Next we look at feasibility studies.