Agile project management is an iterative approach to running projects: work moves forward in short cycles, each one planned, built, reviewed and adjusted before the next begins. It is the dominant way software gets delivered, and it has spread well beyond software.
It is also widely misunderstood. In the 18th State of Agile Report, published by Digital.ai in October 2025, 74% of organisations said they use a hybrid, blended or homegrown model rather than a textbook one. Agile in practice is rarely the pure version described in most guides.
This article covers what it is, the values and principles it rests on, the five phases of the agile life cycle, the roles involved, how it compares to waterfall, and what it does and does not fix.
- What Is Agile Project Management?
- The 4 Values and 12 Principles Behind Agile
- The 5 Phases of Agile Project Management
- How Agile Project Management Works
- An Example of Agile Project Management in Practice
- Agile Project Management Roles and Responsibilities
- Agile vs Waterfall: How They Actually Differ
- Benefits of Agile Project Management
- What Agile Does Not Fix
- Frequently Asked Questions
- Key Takeaways
What Is Agile Project Management?
Agile project management is an iterative approach to working on projects. The iterative nature of the process means that a project moves forward in short performance cycles that include such steps as planning, testing, development, and review of results. While one of such agile cycles remains in progress, a team is expected to collect stakeholder feedback. And once that brief project cycle comes to an end, the received feedback is utilized to plan a new iteration for a few weeks ahead.
The shortest agile project management definition is this: decide a direction, build a small piece, show it to someone who cares, and let what you learn change the next piece. Everything else is machinery built around that loop.
What separates it from traditional planning is not speed. It is when the plan is allowed to change. Traditional project management treats a change to scope as an exception that needs approval. Agile treats it as expected input, because the assumption is that nobody knows enough at the start to specify the whole thing correctly.
The 4 Values and 12 Principles Behind Agile
The Agile Manifesto contains two separate things that are often confused: four values and twelve principles. The values are the four comparison statements below. The twelve principles are a longer list explaining how to act on them. Guides that say agile has “four principles” are describing the values.
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan”
The word doing the work in all four is over. The Manifesto explicitly says the items on the right have value, and claims only that the items on the left have more. That is the line most often dropped when agile is summarised, and dropping it is how teams end up believing agile means no documentation and no plan.
The twelve principles sit underneath and are more specific. They group into four themes:
| Theme | What the principles ask for | What it looks like when ignored |
|---|---|---|
| Deliver value early and often | Ship working output in weeks rather than months, and treat that output as the real measure of progress | Sprints end with status updates instead of something anyone can use |
| Welcome changing requirements | Accept scope changes late in development and treat them as an advantage for the customer | A change board appears, and agile becomes waterfall with shorter meetings |
| Build around motivated people | Give teams the environment and support they need, trust them to deliver, and favour direct conversation | Teams are told what to build and how long it will take, then asked to self-organise |
| Sustain the pace and improve | Keep a pace the team can hold indefinitely, keep the design simple, and reflect regularly on how to get better | Retrospectives generate actions nobody schedules, and velocity becomes a target |
The full text of all twelve is short and worth reading in the original at agilemanifesto.org.
The 5 Phases of Agile Project Management
The five phase agile project life cycle comes from Jim Highsmith’s Agile Project Management framework, published in 2004: envision, speculate, explore, adapt and close. It is the model usually meant when someone asks about agile project management phases or the stages of an agile project, and it differs from the linear stages of traditional planning because the middle of it repeats.
| Phase | What happens | What you have at the end |
|---|---|---|
| 1. Envision | Agree what the product is, who it is for, who is on the team and how they will work together | A product vision and a named team, not a specification |
| 2. Speculate | Build a feature based release plan and an estimate, accepting that both are provisional | A roadmap that is expected to change, and a first backlog |
| 3. Explore | Deliver working increments in short iterations while keeping technical and team risk visible | Working output a stakeholder can react to |
| 4. Adapt | Review the results, the process and the team against current conditions, then change the plan | A revised plan, with the reasons for the revision recorded |
| 5. Close | Finish, hand over what was learned and mark the end deliberately | Knowledge transferred rather than lost with the team |
Phases three and four repeat for as long as the project runs. That loop is the whole point: explore produces something real, adapt decides what it means, and the next iteration starts from a better position than the last.
How Agile Project Management Works
Agile is a set of values rather than a procedure, so teams adopt a framework that turns it into a working routine. Two account for most real use.
Scrum
Scrum is the framework the majority of agile teams follow. Work runs in fixed length iterations called sprints, which the Scrum Guide caps at one month or less. Two weeks is the most common choice rather than a rule. Four events give the sprint its shape:
- Sprint planning decides what the team will complete in the coming iteration. It is done together, so the people doing the work set the commitment rather than receive it.
- Daily standup is a short meeting where the team surfaces progress and obstacles. Its purpose is to expose blockers early, not to report to a manager.
- Sprint review, often called the demo, puts completed work in front of stakeholders at the end of the sprint. Feedback collected here feeds the next sprint’s plan.
- Sprint retrospective examines how the team worked rather than what it produced, and produces changes to the process itself.
The backlog is the connective tissue between them: a single ordered list of everything that might be built, kept in priority order by the product owner, from which each sprint draws its work.
Kanban
Kanban takes a different approach. Instead of fixed iterations, it visualises the workflow as columns on a board and limits how much work sits in each column at once.
- Columns represent the stages your work actually passes through, such as new, in progress, under review and completed.
- Tasks move across the board as they advance, so anyone can see the state of everything at a glance.
- A work in progress limit caps each column. When a column is full, nothing new enters until something leaves, which forces bottlenecks into the open instead of letting work pile up invisibly.
That work in progress limit is the part most often skipped, and skipping it turns a Kanban system into a status board. Scrum suits work that can be planned in batches. Kanban suits a continuous flow of requests with changing priorities, such as support or maintenance.
actiTIME includes a built in Kanban board alongside estimate tracking and performance reports, so progress and the cost of that progress stay in one place. Explore it during a free trial.
Other frameworks you will meet
Scrum and Kanban are not the only options. Extreme programming adds engineering practices such as pair programming and test driven development, and is usually layered on top of Scrum rather than used instead of it. Scrumban combines Scrum’s cadence with Kanban’s flow limits. SAFe and similar scaled frameworks coordinate many teams working on one product, and are the usual answer when an organisation outgrows single team agile. If you are moving in that direction, our guide to enterprise agile transformation covers what changes at that scale.
An Example of Agile Project Management in Practice
Here is what the theory above looks like on a real project. A five person team is building a customer portal. The business wants invoice history, payment, support tickets and a usage dashboard. Under waterfall this would be specified in full, estimated once, and built over roughly five months.
Run as an agile project example instead, it starts differently. The team spends two days on envision: the goal is stated as reducing inbound billing calls, not as delivering four features. That reframing matters later.
Speculate produces a rough order and a first backlog. Invoice history goes first, because most billing calls are people asking where their invoice is.
| Sprint | What shipped | What it changed |
|---|---|---|
| 1 and 2, four weeks | Invoice history, viewable and downloadable | Billing calls fell by about a third. The goal was already partly met with one feature of four |
| 3, two weeks | Nothing releasable. Payment provider integration took the whole sprint | The estimate was wrong, and it was known at the end of week six rather than at month five |
| 4 and 5, four weeks | Payment, plus a link to the existing ticket system instead of a new one | Support tickets were descoped to a link once the calls data showed nobody was asking for it |
| 6, two weeks | Usage dashboard, cut to a single chart | Shipped in twelve weeks against a five month plan, with one of four features dropped |
Three things in that example are the actual mechanism, and they are easy to miss.
The sprint 3 failure is the point, not a flaw. The payment integration was going to take longer than anyone thought whichever method the team used. Agile did not prevent that. It surfaced it in week six, while there was still budget and time to react, rather than during integration testing in month five.
The support ticket feature was dropped on evidence. Because the goal was reducing billing calls rather than shipping four features, and because real call data existed after sprint 2, the team could show that a full ticket system would not move the number. Under a fixed scope contract that feature gets built regardless, because it is in the specification.
The dashboard was cut down rather than cut out. A single chart shipped in one sprint answered most of what the full dashboard was for. That decision is only available to a team allowed to change scope late.
Worth being honest about what this example does not show. The team had a product owner who could answer questions the same day, and permission to drop a feature. Remove either and the same six sprints produce four half-finished features and a project that is late.
Agile Project Management Roles and Responsibilities
In traditional project management, one person carries scope, cost, quality, risk and staffing. Agile splits that load across three roles, and the agile roles and responsibilities below are the reason the job title “agile project manager” does not map cleanly onto any single one of them.
| Role | Responsible for | Not responsible for |
|---|---|---|
| Product owner | The goal, the scope and the order of the backlog. Decides what gets built next and what is dropped | How the work is done, or how long the team says it will take |
| Scrum master | Removing obstacles, protecting the process and coaching the team. A facilitator rather than a manager | Assigning tasks, setting priorities or owning the deadline |
| Development team | Deciding how to build the work, estimating it, and owning quality and delivery within the sprint | Choosing what the business needs most |
The third column matters more than the second. Most failed agile adoptions are a role boundary being crossed: a scrum master who assigns tasks, or a product owner who dictates estimates. The responsibilities a traditional project manager holds are distributed here rather than deleted, and somebody still has to hold each one.
Agile vs Waterfall: How They Actually Differ
Waterfall runs a project through sequential stages where each one finishes before the next begins, and scope is fixed up front. Agile runs it in repeating cycles where scope is expected to change. The practical difference is what happens when you learn something inconvenient halfway through.
| Question | Waterfall | Agile |
|---|---|---|
| What is fixed at the start | Scope. Time and cost are estimated from it | Time and team. Scope flexes to fit |
| When you see working output | Near the end, after the build stage | At the end of every iteration |
| Cost of a late change | High, because earlier stages are already signed off | Low by design, because the next cycle absorbs it |
| What it needs to work | Requirements that are genuinely knowable up front | An available customer and a team allowed to decide |
| Where it fits | Regulated, physical or fixed contract work | Products where the right answer has to be discovered |
The comparison is usually framed as a choice, and in practice it is not one. In Digital.ai’s 18th State of Agile Report, 74% of organisations reported using a hybrid, blended or homegrown model rather than a pure framework. Fixed budgets and fixed deadlines are ordinary commercial facts, and most teams run iteratively inside them.
Waterfall also gets described as obsolete more often than it deserves. It remains the sensible choice where requirements really are fixed and the cost of getting it wrong late is severe. Our guide to the waterfall model covers its stages and where it still applies.
Benefits of Agile Project Management
The benefits of agile project management all follow from a single mechanism: shortening the gap between building something and finding out whether it was right.
- Mistakes get cheaper. A misunderstood requirement caught in a two week sprint costs two weeks. The same mistake in a twelve month waterfall project surfaces at acceptance testing, when everything built on top of it has to move.
- Risk arrives early. Each iteration has to produce something that actually runs, so the integration problems that traditionally ambush a project in its final month turn up in its first.
- Priorities move without a renegotiation. Scope is an ordered list rather than a fixed contract, so a change in business priority means resequencing the backlog instead of raising a change request.
- Users get something before the end. Incremental releases put a usable version in front of people early, which also means the feedback that shapes the rest is real rather than hypothetical.
- Decisions sit closer to the work. Teams estimate their own work and choose how to build it, which cuts out a relay step between the person who sees the problem and the person allowed to act on it.
The Digital.ai survey adds a note of caution to the enthusiasm. 76% of respondents reported increased scrutiny of the business impact and return on investment of agile, and 52% named customer satisfaction as their main measure of success while 40% used efficiency or cost. Agile is increasingly being asked to justify itself in business terms, which is easier when the cost of the work is actually being recorded.
What Agile Does Not Fix
Most guides stop at the benefits, which is why searches for agile pros and cons exist at all. The failure modes are the more useful half, because they are the reason adoptions stall.
- Budgets. Flexible scope and an open ended budget are not the same thing, and agile only removes the first. Tracking cost per iteration is what keeps the first from turning into the second, and our guide to agile project budgeting covers how to do it.
- An absent customer. Every agile framework assumes someone can answer questions and react to what was built inside the cycle. Where nobody is available to do that, the feedback loop is decorative and the sprint review becomes a status meeting.
- Imposed adoption. Self-organisation cannot be mandated. Teams handed the ceremonies but not the authority to decide anything end up with the old process and more meetings in it.
- The wrong kind of work. Where requirements genuinely are fixed, or regulation demands a full specification before anyone builds, iterating adds ceremony without buying the flexibility it exists to provide.
- An unclear goal. Agile changes how you get somewhere. It does not decide where you are going, and a vague vision produces a backlog nobody can put in order.
Frequently Asked Questions
What is agile project management in simple terms?
It is a way of running projects in short repeating cycles instead of one long sequence. The team plans a small piece of work, builds it, shows it to stakeholders, and uses their reaction to decide what to do next. Scope is expected to change as the work reveals what is actually needed, which is the main thing separating it from traditional project management.
What are the 5 phases of agile project management?
Envision, speculate, explore, adapt and close, from Jim Highsmith’s Agile Project Management framework. Envision sets the vision and the team, speculate produces a provisional release plan, explore delivers working increments, adapt reviews results and revises the plan, and close transfers what was learned. Explore and adapt repeat for the life of the project. Other sources give four or six stages because they are describing different frameworks, not correcting this one.
What are the 5 C’s of agile?
There is no official set. The phrase appears in neither the Agile Manifesto nor the Scrum Guide, and at least four different lists circulate under the name. The most commonly cited version is communication, collaboration, commitment, customer focus and continuous improvement. Treat any source presenting one list as the definitive answer with caution, because another source will give you a different five.
Which is better, PMP or agile?
They are not alternatives. PMP is a certification for project managers awarded by the Project Management Institute, and its current content already includes agile and hybrid approaches. Agile is a way of working. The real question is usually whether to pursue a general project management certification or an agile specific one such as a Scrum Master credential, and that depends on whether your work is predictive, iterative or a mix of both.
Is agile still relevant?
Adoption remains near universal, but pure adoption does not. The 2025 Digital.ai survey found 74% of organisations running hybrid, blended or homegrown models, and 76% reporting more scrutiny of agile’s business impact than before. The honest reading is that agile has stopped being a movement and become a normal set of tools that now has to justify its cost like anything else.
What are the agile roles and responsibilities?
The product owner decides what gets built and in what order. The scrum master removes obstacles and protects the process without assigning work. The development team decides how to build it, estimates it and owns delivery within the iteration. Crossing those boundaries, particularly a scrum master allocating tasks or a product owner setting estimates, is the most common way an agile adoption quietly reverts to traditional management.
Key Takeaways
Agile is a response to a specific problem: projects where nobody can know the right answer at the start. It replaces one long plan with many short ones, and treats new information as something to act on rather than resist.
It is not a guarantee of speed, and it is not a substitute for knowing what you are trying to build. The organisations getting value from it are mostly the ones running it as a hybrid, keeping the iteration and the feedback loop while holding on to the budget discipline traditional planning was good at.
That discipline is where a time and cost record earns its place. Estimates improve when they are built from what similar work actually took, and an agile team that cannot see its own cost per iteration has no way to answer the return on investment question three quarters of organisations are now being asked.
To plan project scope, track how long work really takes and keep budgets visible while your team works in sprints, try actiTIME. It combines a Kanban board with estimate tracking, cost of work reports and project budgets, so progress and spend stay in the same place. Pricing starts at $5 per user per month, and you can explore everything during a free 30 day trial.
This article was originally contributed to actiTIME by Maria De La Pena, a Content Writer for the on-demand graphic design service Delesign, and has since been substantially revised and expanded by the actiTIME team.
