Never Stop Planning

It's true that no plan survives contact with the enemy, but that doesn't diminish the value of planning. After all, it's pretty hard to achieve anything meaningful if you don't have an approximate idea about how you're going to get there.

Planning takes time and effort though, and if you try to do it all at once, that time and effort can seem insurmountable.

So, I suggest not doing that.

It Is Foreseen

Plans are only relevant for a specific period of time.

A good example of this is a sprint plan, which is a body of work that should ideally be completed over the next week or two. It's small enough to maintain flexibility in the face of reality shifts, but it's meaningful enough to actually move an agenda forward.

Planning for a sprint is generally a one and done activity.

Get the team together, agree on a theme or goal, pull a bunch of work from the backlog to either achieve that goal or move toward it and then get cracking.

However, if you try to apply the same model to planning for a longer period of time, like a quarter or year, it doesn't work nearly as well.

The first problem with doing concentrated planning for a longer period of time is that it creates a monstrous amount of stress for everyone involved.

When you combine the desire for certainty with shifting business priorities and then add in tight timeframes, you've got a recipe for high cognitive load and thus stress. This is particularly painful for the people who are trying to facilitate the planning and push towards an outcome, but it doesn't do the contributors any favours either.

The second problem is that any decisions made during such focused planning are probably lower quality than they could be.

It takes time for people to digest information, understand it and figure out the best way to move forward, and in my experience, there really isn't a way around this. Sure, you can push for a decision, but it's going to come with assumptions and trade-offs, and the people involved might not even be aware of what those assumptions and trade-offs are, let alone be able to communicate them clearly.

The good news is that you can just avoid both of those problems by just avoiding the situation entirely, while still delivering high quality plans.

Change Was Inevitable

In short; never stop planning.

There is a reason I named this blog post what I did.

This is otherwise known as continuous planning and the gist of it is that you do a little bit of planning on a regular basis as you lead up to the next period of time. It doesn't matter if its a quarter or a year, it still works exactly the same.

When the time comes to finalise things, there is no big, exhausting planning event to deal with, you just take a snapshot of your current plan, maybe tweak it a bit to make sure it's as up to date as it can possibly be and then move on with your life.

Also, because you're always thinking about what's coming next, everyone can incrementally build up their context over time. This not only gives people the time required to digest the information, but it also means that they don't have to cram, which is a hell of a lot less stressful.

Mechanically, actually doing continuous planning is relatively straightforward. It really only requires two things:

1. Have a project backlog
2. Regularly groom said backlog

For the project backlog, the goal is to have a system of record for all of the work that you could be doing.

In order for such a backlog to be effective for continuous planning, it needs:

• A way to indicate in advance when work might be done. This allows you to move work around based on changing circumstances and helps to focus the conversation further by letting you winnow down a list of candidates for the next period as the planning progresses
  • For me, this is a quarters field in JPD
• A way to reason about priority. As the business situation evolves, the items in the backlog need to be continually re-evaluated from a priority point of view, so you need to be able to reason about their current priority clearly
  • For me, this is either the order of the projects (i.e. top = most important) or a specific priority field that can be used to be more specific
• A way to reason about capacity. When you're planning the next period, you need to have a sense of just how much work you can commit to, in order to make decisions about what is in and what isn't
  • For me, this is a combination of project level estimates and a comparison against the total capacity available

There is more to a good project backlog than the scattering of points above, but that should be enough to get started. If you want more information, head over to this blog post. It's got all the detail you could ever want, including examples.

With a project backlog in place, you then need to actually use it.

The goal here is to actually have conversations around the items in the backlog on a regular basis, building context in the relevant people, fleshing things out and ideally, making decisions around what is and isn't in scope for the next period of time.

Mechanically I suggest a weekly session with a group of leaders in the area that you need to do planning for. An hour should be more than enough if you have a good facilitator to keep things on track.

It's unlikely that you will have so many candidate pieces of work for the next period that you can't just walk through it from top to bottom with the entire group on a regular basis, and then when it comes time to dig into the details, break out into smaller groups to give people the focus they need, with the expectation that they feed their decisions and other conclusions back into the items in the backlog.

That's it! Just two things and you're on your way to continuous planning!

So simple. Absolutely no complications or challenges worth mentioning...

Problems Are Just Opportunities

I lied, there are definitely complications and challenges.

First of all, don't get too attached to your early plans.

As you do continuous planning you'll eventually get to a point where you feel like you have a pretty good handle on the next period, probably well in advance of the period actually starting.

If you're lucky, nothing will disrupt that initial plan.

However, if you live in reality like the rest of us, a bunch of stuff will change, and you'll need to adapt and adjust. Maybe another team will actually do their own planning and figure out that they need your help, maybe the business will shift directions subtly and invalidate the things you were going to do or maybe you will just realise that that initial plan was completely impossible to deliver on as you continue to explore the work.

The time spent planning initially was not wasted, no matter how it feels emotionally, so accept that change is inevitable and move on.

The second thing to note is that you will need a driver.

I have yet to meet a group of people who are doing continuous planning consistently, without having at least one or two specific people in that group who are making sure that it actually happens.

That's not a mark against the people I've been working with over the years or anything, it's just that without a concrete driver, things tend to fall by the wayside more quickly than you expect.

The natural driver for continuous planning in an area is the owner of that area, who is probably the one most interested in having a cohesive plan for how to move forward. It doesn't have to be them; that's just the easiest option because they generally have hierarchical power to make sure the planning actually happens.

The last thing that can be challenging when doing continuous planning is dealing with external asks.

When you're the master of your own domain, with little to no external influences, continuous planning is relatively easy. You've got plenty of ideas, you prioritise them as necessary, explore the more promising or important ones and use that information to form a plan incrementally over time.

When you have other teams that rely on you to accomplish basically anything, the situation gets significantly more complex.

They might not be doing continuous planning themselves, so you may be assailed by a blistering fusillade of asks just when you think your plan is fully solidified, forcing you to rethink everything.

All Part of the Plan

Continuous planning is not a silver bullet. It does not solve all of the problems that you will run into when trying to organise the work for a group of people.

It is significantly better than trying to jam all of the planning into a short period of time though and I have absolutely no regrets around establishing continuous planning as the dominant process within my area in Atlassian.

Not only am I less stressed at the end of the quarter when it comes time to solidify things and share planning snapshots with the rest of the business, I'm pretty sure our plans are of a higher quality and lead to better outcomes as well, because we've had more time to mull them over in the back of our minds.

Just as planned.