Plans Are Worthless, But Planning is Everything (Agile Software)

I recently re-read Dwight D. Eisenenhower’s 1957 speech (link) in which he referenced this famous quote “Plans are worthless, but planning is everything”.

As a software leader/manager/developer, when I encounter resistance during the planning and design stages of software projects, I’ve observed that the greatest source of miscommunication almost invariably stems back to this fundamental concept of “plans vs planning”.

This approach to planning, as it turns out, is rooted in the US Army.

The Stoics referred to this as "Premeditation of adversity", or simply to "Practice Misfortune". In today's terms, this exercise is a form of project risk mitigation and preparation.

To better understand this principal, let’s look at Eisenhower’s comment in more detail. In the full context of this quote he says:

“I tell this story to illustrate the truth of the statement I heard long ago in the Army: Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning.”

Eisenhower is acknowledging that the act of planning is synthesizing and imagining an unpredictable future, and that the outcomes of a plan do not reflect how things will actually unfold.

Although he’s referring to planning in the context of emergencies, it generally applies to any planning processes in chaotic environments; such as Software Design and Development.

Okay, then why plan at all if plans are worthless? He goes on to say:

“So, the first thing you do is to take all the plans off the top shelf and throw them out the window and start once more. But if you haven’t been planning you can’t start to work, intelligently at least.”

This statement refers to the dilemma of getting started on a project. When undertaking software projects, the greatest obstacle is simply writing that first line of code. So give yourself some basis of dialogue with an initial plan and a prototype, then throw that away, if necessary, and start on the next iteration.

“That is the reason it is so important to plan, to keep yourselves steeped in the character of the problem that you may one day be called upon to solve — or to help to solve.”

He’s basically saying that planning puts you in a position for success, so when the actual events unfold, you are that much closer to making the detailed decisions to ensure a successful outcome.

“Now in the statements I have made, I don’t mean to say there are not some verities, some unchanging truths, although again, to quote a military man: The only unchanging factor in war is the most changeable, uncertain, unpredictable element in war, and that is human nature. But the human nature of today is exactly what it was, apparently, in the time of Pericles and Alexander and down through the ages to this day. Everything else, even terrain, even weather, seems to change.”

Software is deterministic, but people are not. We program machines to do exactly what we want them to do, but projects largely revolve around people. Therefore any plans that make assumptions based upon the actions of people are non-deterministic and subject to change.

A good leader understands that people on the front lines will ultimately make the final decisions, therefore the goal of planning and plans are simply to prepare people for what they might encounter, and trust they’ll do the right thing when confronted with complete information.

Coincidentally, the Manifesto forAgile Software Development adopts this spirit of planning, just in different words. Learn more…