Agile Software Development: Process, Manifesto, Life Cycle and Scrum Explained

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Agile software development is an iterative way of building software in short cycles, releasing working increments and changing course based on feedback. It is the agile methodology of software development that most product teams now start from. This guide explains the Agile Manifesto, the agile software development process and life cycle, Scrum and Kanban, lean principles, and how agile compares with waterfall: plainly, with the terms defined.

What is agile software development?

Agile work is an approach to building software in which cross-functional teams deliver working increments in short, repeated cycles and adapt the plan based on feedback, rather than defining everything up front and delivering once at the end.

The Manifesto for agile delivery: the manifesto of agile software development

Published in 2001 by seventeen software practitioners, the Agile Manifesto sets out four values and twelve principles. The values prefer the items on the left while recognizing value in those on the right. The twelve agile development principles behind the values cover early and continuous delivery, welcoming changing requirements, working software as the main measure of progress and regular reflection on how to work better.

What is the agile delivery process? The agile software development process, step by step

The agile process runs in cycles: maintain a prioritized backlog, plan a sprint, build and test, hold short daily standups, demo the working increment in a review, reflect in a retrospective, release, and repeat.

The agile development life cycle

The agile SDLC repeats concept, iteration (design, build, test), release, maintenance and feedback continuously, rather than moving once through requirements, design, build, test and deploy as in waterfall. A typical agile development workflow moves each item from backlog to ready, in progress, review, testing and done, and the same agile methodology workflow applies whether the team uses a Scrum sprint board or a Kanban board.

Scrum, Kanban and other agile frameworks: SAFe agile development and agile development frameworks

Scrum

Fixed-length sprints with three roles, product owner, Scrum Master and developers, and events for planning, daily coordination, review and retrospective. See the Scrum Guide.

Kanban

A continuous flow of work visualized on a board with limits on work in progress; no fixed sprints.

Extreme Programming (XP)

Engineering practices such as test-driven development, pair programming and continuous integration.

Lean software development

Principles from lean manufacturing applied to software: eliminate waste, build quality in, deliver fast, defer commitment and optimize the whole.

SAFe: agile development at scale

SAFe, the Scaled Agile Framework published by Scaled Agile, Inc., is a framework for scaling lean and agile practices across an organization, and it is the usual answer when people ask about safe agile development for large programs. It organizes the work into five competency areas: Lean Portfolio Management, Team and Technical Agility, Product Development Flow, Large Solution Integration and Delivery, and Leadership and Culture. The agile methodology SAFe describes sits above team-level Scrum or Kanban, because its job is to coordinate many teams working toward one release. For a single product team it adds more coordination than it removes, so most of the agile development frameworks in everyday use start with Scrum or Kanban and add scaling only when several teams depend on each other’s work.

Agile methodology of project management: how agile project management differs

The agile methodology of project management applies the same short-cycle thinking to planning and tracking work that agile software development applies to code. Instead of one fixed plan agreed at the start, a project management agile methodology keeps a prioritized backlog, plans one cycle at a time, reviews working output at the end of each cycle and reorders what comes next. The project manager’s job shifts from enforcing a schedule to removing blockers, keeping the backlog honest and making trade-offs visible to the people paying for the work. Agile methodology in project management also changes reporting: progress is shown by working increments and the backlog that remains, not by percent complete against a Gantt chart.

Software helps but does not create the discipline. Agile development project management software and agile development project management tools usually combine a backlog, a sprint or Kanban board, estimates, and burndown or flow charts. When you compare agile software development management tools, check how they handle story points, work in progress limits and reporting for stakeholders who do not use the tool every day. The same test applies to any tools for agile methodology: a team that has not agreed what done means will not be rescued by a board. Choose tools for agile development after the team has run two or three cycles by hand, on a wall or a spreadsheet, so the tool follows working habits rather than inventing them.

Agile vs waterfall software development

Waterfall moves through fixed phases once and delivers at the end; agile delivers working software every sprint and adjusts. Agile reduces the risk of building the wrong thing; waterfall offers more up-front predictability when requirements are fixed.

Security in the agile delivery life cycle

Security is built into each sprint rather than tested at the end: threat modeling during design, code review and automated scanning on every change, and penetration testing before major releases. The NIST Secure Software Development Framework describes these practices.

Agile and the MVP

In agile, the minimum viable product is the first increment released to real users; later sprints iterate on what they do.

How Progression Agency uses agile

Our software and app development projects run in two-week sprints with a written first-release scope, an installable or deployable build at the end of every sprint, and a shared backlog you can see and reprioritize.

Scrum roles, events and artifacts

The 2020 Scrum Guide defines three accountabilities, five events and three artifacts. Teams that talk about agile methodology ceremonies mean these same five events, and the agile development retrospective at the end of each sprint is where the team inspects how it worked and picks improvements for the next one.

Scrum vs Kanban: scrum software development and kanban agile software development, and agile development vs scrum

Both are agile. Scrum works in fixed Sprints; Kanban manages a continuous flow of work with limits on work in progress.

Agile vs Scrum: is Scrum a methodology?

Agile is a set of values and principles, and Scrum is one specific way of following them. Agile development vs scrum is therefore not a choice between two rivals: a team can be agile without Scrum, but a team that practices Scrum properly is following agile values. The Scrum Guide itself calls Scrum a lightweight framework rather than a methodology, which settles the common question of scrum or agile methodology: the two phrases are used loosely, but agile is the umbrella and Scrum is a framework inside it. In a scrum vs agile methodology comparison, Scrum prescribes roles, events and artifacts, while the agile methodology vs scrum distinction comes down to prescription: agile tells you what to value, and Scrum tells you what to do each week.

Agile vs waterfall at a glance

Waterfall completes each phase before the next begins; agile repeats all phases in short cycles.

Agile delivery cycles, user stories and testing: agile software development cycles in practice

Agile work cycles are the sprints: each starts with planning, ends with a review and a retrospective, and delivers working software. Work is described as agile user stories (who, what, why), the project plan is a prioritized backlog with a release roadmap rather than a fixed Gantt chart, and testing happens inside every cycle through automated tests written with the code. For how agile compares with the other software development life cycle models, see the software development life cycle.

User stories, story points and epics

In agile software development user stories are short descriptions of a need written from the user’s side: as a type of user, I want something so that I get a benefit. A user story in agile development is deliberately small enough to finish in one cycle, which is why a larger need is written as an epic and then split into stories. Agile development epics bundle related stories under one goal, such as a new checkout flow, so the roadmap stays readable while the daily work stays small. Teams estimate each story in story points, a relative measure of effort and uncertainty rather than hours, and the user story agile methodology convention is to agree acceptance criteria before work starts. Agile methodology user story points are comparable only within one team, so do not use them to rank teams. Agile software development testing follows the same rhythm: tests are written alongside the code, run automatically on every change, and a story is not done until they pass.

Frequently asked questions