Agile Didn't Kill Planning. It Rescued It.

I've spent about thirty years in enterprise IT. Some of that as a Scrum Master, most of it building, running, and now leading infrastructure. And in all that time, one claim keeps resurfacing in a form I've never been able to let go:

We're agile, so we don't really plan.

I've heard it from junior engineers who picked it up secondhand. I've also heard it from people with certifications on the wall, said with total confidence, treated as settled ground rather than a position that needs defending. That second group is the interesting one. Because the training they took teaches the opposite, and somewhere between the classroom and Tuesday morning, the meaning drifted.

I want to make the case that the drift runs backwards from what most people assume. Agile didn't reduce planning. Agile exists because planning was broken, and it was an attempt to fix it.

The sentence nobody quotes

The Manifesto for Agile Software Development is four value statements and twelve principles. It fits on a page. It has been in the same place, largely unchanged, since February 2001.

The line everyone remembers is the one that ranks responding to change above following a plan. Fair enough. It's the memorable half.

The half nobody quotes sits directly underneath all four value pairs, and it says that while there's value in the items on the right, "we value the items on the left more."

That's it. That's the whole ballgame.

It's a statement of preference under tension. Not a deletion. The plan keeps its value, explicitly, in the same breath, on the same page, from the same seventeen authors. It reads like fine print, and it gets treated like fine print, and it is in fact the sentence that settles the argument.

Go read it yourself. It takes ninety seconds: agilemanifesto.org

What the old way actually got wrong

Here's the part I think gets misdiagnosed, and it matters because the misdiagnosis is what produced the drift.

The methods Agile reacted against did not plan too little. They planned enormously. Months of it, up front, producing documents that were comprehensive, authoritative, and stale by the time anyone acted on them.

And the sheer cost of producing all that made it rigid. When reality diverged from the plan, changing the plan cost nearly as much as writing it had. So the plan usually won and reality got managed around it. Requirements that turned out to be wrong got built anyway, because the alternative was reopening a document that took a quarter to close.

The outcome still came out wrong. Just later, and more expensively.

Do that to a person enough times and they don't conclude "we should plan differently." They conclude "planning is theater." That's the lasting damage, and I think we're still paying it down twenty-five years later.

What actually changed

Agile pulled planning out of a phase and put it inside the work.

Smaller pieces. More often. Close enough to real feedback that you find out quickly whether you were right. Three things changed, and none of them is less:

Cheaper planning is repeatable planning. Repeatable planning is worth doing honestly instead of defensively. And planning you do honestly is the only kind that's ever been worth anything.

So when someone frames Agile and planning as opposites and asks you to pick a side, the frame itself is the error. Agile brought planning front and center and put it directly in the action. That is the opposite of removing it.

Count the ceremonies

If the argument still feels like interpretation, make it countable. Here's where planning sits in the frameworks people actually cite.

Scrum has Sprint Planning as a formal timeboxed event, up to eight hours for a one-month Sprint, organized around three questions: why this Sprint is valuable, what can be delivered, and how the work gets done. The Sprint Backlog is described in the Guide as the Developers' own plan. All three artifacts carry commitments: a Product Goal, a Sprint Goal, a Definition of Done. Backlog refinement runs continuously. The Daily Scrum is a fifteen-minute re-planning event. And on protecting the plan once made, the Guide is blunt: "No changes are made that would endanger the Sprint Goal."

Three commitment devices and five planning touchpoints, in a framework people describe to me as anti-commitment.

SAFe runs PI Planning: a two-day event where every team on a release train plans the next eight to twelve weeks together. Fifty to a hundred and twenty-five people in one room. Scaled Agile's own line is that if you're not doing it, you're not doing SAFe.

Kanban is the one usually reached for as the flexible alternative, generally by people who know the board better than the rest of the method. Four of its six core practices are planning or governance: limit work in progress, manage flow, make process policies explicit, implement feedback loops. It also defines replenishment meetings, service delivery reviews, and forecasting from historical throughput. And WIP limits are a harder constraint on interrupt work than Scrum is, not a softer one. In a pull system, nothing new enters until something else visibly stops.

