Commander's Intent

No plan survives contact with the enemy.

Last night I started reading Made to Stick. In it I was introduced to a concept called "Commander's Intent" that I thought would be useful in a software development context.

The military loves to plan. There are plans that specify what should happen for a whole theater of operations and there are plans that specify what a SEAL team of ten men will do on a particular mission. The plans are so detailed that they can guide the actions of a single soldier. Unfortunately, enemies never behave exactly as expected, so the moment an enemy becomes involved, the plan is obsolete. Recognizing this, in the 1980's the army began requiring commanders to include a statement of the "Commander's Intent" at the top of each plan. This statement is a distillation of the goals of the entire mission into a single, simple statement. Since it's introduction, Commander's Intent has proven tremendously useful. It provides soldiers with the information they need to continue working towards the goal of a mission even after all the particulars of the plan are unachievable.

If we do nothing else during tomorrow's mission, we must ________________

What made me think of this in software was Chris Stevenson's "The Editable Grid Antipattern" The article is about how 90% of the time a requirement for something to "work like excel" means you've missed the real requirement. He provides a great example of an application maintaining employee and employment information. Go read it now. I'll wait.

Commander's Intent is about giving the soldier the information they need to fulfill the goal of the mission even when the specifics of the plan are no longer possible. In software what we need in is knowledge of User Intent. User stories are a great way of doing this that are still criminally underused in many companies (read: my company). Their canonical form of "As a [role] I want to [action] so that I can [intent[" gathers the information a developer needs to the solution the customer wants, not what they ask for. Traditional requirements of "The system shall [action]" don't capture the intent, so you end up building it "like excel" because that's what the customer asked for, even if it wasn't what they really needed.