On planning, part 5: exploration March 17, 2025

This is the fifth and last post in my series about planning in the context of agile teams.

• Part 1 is concerned with why you should plan at all.
• Part 2 describes my iterative approach to end-to-end planning.
• Part 3 shows how I do forwards and backwards planning.
• Part 4 demonstrates how I use the critical path.

In this post, I will explore … exploration.

Happy path planning

We'll start with a very simple plan. The following picture shows how to get from Krottenkopfstraße in Munich to the hospital Klinikum Großhadern.

You start off going north, turn 5 times, and you are there. The street names are on the plan. What more do you need?

If everything goes well – nothing. If everything goes well, you will get from here to there using only this plan. If everything goes well. How likely is that? In this particular example, and if you are walking, it is pretty likely. If you are going by car, it's a little less likely. There may be construction work blocking a street, traffic jams, or you might not find a parking space once you are there. What are you going to do then?

This plan is fragile in the sense that it works while you can follow it strictly, but if you deviate from it even slightly, it can no longer tell you what to do. And this is a very simple plan for a very simple ‘project’. If your undertaking is more complex – say, like a software development project –, something is bound to go wrong, where ‘wrong’ means deviating from the happy path.

Now, you might say, this is a stupid example. Obviously, I got the route from OpenStreetMap, and why would I blank out everything but the chosen route? Why not show the whole map so I can immediately see alternative routes if I need them? And you'd be right. Here is the map, including the route.

With this map, my plan becomes much more resilient: if I deviate from the route, the map allows me to find back to it or to quickly choose a new route to the target if this seems more appropriate. If getting from here to there is in any way important, I'd be stupid not to use the map if I have it available.

But how often do we have such a map when embarking on a software development project? The plans I have seen often resembled the first picture much more than the second. This is what I call ‘happy path planning’. It presupposes that all will go well and makes little provision for unexpected obstacles.

Ask, ‘What can go wrong?’

If and when I make plans, I always think about things that could go wrong. I explore what could go wrong and think about appropriate responses and alternative ways forward.

I make a point of not being content after devising the first possible plan that could work out (if everything goes well), but to think about other options we have and risks associated with each of them. For example, I can do even better in the routing example above by including the timetable of the subway line U6 in my plan because it could take me most of the way if I wanted to. It adds another option.

I examine the dependencies among tasks and possible orderings. If doing the tasks in one order results in a bottleneck (especially one at a later stage of the project), and doing them in another order increases flexibility, I prefer the latter.

In effect, I am building a map that not only shows one single path but a web of paths, so if some obstacle blocks our way, a solution becomes apparent quickly by looking at the alternatives I have considered. Having this map enables me to respond to change better. (Remember this? It is one of the values from the Manifesto for Agile Software Development.)

This doesn't mean that I don't have a preferred way forward. I do plan a route – a ‘happy path’ – on this map. But – and this is a big ‘But’ – I am prepared to respond to changing circumstances much better than if I had only considered the happy path.

Also, simply knowing that we have fallback options provides much-needed ease of mind in times of high pressure. And this ease of mind sometimes allows us to perform feats that are impossible when we are stressed out. ‘We would like to get this subtask done before the deadline, but we could deliver it later if necessary,’ can take out so much pressure. So maybe having this plan is what allowed us to succeed, even though – on the surface – we did not actually ‘need’ any of those alternatives.

Here we are with general Dwight Eisenhower again:

Plans are useless but planning is indispensable.

Having planned this way (and having built a map around our plan), we are prepared for whatever life will throw at us, regardless of how much of the initial plan actually works.

Conclusion

That's it for my ‘planning’ series. It has gotten much longer than I had planned (hah!).

In conclusion, yes, I think planning is important, even for agile teams, especially if they take on larger pieces of work, have to deal with deadlines, or depend on external resources which may not be easily available. I use forwards and backwards planning to come up with an end-to-end plan that I refine continuously. When dealing with deadlines, I use the concept of the critical path to ensure my plan fits the available time. And I draw up not only the happy path where nothing must go wrong, but I also explore risks and alternatives to be prepared for change because everything flows.