# What Is Agile Project Management?

> Agile project management is an approach that delivers work in small, frequent increments and adapts the plan as you learn, rather than following one fixed plan from start to finish.

*Section: Business — By Tom Bennett (Sports Writer) — Published January 13, 2024 — 6 min read*

Canonical URL: https://dailyjunction.co.uk/business/what-is-agile-project-management
Tags: agile, project management, scrum, kanban, ways of working

## Key takeaways

- Agile project management breaks work into short cycles, delivering usable increments often and adjusting the plan based on feedback.
- It grew from the 2001 Agile Manifesto, which values working results, collaboration and responding to change over rigid plans and documentation.
- Scrum and Kanban are the two most common frameworks: Scrum uses fixed-length sprints and set roles, while Kanban focuses on continuous flow and limiting work in progress.
- Agile suits work where requirements are uncertain or likely to change; the traditional waterfall approach suits stable, well-defined projects.
- Agile is a mindset, not just a set of ceremonies; copying the rituals without the culture rarely delivers the benefits.

For decades, the standard way to run a project was to plan it all up front, then execute that plan step by step. It worked well when you knew exactly what you were building. But for work full of uncertainty — software, new products, fast-moving markets — fixed plans kept colliding with reality. Agile is the response: an approach built around the assumption that you will learn and change as you go. This guide explains what agile project management is, where it came from, how its main frameworks work and when it is the right choice.

## What it is

**Agile project management is an approach that delivers work in small, frequent increments and adapts the plan continuously based on feedback, rather than following a single fixed plan from start to finish.** Instead of one long march to a distant deadline, agile teams work in short repeating cycles: plan a little, build a little, review, and adjust.

The core idea is to treat a project as a series of experiments rather than a prediction. You produce something usable quickly, put it in front of users or stakeholders, learn from their reaction, and feed that learning into the next cycle. This makes agile especially powerful when you cannot know everything in advance — which, for most modern work, is the norm.

## Where agile came from

Agile is not a single tool but a philosophy, set out in the **Agile Manifesto** of 2001. A group of software developers, frustrated with heavy, document-driven processes, wrote four values that still define the movement. They said they had come to value:

- **Individuals and interactions** over processes and tools
- **Working software** over comprehensive documentation
- **Customer collaboration** over contract negotiation
- **Responding to change** over following a plan

Crucially, they noted there is value in the items on the right — but *more* in those on the left. Agile does not mean no planning or no documentation; it means not letting either become more important than delivering something that works and adapting when circumstances shift.

## Agile vs waterfall

To understand agile, it helps to contrast it with the traditional **waterfall** approach, where a project flows through sequential phases — requirements, design, build, test, release — each completed before the next begins.

| Aspect | Waterfall | Agile |
|--------|-----------|-------|
| Planning | All up front | A little each cycle |
| Delivery | One release at the end | Frequent increments |
| Handling change | Costly and resisted | Expected and welcomed |
| Best for | Stable, well-defined work | Uncertain, evolving work |
| Feedback | Late, after build | Early and continuous |

Neither is "better" in the abstract; they suit different situations. Building a bridge to a fixed specification is a waterfall job — you would not want to "iterate" on the foundations. Developing an app whose features depend on how users behave is a job for agile. A traditional plan, often visualised with a [Gantt chart](/business/what-is-a-gantt-chart), excels when the path is known; agile excels when it is not.

## Scrum: working in sprints

The most widely used agile framework is **Scrum**. It organises work into fixed-length cycles called **sprints**, usually one to four weeks, each producing a usable increment. Scrum adds structure through defined roles and events:

- **Roles** — a *Product Owner* who decides priorities, a *Scrum Master* who keeps the process healthy, and the *development team* who do the work.
- **The backlog** — a prioritised list of everything that might be built, from which each sprint draws.
- **Ceremonies** — sprint *planning* at the start, a short *daily stand-up*, a *review* to show what was built, and a *retrospective* to improve how the team works.

The rhythm matters as much as the rules. Each sprint is a complete loop of planning, building and reflecting, so the team improves both the product and its own process a little every cycle.

## Kanban: managing flow

