🧐 agile monocle S01E06: a word (or two) about planning

Plans are useless, but planning...you gotta do it.

This sixth episode welcomes you to the land of planning. And whenever we talk about planning we really do have to quote Dwight.

“Plans are useless, but planning is indispensable.”
Dwight D. Eisenhower

Which again it’s something — you might have guessed that I have a thing for quoting people correctly — Eisenhower never actually said, but only reportedly heard from someone else:

“Peace-time plans are of no particular value, but peace-time planning is indispensable.”
An anonymous and successful soldier

The reference to peace-time is giving me an idea about the topic of strategy, which might be something I’m gonna talk about in Season 2, we’ll see.

Anyhow, let’s cover some important basics about planning: I won’t dig into this or that planning technique, but I’d like to overview what planning is, what are the common problems with planning, what does it mean to plan in an “agile way”.

To be clear, I don’t even think that there should be something called “agile planning”.

“Agile planning doesn’t exist, but complexity-aware planning is indispensable.”
Me

A planning continuum

I think what we struggle the most with “agile planning” is the concept of “just about planning” which is easier said than done, and let’s see why.

Borrowing from Peter Gfader, we really need to have a talk about what do we mean when we say “let’s do this in agile”.

Planning it’s not limited to a bi-modal approach. We have a spectrum, or a continuum, especially we are working in a complex environment or a larger company, we can have different sorts of projects run in slightly different ways, and we should be able to acknowledge this continuum.

Now, given a continuum that goes from chaos (you might call it “ad hoc” to be polite, I’ll call it what it is) to BDUF (those situation where you need and estimate of an estimate of an estimate, document every micro-interaction of the front-end, and so on), let’s see what most people mean when they say “let’s do this in agile”.

And that’s it: what most people think when they say or hear “let’s do this project in agile!” is to skip planning entirely or to use creative estimation techniques. This is a big problem because that, my friends, it’s not the land of agile, that is the land of improvisation.

Do we really like to improvise (that much) in a business context?
I don’t think so.

Agile planning sits right in the middle of that continuum, because it tries to acknowledge both the shortcomings and strengths of the extremes. As in the physical world, staying in balance right there in that middle ground is harder than sitting on the extremes: you need a strong core.

🧐 Now try this: look the blank, graduated continuum here below. Think about your last 5 to 10 projects. How they fared in terms of “ad hoc-ness” or “BDUF-ness”? Were these projects on one side of the continuum for the entire duration of the project? Did they swing from one side to the other? Where there particular phases skewed toward one specific end? Why are you sometimes lost in the chaos while other times you have strict controls over your work?

Estimation vs. Forecasting

First: do not confuse estimation with forecasting. Second: I think estimation is relatively easier and in my experience a much more common practice than forecasting. That doesn’t mean we shouldn’t be using both estimation and forecasting while planning.

What “good estimation” and “good forecasting” look like?

  • Good estimation: it’s fast, can and should be done a relative fashion, and with well-known trade-offs between accuracy and precision;

  • Good forecasting: you really need to keep your assumptions in check because no statistical law or equation is going to save you if your assumption about your work are wrong.

And you might have guessed it: planning in Scrum tends to be unbalanced toward estimation, while planning in Kanban tends to be skewed towards forecasting: and yes, you should use elements of forecasting in Scrum and elements of estimation in Kanban to make your planning a little more robust.

Estimation and forecasting serves two different purposes, and for sake of brevity I won’t dig into the subject of forecasting this time — let’s just say for now that in order to approach good forecasting practices you need to have strong data-oriented culture in your company.

Estimation gets stumped by imperfect, incomplete, wrong, immature knowledge. And the fact that digital projects suffer from, borrowing again from Peter Gfader, the so-called project paradox.

Yep, you guessed: we have to make a lot, if not most of our decisions at the beginning of the project, where we have the least amount of knowledge available — the project paradox can be seen as a simplified corollary of the older concept of the cone of uncertainty.

To summarize, from this concise and great talk about estimation from Ciaran Hanway, what are the principle about agile estimation:

  • Speed over perfectionism

  • Accuracy over precision

  • Collaboration over assertion

  • Relative over absolute

We don’t do sprints for the sake of doing sprint, we don’t use story point for the sake of using story points: we do so because our planning practices have had a lot of shortcomings for decades, since the beginning of digital projects, and that’s the main reason why I sort of refuse of talking about “agile planning”.

There is “complexity-aware” planning and “complexity un-aware” planning. Staying right there in the middle requires a lot of discipline and method, which most of agile practices are supposed to help you with: it’s not the land of improvisation.

What do you see?

This newsletter is about a monocle, not about a monologue. I want to hear from you so if you want to ask about anything or suggest a topic, you can reply to the newsletter, comment here below, or send a request here. I’d like to make it as much interactive as possible. Don’t make me open a Slack channel.

See you next week, agile monocle episode 7, the Season 1 finale, will be out on Monday, October 26th.

(header image: Scott Rodgerson)