Is Agile Just an Excuse to Avoid Planning?

There is a particular kind of silence that happens in a steering group when a delivery lead says the team doesn't have a fixed plan for month four yet. The sponsors shift slightly. Someone glances at their notes. It isn't hostility, not quite. It's the sound of people who have spent a career being told that a project without a plan is a project heading for trouble, watching a team stand up and say, more or less, that they'll work it out closer to the time.

It is a fair reaction. Anyone trained in a governance-led environment, PRINCE2, MSP, a formal PMO, learns early that a plan is the thing that lets a sponsor sleep at night. It sets expectations, allocates resource, gives everyone a shared picture of where the project is going and when. So when an Agile team turns up with a backlog instead of a Gantt chart, and talks about the next two weeks rather than the next six months, the natural conclusion is that planning has quietly been dropped from the process. That the team has found a more comfortable way to describe not knowing what happens next.

That conclusion is understandable. It is also wrong, and worth taking seriously enough to actually pull apart rather than wave away.

Start with what a plan is actually for. In a plan-driven environment, a plan exists because the cost of being wrong later is high, and because most of what will happen can reasonably be known now. A construction programme, a system migration with fixed regulatory dates, a change with hard external dependencies: these are contexts where the information needed to plan accurately already exists at the start, so front-loading the plan makes sense. You commit early because early commitment is cheap and reliable.

Agile delivery tends to sit in a different kind of problem. The requirement itself is often not fully knowable at the start, not because nobody bothered to find out, but because the answer depends on things that only become clear once real users interact with real functionality. A product team building a new customer portal genuinely does not know, in week one, exactly what the third release should contain, because that depends on what the first two releases teach them. Planning that in detail at the outset would not be more rigorous. It would be more confident-sounding and less accurate, a plan built on assumptions dressed up as facts.

This is where the framing shifts. Agile does not remove the discipline of planning. It relocates it. Backlog refinement is planning. Sprint planning is planning, done in shorter, more frequent cycles instead of one long upfront pass. A well-run product backlog, properly prioritised and refined, contains as much decision-making rigour as a project initiation document, it is simply distributed across the life of the delivery rather than concentrated at the front of it. The team hasn't skipped the conversation about scope, sequence and risk. They have moved it to sit next to the moment the relevant information actually exists, rather than trying to have it three months early on a guess.

A PMO manager once described watching this play out from the other side of the table. She had spent years running structured programme offices, and her first exposure to a genuinely well-run Agile team left her uneasy, because there was no baseline document she could point to and say "this is the plan." What changed her view wasn't a conversation, it was watching the team's sprint reviews over about six weeks. Every session, decisions that would ordinarily have sat in a change control log were being made in the room, in front of the sponsor, with the same rigour, just faster and closer to the point of delivery. Nothing was being skipped. It was simply happening on a two-week cycle instead of a six-month one, and the paperwork looked different because the rhythm was different.

None of this means Agile is planning-agnostic, or that every team calling itself Agile is doing this well. Plenty of teams do use the language of iteration as cover for genuinely poor discipline, backlogs that are really just to-do lists, sprints with no clear definition of done, a roadmap that changes because nobody committed to one rather than because new information justified the change. That failure mode is real, and it is precisely what makes sceptics in governance-led organisations reasonably wary. But the failure is a symptom of Agile done badly, not evidence that Agile itself is structurally incapable of planning. A PRINCE2 project run without proper stage boundaries fails for the same underlying reason: not because the framework doesn't work, but because someone skipped the discipline the framework depends on.

The more useful question, then, is not whether Agile plans, but whether a given delivery is actually earning the right to plan iteratively, refined backlogs, clear sprint goals, a genuine definition of done, visible prioritisation logic, or simply using the word as licence to avoid commitment altogether. That distinction is the one worth testing in the room, not the label on the methodology. If you're trying to work out where your own delivery sits on that line, or how to reconcile the two worlds without abandoning either one, get in touch about your training options.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.