Software development rarely goes to plan: requirements change, bugs appear, and clients realise halfway through that they wanted something different. Agile software development accepts this uncertainty as normal and structures work into short cycles called sprints, delivering working software frequently rather than aiming for one perfect release months away.
What is the software development life cycle?
The Software Development Life Cycle (SDLC) describes the stages through which software is conceived, built, and maintained. All approaches to software development pass through these stages, in one form or another:
- Analysis — understand requirements; what should the software do?
- Design — plan the system architecture, data structures, and interfaces
- Implementation — write the code
- Testing — verify the code meets requirements and contains no defects
- Maintenance — fix bugs, add features, and update the system
Different software development methodologies organise these stages differently. Waterfall runs them once, in sequence. Agile runs them repeatedly in short cycles.
What is the waterfall model?
The waterfall model completes each SDLC stage fully before moving to the next. Requirements are gathered, frozen, and documented at the start. Design follows, then implementation, then testing, then deployment. The process flows downward like a waterfall — changes flow back up with great difficulty.
Advantages of waterfall:
- Clear milestones and documentation at each stage
- Easy to manage when requirements are fixed and well understood
- Well suited to projects with strict regulatory requirements (medical devices, aircraft software)
Disadvantages of waterfall:
- Any change in requirements late in the process is very costly
- The client sees no working software until the end — often months or years later
- Errors discovered in testing may require expensive redesign
What is agile development?
Agile is an iterative and incremental approach. Rather than completing the entire system at once, the team builds a small, working portion of the system in a short fixed period called a sprint (typically one to four weeks), delivers it to stakeholders for feedback, and then plans the next sprint based on that feedback.
After each sprint, the software is improved, extended, and re-evaluated. Requirements can change between sprints — indeed, agile expects and accommodates this.
What are the core principles of agile?
In 2001, seventeen software developers published the Agile Manifesto, which defined four core values:
| Agile values… | …over |
|---|---|
| Individuals and interactions | Processes and tools |
| Working software | Comprehensive documentation |
| Customer collaboration | Contract negotiation |
| Responding to change | Following a plan |
The manifesto does not dismiss the items on the right — documentation and planning still matter — but it prioritises the items on the left when the two conflict.
How does a sprint work?
A typical agile sprint follows this pattern:
- Sprint planning — the team selects a set of features (from a prioritised backlog) to build during the sprint
- Development — the team designs, codes, and tests the selected features
- Daily stand-up — a brief daily meeting: what did I do yesterday? What will I do today? Any blockers?
- Sprint review — at the end of the sprint, working software is demonstrated to stakeholders, who give feedback
- Retrospective — the team reflects on its own process: what went well? What should change?
The next sprint begins immediately with updated priorities based on feedback received.
How does agile compare with waterfall?
| Property | Waterfall | Agile |
|---|---|---|
| Requirement changes | Difficult and costly | Welcome — adapted between sprints |
| Customer involvement | Mainly at start and end | Continuous — every sprint review |
| Working software visible | At the end of the project | After every sprint |
| Documentation | Heavy, upfront | Light, just enough |
| Best suited to | Fixed, well-understood requirements | Evolving or unclear requirements |
| Risk of failure | High (errors compound over months) | Lower (errors caught each sprint) |
| Team structure | Hierarchical, stage-specific | Small, cross-functional, self-organising |
What are real-world examples of agile use?
Most modern software companies — including the teams that built the apps on your phone — use some form of agile. A mobile app team might release a new version of the app every two weeks (each release represents a sprint). Each version adds a small number of new features and fixes bugs reported since the previous version. Users see continuous improvement rather than waiting a year for a major release.
Government digital services in the UK (including services behind gov.uk) use agile explicitly, following the Government Service Standard which mandates iterative development, regular user research, and continuous improvement.
Frequently asked questions
Why is agile better for projects where requirements are uncertain?
Because it builds in checkpoints (sprint reviews) where real working software is demonstrated and feedback is collected before most of the project budget is spent. In waterfall, a wrong assumption at the requirements stage is not discovered until testing — which may be twelve months later, after the design, implementation, and testing are all based on the flawed assumption. In agile, the same wrong assumption surfaces after the first sprint, when only a fraction of the budget has been spent.
What is a product backlog in agile?
A product backlog is an ordered list of features, improvements, and bug fixes that the team intends to build — but has not yet started. The backlog is owned by the product owner, who prioritises it based on business value and user feedback. At the start of each sprint, the team pulls the highest-priority items from the top of the backlog into the sprint plan. The backlog is never "complete" — new items are added as requirements evolve.
Is agile always better than waterfall?
No — context determines the best approach. Agile requires close customer involvement throughout the project; if the customer is unavailable for regular reviews, agile struggles. For projects with fixed, legally mandated requirements (building a bridge, developing pharmaceutical software), waterfall's comprehensive documentation and stage approvals are more appropriate. Most real-world projects use a hybrid approach — agile within project phases, waterfall between major phases.
Which GCSE specifications cover agile development?
AQA GCSE Computer Science (8525) includes the iterative and waterfall models of software development within its SDLC content. OCR J277 similarly covers these approaches. Edexcel 1CP1 includes software development methodologies. In all cases, students should be able to describe both agile and waterfall approaches, compare their advantages and disadvantages, and state which is more appropriate for a given scenario.
Build your understanding of software development from analysis through to deployment — Professor Turing at aitutors.me guides you through every part of the GCSE specification.