Plan, Adapt, Repeat

Every quarter, it’s the same struggle. Stakeholders want to know what the team is going to deliver and when. Developers don’t want to hear any of it: “We are builders, not fortune tellers. We can’t foresee the future, so don’t ask us to!”

That reaction doesn’t come out of nowhere.

For decades, businesses and project managers have been sold on the idea that the future can be known if you think hard enough upfront. Ask for estimates, stack them into a timeline, announce a date, and assume it will just happen. But when it doesn’t — because it never does — it’s always the team who takes the heat.

It’s no surprise developers started dreaming about “no estimates.” If every plan ends up being wrong, why keep pretending at all? Why not just let development take as long as it needs, and stop wasting time defending guesses? After all, isn’t agile about delivering continuously?

In reality, both sides get it wrong. One side believes uncertainty can be eliminated through careful preparation. The other thinks uncertainty can be avoided by refusing to plan. Both are comforting fantasies that don’t work in real life.

Agility isn’t about speed, precision, or delivering more. It’s about the ability to adapt when reality diverges from expectations. That divergence isn’t a failure; it’s just a fact of life. Small cycles don’t exist to avoid planning. They exist to confront reality early and correct course before the gap becomes too large.

At the same time, businesses can’t operate on a two-week horizon. Teams don’t work in isolation. Hiring, budgeting, coordination, dependencies — all of that requires looking ahead. Planning isn’t about squeezing performance out of the team. It’s about alignment. There is no escaping that.

The real problem isn’t planning. It’s what people think a plan is.

A plan is not a promise. It’s not truth. It’s not a commitment to an outcome.

A plan is a hypothesis – a projection based on what you know today. It’s full of assumptions, and the further it goes into the future, the more likely those assumptions are to break.

A plan only works when everyone agrees it’s provisional — valid for alignment today, but expected to change as execution reveals what we didn’t know yet.

Once that’s explicit, the path forward becomes clear: treat planning itself as an agile practice.

Plan far enough to align people, surface assumptions, and identify risks. Execute in short cycles, confront reality early, and adapt the plan as assumptions break and new information appears. Keep stakeholders in the loop so they can adapt their own plans too. Then repeat.

Planning isn’t committing to a lie. It’s offering a hypothesis instead of silence. Plans don’t exist to provide guarantees. They exist to provide alignment in an uncertain world.

We can’t foresee the future. But we should still make plans.

Topics:

About the author

I'm Pablo Borowicz, a veteran engineering leader. I write about software development, leadership, and more.
More about me