DSDM fixes time and cost and flexes scope. Its handbook has a chapter titled Project Planning and Control.

One more, and it's my favorite for ending these conversations quickly. Mike Cohn, a founder of the Scrum Alliance, published a book in 2005 called Agile Estimating and Planning. If Agile were opposed to planning, that book would be four pages long and mostly blank.

Where the drift actually comes from

I want to be careful here, because the people making this argument are usually not lazy and usually not wrong about much else.

Some of us learned Agile secondhand, from a previous team or a job where it was already running by the time we arrived. Others learned it properly, in a certification course, from the actual material. Either way, the same thing tends to happen next. The framework gets adapted to fit a team. The adaptations pile up over a few years. Nobody goes back to the source. And eventually "agile" means, locally, whatever the last three teams did with it.

That's the drift. And notice it runs the opposite direction from how these conversations usually go, because the formal training is on the correct side. If you took a CSM or PSM course, you were taught Sprint Planning as a timeboxed event, the Sprint Goal as protected, and the Product Owner as a single ordering authority. If you took a SAFe course, you spent a lesson inside a two-day planning event.

The training teaches the planning. It always has. Which means the correction isn't a challenge to anyone's credentials. It's a return to them.

It also means "you're wrong about Agile" is the least effective thing you can say. That's a competence claim about a person. "Our practice drifted from the material" is a claim about a process, it's true of almost every team eventually, and it's fixable by rereading rather than by anyone conceding.

What this looks like in infrastructure work

I lead an infrastructure team now, not a software team, and the fit is imperfect in ways worth naming. We inherit systems we didn't build. We can't ship a broken increment and fix it Tuesday. Our users notice immediately when we're wrong. And we carry an operational load that no framework handles gracefully out of the box.

Three things have held up.

Reserve explicit capacity for interrupts, and cap it

We route unplanned operational work through a rotating on-point role with a hard ceiling on any single item. Above that ceiling, you stop and escalate. Reserving capacity for interruptions is how you stay responsive without letting responsiveness consume the whole commitment.

But the cap is a stop sign, not a budget. That distinction is the one I've had to make most often. Being able to absorb a four-hour item doesn't mean you should, and it never means the planning was optional. Anything with an unknown inside it is unscoped work carrying an optimistic estimate, regardless of how small the estimate is.

Let work earn its way into the backlog

Work that's real but not ready lives in a planning document: direction, rough scope, known dependencies, open questions, no estimates pretending to certainty. It enters the backlog one or two sprints before pickup, which is when refining it pays off instead of going stale. Then it enters a sprint.

A backlog stuffed with unrefined future work is noise, and noise makes the real queue harder to read. Something being important is not a reason to put it in the backlog. Something being nearly ready is.

Notice that every item in that pipeline gets planned three separate times, at increasing fidelity, and nothing skips a stage. That's the cleanest answer I know to "planning isn't agile."

Make the plan in front of other people

Infrastructure attracts people who are good at solving things alone, fast, without asking. That capability is real and I don't want to breed it out of anyone. But it's a mode, not a default, and Agile is unusually clear that the default is the team. The first value is half about interactions. Every collaboration principle is written in the plural. Scrum locates the Sprint plan in the Developers as a group, and the 2020 Guide specifically removed the Development Team as a separate unit inside the Scrum Team to kill team-within-a-team behavior.

Ten minutes at standup routinely saves a day. I've watched it do exactly that more times than I can count.

The short version

Agile didn't take planning away. It took away the part of planning that never worked: the front-loaded, high-fidelity, expensive-to-change document that was wrong on arrival and too costly to fix.

What's left is planning that's cheap enough to do often and honest enough to be worth doing at all.

If someone tells you otherwise, ask which framework and which passage. Every source above is free, public, and short. The Manifesto is one page. The Scrum Guide is about thirteen. Twenty minutes of reading settles most of it.