Daily Junction.mobi portalBusiness · January 13, 2024 · Tom Bennett · 6 min
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.
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.
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.
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:
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.
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, excels when the path is known; agile excels when it is not.
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:
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.
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:
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.
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 and depends heavily on bringing every stakeholder along, from the team to the customers.
Agile is a strong choice when:
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.
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.
![[View image]](/img/what-is-agile-project-management.jpg){kind=link}