Part 1: a different approach to planning and risk

I’ve already talked about how agile enables good prioritisation. This means you are doing the right things, and more importantly, you are doing fewer things at once. You can achieve so much more if you are focused on a few high impact pieces of work instead of trying to do a million things at once.

When this month (or this week, or this day), is all about getting this one very important piece of work done, you make a lot more progress. This doesn’t mean you can’t do those other priorities later, but limiting what you do at any one time stops you wasting time flitting back and forth between competing priorities.

So, the emphasis on agile in prioritising a few things – maximising the work you’re not doing at any one time – is really helpful. But there’s more to it than that. I’m going to explore one of the most important today, and then I’ll touch on others in future blogs.

Agile reduces risk

We don’t often think about it this way because it sounds very boring, but agile reduces the risk involved in your work. Agile emphasises working on a shorter timescale, not planning too far ahead and not going too long before you have an opportunity to stop and reflect. Very often, we plan in annual cycles, often developing our plans months and months before we actually implement then. But then things change – people leave, there’s a new opportunity or a competing product or a trend in the market. Planning well in advance means you can’t respond to those things.

Even if you could account for inevitable change, long-term plans would still turn out to be a bit rubbish. Our work is complex and we are notoriously bad at predicting how long things will take, what others will need or what barriers might crop up along the way. I’ve written embarrassingly many project plans that have turned out to be nonsense, and I’m sure you have too. I can probably map out the big milestones for a project, but for anything more granular than that, I am just guessing, and guessing badly.

Agile reduces the risks inherent in planning because it stops you from going into detail too far in advance. Since your plan is going to be nonsense, you might as well not waste time in developing it. Instead, think in shorter cycles. What do you want to achieve over the next fortnight, or the next month? You can make a much better plan for a short time-frame like that than a longer one. So plan for your short cycle, enact your plans and then stop and reflect on how it went.

The stopping and reflecting element is vital! This is how you course correct as you go along.

If you pause to think, you’ll realise you’re learning about your work and about how you are doing it all the time – and indeed you should be deliberately structuring your work to do this. Done well, agile turns some of your work into a series of experiments that help you learn more about your audience, the external market and what you’re trying to achieve. This allows you to iterate your way forward, avoiding the pitfalls you would otherwise have fallen into. It’s much less risky than the alternative, because you won’t go very far before validating your learnings.

This works for everyone

You may be reading this thinking this is all very well, but in no way applies to your work. Perhaps you have to work in an annual planning cycle because that’s how everyone else in your organisation does it. Perhaps you’re focused on a project that inherently involves longer cycles, like an event you deliver every six months. Perhaps the idea of not planning out your work in detail seems laughable.

I get it! I would have said the same for my work too a few years ago. Most of my career has involved delivering annual fundraising appeals. Each of these has a long list of deadlines spread out over many months. I need to be confident that we’ll hit those otherwise it will go disastrously wrong. Thinking on an annual cycle seems like the obvious and sensible thing to do.

Except that, as we’ve said, plans are rubbish. It turns out that you can take an agile approach to annual projects like mine too. I’ve already described how my team uses backlog refinement to prioritise. This is a big part of how we plan! We spend time at the start of the project thinking big picture about the outcomes we want to achieve, and what activities will be needed to support those. But we don’t map out those activities in detail until we come to them.

This doesn’t mean we miss those deadlines. We have a rough idea of when things need to happen at a high level, and we work around those. Each time we prioritise we naturally think about time-sensitive work and we plan for the short term accordingly. But we also think about the more important tasks that aren’t time sensitive. And we incorporate everything we’re learning so far, including a lot of up-to-date knowledge about interdependencies.

Instead of spending several weeks planning at the beginning of a project, we do a light touch plan and then invest an hour or so each month in planning for the upcoming month. This saves us time overall and leads to much better, more informed results.

I’d love to hear from you – what’s your planning process like and do you experience some of these pitfalls?