It's planning season at work. We are high trust, high agency, and minimise collaboration. It is pretty common for folk to change their plans and they do so without needing to seek approval.

So why do we run planning sessions at all?

My favourite quote is "The plans are useless, the planning is essential" (which you'll find in a few forms if you go a'googlin')

But why are the plans useless?

Torture a metaphor? If you insist…

The landscape you're building software in probably doesn't look like this:

We're generally operating under imperfect conditions. Trying to figure out where we are is more like being in the fog:

A friend was for a while a member of mountain rescue (who are incidentally incredible - you should give them money). They once described to me how they navigate when they have very low visibility.

In pairs:

• use the map to figure out where you are
• use that information to figure out what direction to go
• using a compass one of you slowly walks in that direction
• the other stays still and calls out when the walker is about to disappear into the fog
• then that person catches up with the walker
• repeat

Looking at the context of where they are against what they know about the world. Working together to understand what that means, right then. Watching each other and relying on communication. Chopping the journey into many safer parts.

The navigation completely falls apart without a map. It requires the wider context.

But surely you can't keep going with this metaphor?

When we're hiking my wife, who is a competent navigator, will ask me: "why is your thumb there (on the map)?". I explain it's where we are. And she will point out distant landmarks to triangulate how wrong I am.

Her navigation is better because she is looking at the bigger picture. Whereas I'm counting field boundaries.

Even once we have the map and the route, we still need to navigate by looking at the landscape and landmarks to stay on course.

OK, we're done now with the hiking metaphor now, surely?

Well, why was I counting field boundaries? Once we have the map and the route we have our plan. But when you try to follow it, you discover all the things that make it difficult. A copse of trees was cleared. A farmer moved a style. A path is impassable because of thorns or mud.

The route very quickly becomes a series of small decisions and adjustments as you navigate around obstacles. You can't make those adjustments with a static plan. You can make them because you have practised making the route. You know why it is the route and so you can adapt it to changing conditions.

The actual plan is the starting point. The thing we thought would meet our goal before reality hit us over the head.

Please no more metaphor

In all of these scenarios the planning doesn't get you anything without execution - no point planning a hike and not walking. But the planning has to happen to make the route any good.

That's what good "modern" software teams do. They have a series of nested loops and they check themselves at each point. Short term loops like daily standups that focus on the next few hours. And long term loops like quarterly planning that focus on the next few months.