The other common framework is **Kanban**, which is less prescriptive than Scrum. Instead of fixed sprints, work flows continuously across a board with columns such as *To Do*, *In Progress* and *Done*. Two ideas are central:

1. **Visualise the work** — every task is a card on the board, so the whole team can see status at a glance.
2. **Limit work in progress (WIP)** — capping how many items can be in each column at once. This stops everything being half-finished and exposes bottlenecks where work piles up.

Kanban suits teams with a steady stream of incoming requests — support, operations, content — where fixed sprints feel artificial. Many teams blend the two, sometimes called "Scrumban," taking sprints from one and flow limits from the other.

> Scrum gives you rhythm and structure; Kanban gives you flexibility and flow. The right choice depends on whether your work arrives in plannable batches or as a continuous stream.

## It is a mindset, not a ritual

The most common way agile fails is when an organisation adopts the *ceremonies* — the stand-ups, the boards, the sprint names — without the underlying *culture*. You can hold a daily stand-up and still micromanage; you can run sprints and still refuse to change the plan when feedback demands it. That is "going through the motions," and it delivers little.

Real agility depends on culture: trusting teams to make decisions, welcoming change rather than resisting it, and genuinely collaborating with the people the work is for. Because it changes how people work, not just what tools they use, an agile transition is itself an exercise in [change management](/business/what-is-change-management) and depends heavily on bringing every [stakeholder](/business/what-is-a-stakeholder) along, from the team to the customers.

## Where agile fits

Agile is a strong choice when:

- Requirements are unclear or likely to change.
- Early and frequent feedback is valuable.
- The team can deliver work in small, usable pieces.

It fits less well when the outcome is fixed and predictable, when regulation demands extensive up-front documentation, or when "delivering increments" makes no sense for the work. In those cases a more traditional plan is often the better servant. The mature view is not "agile good, waterfall bad," but choosing the approach — or a blend — that suits the work in front of you.

## The bottom line

Agile project management delivers work in short, repeating cycles, releasing usable increments often and adapting the plan as you learn — a deliberate alternative to fixed, plan-everything-up-front approaches like waterfall. It is rooted in the Agile Manifesto's preference for working results, collaboration and responding to change. **Scrum** brings structure through sprints and roles; **Kanban** brings flexibility through continuous flow and limited work in progress. But the frameworks are only the visible surface: agile delivers its benefits only when the mindset of trust, feedback and adaptability comes with them. Choose it for uncertain, evolving work, and treat it as a way of thinking, not a checklist of rituals.

## Frequently asked questions

### What is agile project management in simple terms?

It is a way of running projects by doing the work in small chunks, releasing something usable frequently, getting feedback and adjusting as you go. Instead of locking down every detail at the start and following that plan for months, agile teams plan a little, build a little, review and repeat. This makes it easier to cope with changing requirements and to deliver value sooner.

### What is the difference between agile and waterfall?

Waterfall runs a project in sequential phases — requirements, design, build, test, release — each finishing before the next begins, following one plan throughout. Agile works in repeating short cycles, delivering increments and revising the plan with each round of feedback. Waterfall suits stable, well-understood projects; agile suits work where requirements are uncertain or likely to change.

### What is the difference between Scrum and Kanban?

Both are agile frameworks. Scrum organises work into fixed-length sprints, usually one to four weeks, with defined roles and regular ceremonies such as planning and a review. Kanban is less prescriptive: work flows continuously across a board and the focus is on visualising the flow and limiting how much is in progress at once. Scrum adds structure and rhythm; Kanban adds flexibility.

### Is agile only for software development?

No. Agile started in software and is still most associated with it, but the same principles are now used in marketing, product design, operations and beyond. Any work that benefits from delivering in increments, getting feedback and adapting can use agile ideas. That said, it fits poorly where the outcome is fixed and predictable, where a more traditional plan often works better.

## Sources

- [Manifesto for Agile Software Development](https://agilemanifesto.org/)
- [Association for Project Management (APM): What is agile?](https://www.apm.org.uk/resources/find-a-resource/agile-project-management/)

---
Daily Junction — https://dailyjunction.co.uk/business/what-is-agile-project-management