In short
Agile software development is an approach in which software is created in short cycles and a usable interim result is available after each cycle. Requirements are prioritised and adjusted continuously instead of being fixed completely at the start.
The basis is the Manifesto for Agile Software Development, published by 17 software developers in February 2001.
Agile is not a single method but a mindset with four values and twelve principles. Concrete methods such as Scrum, Kanban or Extreme Programming put this mindset into practice in different ways. For custom software, working in an agile way is widespread today because the requirements for new software can rarely be predicted in full.
The four values of the Agile Manifesto
The manifesto contrasts two things in each case. It does not declare the right-hand side worthless but values the left-hand side more:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
A common misunderstanding lies in the second value: agile teams still document, just not in advance for its own sake. What gets documented is what someone actually needs, such as architecture decisions, interfaces and acceptance criteria.
Selected principles
Of the twelve principles behind the manifesto, these are particularly formative in practice:
- Working software is delivered regularly and at short intervals.
- Changes to requirements are welcome, even late in development.
- Business people and developers work together daily throughout the project.
- Working software is the primary measure of progress.
- At regular intervals, the team reflects on how to become more effective and adjusts its behaviour accordingly.
Agile methods at a glance
| Method | Core idea | Typical elements | A good fit when |
|---|---|---|---|
| Scrum | Work in sprints of fixed length with a clear sprint goal | Product Owner, Scrum Master, Developers; Sprint Planning, Daily Scrum, Sprint Review, Retrospective; Product Backlog, Sprint Backlog, Increment | A product is developed over a longer period by a stable team |
| Kanban | Continuous flow instead of fixed cycles; the amount of parallel work is limited | Board with columns, WIP limits, measurement of lead time | Ongoing development and maintenance with incoming work that is hard to plan |
| Extreme Programming (XP) | Technical practices for high code quality with frequent changes | Test-driven development, pair programming, continuous integration, small releases | As a complement to Scrum or Kanban when quality and speed both count |
Scrum is the best-known agile method. The Scrum Guide specifies that a sprint lasts no longer than one month and ends with a usable increment that meets the Definition of Done. For very large organisations there are scaling frameworks such as SAFe or LeSS that coordinate several teams working on one product.
Agile vs traditional: the comparison
Traditional process models such as the waterfall model or the V-model plan the project in successive phases and fix the requirements in advance. Agile software development plans in short loops.
| Traditional (waterfall, V-model) | Agile (Scrum, Kanban) | |
|---|---|---|
| Requirements | Fully defined at the start, for example in a requirements specification | Roughly at the start, details shortly before implementation |
| Planning | Overall plan with phases and milestones | Target picture plus planning per cycle |
| Result visible | At the end of implementation | After every cycle, as working software |
| Handling changes | Via a formal change request | Via reprioritisation of the backlog |
| Role of the client | Strong at the beginning and at acceptance | Ongoing, for example as Product Owner or in the Sprint Review |
| Strength | Predictability with stable, well-known requirements | Learning and changing course with uncertain requirements |
Neither model is fundamentally better. With requirements fixed by regulation or fixed interfaces to hardware, a traditional framework often makes sense. For new products whose benefit only becomes clear in use, an agile approach plays to its strengths. Many projects combine the two: a fixed framework for budget and core requirements, with agile implementation inside it.
Agile software development in practice
A typical flow in a Scrum project looks like this:
- Target picture and backlog: in a requirements analysis, goals, user groups and constraints are clarified. This results in a first product backlog with user stories, prioritised by business value.
- Sprint Planning: the team selects the most important items it can manage in the sprint and formulates a sprint goal.
- Implementation: in the Daily Scrum the team aligns briefly. Code is integrated continuously and tested automatically.
- Sprint Review: the team shows the working software, not a presentation. The business side gives feedback and the backlog is adjusted.
- Retrospective: the team discusses what will improve collaboration in the next sprint.
Agile development fits particularly well with the minimum viable product: the first version contains only the functions needed to test the most important assumption, and every further sprint builds on real user feedback.
Common mistakes
- Agile without a goal: a backlog without a product goal leads to many completed tickets but no coherent product.
- A Product Owner without decision-making authority: if every priority first has to be clarified in a round of consultations, the team comes to a standstill.
- Architecture "emerges by itself": agile teams also need an early framework for the software architecture; otherwise technical debt piles up.
- Rituals without content: a Daily Scrum that turns into a status report for management loses its purpose.
At nextlevels, every sprint ends with a demo of working software rather than a status report, and you help prioritise the backlog. How we steer projects in this way is described in our agile project management service.
FAQ on agile software development
What does agile software development mean?
Agile software development means developing software in short cycles, showing a usable interim result after each cycle and continuously adjusting the planning on the basis of feedback. It is based on the four values and twelve principles of the 2001 Agile Manifesto.
What agile methods are there?
The best known are Scrum, Kanban and Extreme Programming (XP). For large organisations with many teams there are scaling frameworks such as SAFe and LeSS. Many teams combine elements, for example Scrum for planning and XP practices for code quality.
Is Scrum the same as agile?
No. Agile is the overarching mindset; Scrum is a concrete method that implements this mindset with fixed roles, events and artefacts. A team can also work in an agile way without Scrum, for example with Kanban.
Do agile projects need a requirements specification?
A classic requirements specification with every detail is usually not necessary in agile projects. Goals, constraints and the most important requirements should still be in writing, often as a product vision and a prioritised backlog. In tenders, a lean requirements specification is frequently combined with agile implementation.
For which projects is agile software development not suitable?
It is less suitable when all requirements are fixed and must not change, for example because of standards or contracts, or when the business side cannot collaborate regularly. In that case a traditional process model or a hybrid is often a better fit.
Further reading: how requirements are created and maintained in an agile project is shown in our requirements analysis and project management service.