Agile software development is an umbrella term for process models that build a software product in short, iterative cycles and refine it after each iteration based on user and customer feedback. Instead of specifying the entire product down to the last detail up front and delivering it “big bang” at the end, working intermediate versions emerge in weekly rhythms. The goal is to deliver visible results early, react quickly to changing requirements and reduce the risk of expensive wrong turns. The most important methods in practice are Scrum, Kanban and Extreme Programming – combined with modern tools from DevOps and continuous integration, they are today’s de facto standard in professional software development.
How does agile software development work?
Agile development runs in short, self-contained iterations – called “sprints” in the Scrum context, typically two to four weeks long. Every sprint follows a fixed rhythm of planning, implementation, review and retrospective:
- Planning: the team selects the requirements from the prioritised product backlog that fit into the next sprint.
- Implementation: the selected tasks are carried out; daily stand-ups synchronise the team and surface blockers early.
- Review: at the end of the sprint, the team presents the finished increment to the customer or product owner.
- Retrospective: the team reflects on its own way of working and defines concrete improvements for the next sprint.
After the sprint, the cycle starts over. Requirements, priorities and even the architecture may change between sprints. That’s a feature, not a bug. Instead of committing to everything at the start, customer and team agree on a vision and deliver substance towards it in regular steps.
The four values of the Agile Manifesto
The Agile Manifesto was formulated in 2001 by 17 software developers and has since served as the common frame of all agile methods. It names four values – each in the form “A over B”, meaning: B is not unimportant, but A weighs more.
Individuals and interactions over processes and tools
Software is built by people, not by tools. Direct communication and a well-attuned team deliver better results than lovingly detailed process descriptions or the next ticket system.
Working software over comprehensive documentation
A running prototype says more about the product than an 80-page requirements document. Documentation has its place, but it doesn’t replace the running piece of software.
Customer collaboration over contract negotiation
The customer is part of the team, not a contracting party with a fixed list of obligations. Change requests are planned in rather than fended off.
Responding to change over following a plan
A plan is a snapshot. As soon as market, technology or customer requirements shift, the team must be able to adjust course without drowning in change requests.
Behind the four values stand twelve concrete principles describing everything from delivery cadence and architecture to the team’s self-organisation.
Well-known agile methods
Scrum
Scrum is by far the most widely used agile method. It clearly defines roles (product owner, scrum master, development team), artefacts (product backlog, sprint backlog, increment) and events (planning, daily, review, retro). Scrum is particularly suited to complex product developments whose exact scope isn’t fixed at project start.
Kanban
Kanban originally comes from Toyota’s production system and focuses on continuous workflow instead of fixed sprints. Tasks move visually across a board (To Do → In Progress → Done), and the team deliberately limits the number of tasks running simultaneously (work in progress, WIP). Well suited to maintenance, support and teams with unpredictable workloads.
Extreme Programming (XP)
XP puts the technical practices front and centre: pair programming, test-driven development, continuous integration, short release cycles and collective code ownership. XP is rarely found in pure form today, but its practices have passed into modern engineering standards.
Lean software development
Lean transfers principles from lean production management to software development: minimise waste, amplify learning, decide as late as possible, hand responsibility to the team. Lean is often laid as a thinking frame over Scrum or Kanban.
Scrumban
A hybrid of Scrum and Kanban: fixed roles and events from Scrum, but a pull system and WIP limits from Kanban. Popular with teams coming from Scrum that want more flexibility in their delivery cadence.
SAFe and LeSS (scaled frameworks)
As soon as several agile teams work on one product, scaling frameworks such as SAFe (Scaled Agile Framework) or LeSS (Large-Scale Scrum) come into play. They structure dependencies between teams, releases and programme levels.
Roles in the agile team
| Role | Responsibility |
|---|---|
| Product owner | Prioritises the product backlog, clarifies domain questions, owns the product value. |
| Scrum master / agile coach | Ensures the team works in an agile way, clears blockers out of the way, shields it from disruption. |
| Development team | Implements the requirements technically, ideally cross-functional (frontend, backend, QA, design in one team). |
| Stakeholders | Business units, customers, specialist departments – provide input and accept increments. |
In small projects, roles frequently merge: a tech lead takes on product owner duties on the side, an experienced developer acts as scrum master. That’s pragmatic, as long as it remains clear who makes which decisions.
Benefits of agile software development
Faster time to market
The first productive functionality often goes live after just a few sprints, rather than only after months of specification. That makes it possible to test market reactions early and refine the product based on real usage data.
Lower project risk
Because requirements, architecture and market are reviewed regularly, wrong turns show up early – while correction is still cheap. Instead of scrapping a 12-month engagement at the end, the course changes after one sprint.
Higher product quality
Tests, code reviews and continuous integration aren’t add-ons but a fixed part of every sprint. Problems accordingly show up early and get fixed before they harden.
Better customer relationships
In every review, the customer sees what their money has achieved. Wishes and adjustments are planned in rather than formally rejected – trust grows from pace and transparency.
Higher team motivation
Clear responsibility, short feedback cycles and visible progress do more for team morale than months-long spec phases whose result only becomes tangible late.
Better cost and effort control
Agile approaches lower the probability of paying, in the end, for features nobody needs. Sprint by sprint, you can decide where the next euro gets invested.
When does agile fit, and when not?
Agile methods unfold their strength above all where requirements are not yet fully clear at project start or may change along the way. That applies to the majority of modern software projects, especially:
- Product developments facing an uncertain market
- Custom software whose requirements only crystallise in conversation – see also our page on custom software development
- Complex web platforms under continuous development
- Mobile and web apps with frequent user feedback
Agile is less suitable for:
- Heavily regulated projects (aviation, medical technology) with extensive audit and documentation obligations
- Pure maintenance contracts with a firmly defined service catalogue
- Fixed-price engagements with non-negotiable scope: here the conflict between agile adaptability and contractual finality lies in the nature of the thing.
Typical tools
Agile teams today work practically without exception with digital boards and CI/CD pipelines:
- Boards & backlogs: Jira, Linear, GitHub Projects, Azure DevOps, Trello
- Code & CI/CD: GitHub, GitLab, Docker – see also our tech stack
- Collaboration: Slack, Microsoft Teams, Miro, FigJam
- Testing: Playwright, Cypress, Jest, JUnit – continuous tests are part of the “definition of done”
Frequently asked questions about agile software development
Is Scrum the same as agile? No. Agile is the overarching set of values and principles; Scrum is one concrete method within it. Other agile methods are Kanban, XP or Lean. Many teams say “we do Scrum” and mean a mix of Scrum events and Kanban pull principles.
Can agile work for fixed-price projects? To a limited extent. Classic fixed-price contracts with a detailed requirements document fit agile flexibility poorly. Hybrid models such as a fixed-price budget with flexible scope, or a fixed price per sprint, work well in practice, but demand mutual trust.
How long should a sprint be? Two weeks is the most common value. One week suits very fast feedback cycles or small teams; four weeks fit more complex backlogs but cost adaptability. More important than the length is that the team sustains a steady rhythm.
What are the biggest pitfalls? Daily stand-ups as pure status reports instead of a synchronisation tool, a product owner without decision-making authority, a retrospective without visible consequences, or “Scrum on paper” with waterfall reality behind it. An experienced agile coach or scrum master makes the difference here.
Can agile be used outside software development? Yes. Marketing, hardware development, even construction projects experiment with agile methods. The values of the Agile Manifesto are formulated generally enough to apply in any knowledge-work context.
Conclusion
Agile software development is today far more than a methodology debate – it is the standard way modern software teams work. Anyone developing a digital product benefits from short delivery cycles, early visibility and a balanced relationship of plan, adaptation and risk. We have relied on agile ways of working for our custom software projects for more than ten years. If you want to know what that can look like concretely for your project, get in touch for a no-obligation consultation.