Ideas Behind Agile Planning: It Helps to Have a Plan

September 21, 2020

Revised: 11/21/2020 (Original: 9/21/2020).

This idea is a bit controversial, depending on who you talk to.

First, let’s agree partly with the opposite idea.

It can be painful to have a plan. It can hurt. Especially if managers will lock the “delivery date” in stone, as we say, and want to punish us if we are a late (it is usually that lateness, usually by more than 1 day, that is the biggest problem).

So, let’s agree that a plan is always a guess, and guesses, as in poker, are likely to be wrong usually. The real question is how much they will be wrong. So, being punished for making a guess is not useful.

Equally, not improving your guesses, and especially not learning from the guesses…those behaviors are also not good.

OK, so how can it help to have a plan?

First

Because in general, a plan is wanted, needed, and in some sense required.

Yes, there are situations where we have no half-way good guess. And I suppose also, we have people who will not listen to reason, and understand large uncertainties.

But from my experience, those situations are relatively few.

The customers and the managers need to have an idea when Product X will be delivered. The delivery date affects other things, other actions. So, at some point, we must give them some idea. To be responsible and a bit fancy, we might also give them our confidence interval (how likely that outcome it to occur).

Second

The initial guess makes us think. And thus improve the guess.

We should never suggest that any plan is perfect. They are all guesses about the future. In a probabilistic universe, every guess will be followed by results that vary from the guess. This variation might be wider some times, and narrower other times. But always the variation is significant.

Minor point: The longer to the finish date, the higher the typical variation from our guess.

Third

The current plan enables the Team to make decisions. Quickly. It concentrates the mind in the land of uncertainty.

In most cases, making decisions quickly leads to faster learning, and therefore to faster real delivery.

Fourth

The act of making a plan forces us to address, in a small timebox, a series of hard questions or hard issues. This clarifies the issues in our minds. The team can then notice more easily if our assumptions, or some of them, are starting to be wrong. We can adjust faster and better.

Fifth

Once we have done a quick and complete plan (in the sense of covering all dimensions), we can prioritize our stupidity. Once we see the weaknesses or lack of knowledge embedded in the plan, we can take action to learn in the best areas.

Sixth

We can revise it. The Plan.

To state the obvious: It is hard to revise a plan that does not exist.

More insightfully: as we hinted earlier, making a plan clarifies for those participants the assumptions they made and the choices they made. Their minds are then in a better position to scan the universe for confirmation (yes, confirmation bias) or contra-information to those assumptions or choices.

And a good team will assume that some contra-information will exist. At the very least, they must assume, with Buddha, that “everything changes, nothing remains the same.”

Further: If we organize the current plan in a good way, it becomes easy to revise it together.

As an example, a long highly details Microsoft Project plan (as I used to do), is very hard to revise. But a plan that is embedded in 50 stories sorted into, possibly, 12 sprints, is fairly easy to revise. The level of granularity is important (and for more reasons than this).

As knowledge improves and life changes, we can make the plan better. This is similar to saying: having a plan enables continuous learning and re-planning.

Let’s say that again, a different way. In Waterfall, for me at least, it used to be painful and difficult to revise the plan. I used to hate Microsoft Project. (Well, I still do.) In agile, we must make the re-planning have a low overhead cost so that — it costs less, it hurts less and it is done more frequently. And these days, with most of the Scrum tools, this is now fairly easy to arrange.

***

Again, I am not advocating ever fully believing in any plan. “It ain’t over till it’s over”, as Yogi Berra would say. But you need a plan to win the ballgame.

More soon… And see prior posts in this series.

***

Note: Yogi Berra was a catcher for the New York Yankees, and was famous for his “Yogi-isms”.