Map and Terrain – The Limits of Planning

Belgian surrealist René Magritte created a series of paintings known as The Treachery of Images. One painting depicts an image of a pipe with the declaration Ceci n’est pas une pipe (It is not a pipe) painted below.

Magritte’s image reminds us that any abstracted symbolic representation is by definition, a limited view. Magritte commented

 If I had written on my picture ‘This is a pipe,’ I’d have been lying!

Alfred Korzybski, developer of the theory of general semantics, remarked

The map is not the territory.

There’s a difference between a model of something and the actual thing. Author Jerry Weinberg tweeted an applicable heuristic that inspired this post

If the terrain and the map do not agree, follow the terrain ~Swedish army manual 
@JerryWeinberg

Similarly with software, we can plan ’till the cows come home. But, once the action starts, stuff happens! Are you going to follow the plan or react to unforeseen circumstances? Often the map and the terrain don’t agree.
Given Patrick Reilly‘s recognition that the optimal model of a system is THE system, and his admission that that ill-formed premises can be modeled and validated, why do we spend so much time planning, designing, and modeling?
I admit I have a soft spot for software prototyping.With prototyping, discrete activities of planning, designing, and modeling are compressed into cycles of develop and review. It’s been my limited experience that the closer the review is to the user, the better the software.
During the cycles of develop and review, stuff happens. Inevitable stuff. Stuff like important discoveries. Valuable discoveries occur that we likely wouldn’t have or couldn’t have known before hand.

Discovery consists of seeing what everybody has seen and thinking what nobody has thought. ~Albert Szent-Gyorgi

Planning isn’t always amendable to discovery. Planning usually occurs before action occurs. And before action, there might not be anything to critically observe.

Highfalutin plans can often be condensed into a concise phrase similar to the military concept of Commander’s Intent (cf. my post Team Decisions and Commander’s Intent). Troops in the field must often act without a script because stuff happens.

Most of us are adept empiricists. We understand things best when we experience them…

Instant message:

Bob says:
  i have a THANKING cloak that bounces THANKS back to the emitter
Steve R says:
 what does a “you’re welcome” do?
Bob says:
  just threw an unhandled exception
Bob says:
 that was an edge case I couldn’t have planned for.

Team Decisions & Commander’s Intent

How does your team make impromptu decisions?
To keep Bill Clinton’s presidential campaign sailing along on a singular tack, political strategist James Carville posted the declaration,

The economy, stupid

in their Little Rock campaign headquarters.

In Made to Stick, Chip and Dan Heath remind us that James Carville’s declaration is known in military circles as the Commander’s Intent.
Historically, military planners have observed that complex battle plans begin to break down as soon as the battle commences.

Everyone has a plan ’till they get punched in the mouth.
~Mike Tyson

During combat, innumerable variables dictate the prudent course of action. In the 1980s, military planners adopted the concept of Commander’s Intent. The Commander’s Intent is a direct, fast, and simple declaration like win hearts and minds or destroy the bridge. When faced with a decision in the field, everyone can weigh whether a course of action follows the CI.
The US Department of Defense defines Commander’s Intent as
A concise expression of the purpose of the operation and the desired end state that serves as the initial impetus for the planning process. It may also include the commander’s assessment of . . . where and how much risk is acceptable during the operation.
Is there value in declaring a Commander’s Intent during project chartering? In many cases, I think so. The Product Owner might make the declaration
Provide fast search results
(making sure the team understands the distinction between fast search results and relevant search results).
During iteration planning, and during retrospectives held over the course of the project, team members are then able to repeatedly ask the self-correcting question
Are we providing fast search results?
In some cases, project iterations would benefit from a CI; particularly in iterations where the user stories roll up into a singular theme or goal. In such cases, the Product Owner, or the team collectively, might craft a succinct, high-level statement like,
Display targeted ads with search results
that sharpens the focus of the iteration. During the course of the iteration, the team is then able to ask the self-correcting question

How is this helping us Display targeted ads with search results?