United States Joint Forces Command 
(JFCOM) never set out to teach software development project managers a lesson about enablement. Things just sort of turned out that way. But they don't really like to talk about it.
So I will.
But first, another story. If you've read any of my recent material, then you're aware of the effort at our company to build an Agile development practice internally. Since mid-2002, we've gradually built up our knowledge and capability to run successful projects using an adaptive approach with methodologies like eXtreme Programming and Scrum .
Well, if you've become involved with adaptive development yourself, then you know there's more to it than just memorizing another cookbook process or another list of buzzwords, while continuing to do the same things you always did before but calling it "new." This stuff really is new. It's a whole different mindset than that of traditional, predictive development. And a mindset is a much harder egg to crack than a methodology.
What is enablement and why does it matter?
Possibly the most significant difference is the relative emphasis on formal methods. Indeed, the very first statement in the Agile Manifesto — the brief statement of guiding principles on which further elaboration of Agile methods is based — is that we value direct, face-to-face communication more than we do indirect, formal communication through documents.
The divergence between predictive and adaptive mindsets is significant. The former — and this is the basis of traditional software development methodologies — is based on thorough data collection, painstaking analysis, and systematic assessment of all available options, risks, and costs. Then, based on the results of that analysis, development proceeds according to a comprehensive, detailed plan that predicts and controls every step of the process.
Adaptive development, on the other hand, is based on acceptance of the simple reality that human beings cannot accurately predict every requirement, identify and mitigate every risk, plan every step, and budget every expense of a software development project in advance. Not even a team comprising domain experts and technical wizards can do that. Adaptive development, as the name suggests, embraces continuous change and defines ways to deal with it. Most of those ways are concerned with facilitating direct, face-to-face communication among the stakeholders of a project.
It turns out, perhaps counterintuitively, that the formal, logical, analytical approach to decision-making isn't actually the way effective people make decisions under stress. Cleveland-based cognitive psychologist Gary Klein has studied the ways in which people make life-or-death decisions for many years. His 1999 book, Sources of Power: How People Make Decisions has become a classic in the field. According to an article in Fast Company (a publication whose title seems particularly apt for a discussion of adaptive development):
Klein and his research team are attempting to crack a mystery that has intrigued psychologists for decades: How do people who work in unpredictable situations make life-and-death decisions? And how do they do it so well? According to decision-making models, they should fail more often than they succeed. There is too much uncertainty and too little time for them to make good choices. Yet again and again, they do the right thing. Klein wants to know why.
Basically, what Klein was onto was the fact that people can learn to assess complex situations very quickly and subconsciously, bypassing the conscious and methodical process of reasoning through a problem step by step based on experience and practice. Ordinarily, we assume the ability to solve complex problems or make difficult choices requires sophisticated, advanced cognitive skills. But nature is full of examples of behavior that seems to reflect conscious thought, yet could not possibly do so since the animals involved lack the "hardware" for conscious thought — African termites' engineering and their cultivation of crops, ants' husbandry of aphids, honeybees' dances to describe the location of food sources, viruses restraint from killing off 100% of their host organisms lest they eliminate their own environment. Even non-biological objects can exhibit the appearance of behavior guided by intelligence, such as the insect-like robots that learn to walk in order to move toward light sources to recharge their batteries, although they lack any artificial intelligence programming whatsoever; all they "know" is that they need light.
Human beings have the ability to reason through problems consciously and deliberately, but not at the expense of their ancient, natural ability to reach useful conclusions about complex situations very quickly, and subconsciously. It is an ability that has served us well throughout our evolution. Our ancestors might not have survived the heyday of sabre-toothed cats without it. Those who are effective at reaching the right conclusions quickly in stressful circumstances have learned — perhaps unconsciously — to tap into that ability.
When you consider the characteristics of projects that lend themselves to adaptive development, it's clear they are examples of unpredictable, high-stress situations in which people must make snap decisions that have high stakes without the luxury of time to examine all the available alternatives or to consider all the possible risks. Yet, most people in the IT industry continue to see software development as a task that can be reined in and controlled through rigorous, methodical, statistical methods. Go figure.
So, a traditional project manager wants to keep track of hours, dollars, and dates; to assign tasks to developers and watch them to make sure they actually put in an honest day's work; to mark the completion of the standard steps in a formal process on a checklist. An Agile project manager wants to hire the right sort of people , keep them informed about goals and priorities, and move obstacles out of their way so they can get the job done.
And that's what enablement means, plain and simple.
Of course, for a manager to stand aside and let people get the job done requires that the people can get the job done without much supervision. That's where hiring the right sort of people becomes important. In our group, we look for these characteristics in new hires:
It's no accident that we list these characteristics inside a triangle. The geometric shape suggests that the relative importance of the traits forms a geometric progression rather than merely a prioritized list. You can probably see the priorities are pretty much the reverse of those sought in traditional software development organizations, where hiring managers look first and foremost for technical experience with particular technologies, while traits such as critical thinking and creativity are not so important, since developers are only expected to follow a predefined cookbook process. Agile managers look for traits that will drive the work forward relentlessly if only they can be unleashed, or enabled.
Enablement is a critical success factor on Agile projects, and it is a practice that makes Agile project management easier and more professionally satisfying than traditional project management . To a traditional manager, however, enablement is both mysterious and frightening. It feels like a surrender of "control."
Large IT organizations aren't the only ones that fear enablement. Other large organizations that deal with high-stress, life-and-death situations in which there is "too much uncertainty and too little time" have the same tendency to rely on formal processes, detailed data analysis, and methodical decision-making. What larger organization of that type could there be than the United States military?
The perfect solution to uncertainty and risk
The United States military had a problem. It was a problem that had been stated in many ways by many people, including Napoleon Bonaparte :
A general never knows anything with certainty, never sees his enemy clearly and never knows positively where he is. When armies meet, the least accident of the terrain, the smallest wood, hides a portion of the army. The most experienced eye cannot state whether he sees the entire enemy army or only three quarters of it. It is by the eyes of the mind, by reasoning over the whole, by a species of inspiration that the general sees, knows and judges. (Military maxims of Napoleon )
This sort of thing really rankled the military brass. Only certain people, blessed with the right personal traits, could be successful in battle. Under those circumstances, how could victory be guaranteed every time? It was just too "iffy" for comfort.
It seemed to the military leadership that it ought to be possible to rein in the uncertainties of war and subject the whole matter to a rigorous, well-defined, manageable process. Toward the end of the twentieth century, it began to look as if the technology and expertise existed to do just that. The Department of Defense established the Office of Force Transformation to effect a sweeping change in the way the military conducted its operations.
JFCOM played, and still plays a major role in the transformation. They came up with the Operational Net Assessment (ONA), which they describe (in part) as follows:
The ONA process frames our understanding of a potential adversary's political, military, economic, social, information, and infrastructure systems. Link analysis, network analysis, and structured argumentation are used to assess the adversary's systems.
Such systems analysis:
- Reveals critical nodes and vulnerabilities that may be used in effects-based operations
- Recognizes the adversary's goals, intentions, strengths, weaknesses, and behaviors
- Generates understanding and knowledge that may be used to predict indirect and unintended effects a of diplomatic, information, military, or economic applications of national power
- Determines what the adversary values most and how to affect it decisively.
JFCOM also came up with Effects-Based Operations (EBO), a "process for obtaining a desired strategic outcome or 'effect' on the enemy, through the synergistic, multiplicative, and cumulative application of the full range of military and nonmilitary capabilities at the tactical, operational, and strategic levels." The Common Relevant Operational Picture (CROP) provides "military thinkers, inter-government agencies and joint warfighting commanders [with] the ability to review intelligence on their adversary, chart and map troop movements, gather information on an extensive database of knowledge and scenarios and also get the information to the troops in a way never before utilized by any force in the world - all at their fingertips. With the click of mouse, and through the use of their desktop computers, leaders have the power to see the battlefield and win the war in a whole new way."
Sounds impressive. Indeed, it sounds so impressive it's hard to imagine an enemy who would even try to stand up against it. A totally comprehensive picture of everything about the enemy's capabilities, economy, and culture and all the linkages among those elements; complete intelligence about all the enemy's movements, communications, status, and personnel; a comprehensive real-time map of the operational theater and the ability to deploy forces instantaneously with the click of a mouse. And all that guided by the cumulative mindpower of the top military thinkers available, working in concert.
To prove the case for all this, JFCOM organized the most massive and most expensive military exercise in history: Millennium Challenge 02 (MC02). Blue Team, equipped with ONA and CROP, among other tools, and ready to employ EBO against the enemy, arrayed its virtual forces against Red Team, representing a hypothetical rogue middle-eastern state located on the Persian Gulf, filled with religious fanatics, and headed by a megalomaniacal, anti-American dictator. The whole game cost a whopping quarter billion dollars. It was the showcase of the transformation. Blue Team couldn't lose.
And that brings us to JFCOM's lesson about enablement for software development project managers, as well as the reason why JFCOM doesn't like to talk about MC02.
Blue Team lost.
Millennium Challenge 02
JFCOM asked a respected, experienced, hard-nosed combat veteran and former head of the Marine Corps University at Quantico, Virginia to lead Red Team in the exercise. Paul Van Riper had earned a reputation in the field as an effective battle tactician who could think outside the box. He expected a lot from his men, and he expected them to know how to do their jobs. In an anecdote recounted by Malcolm Gladwell in his book, Blink: The Power of Thinking Without Thinking (p. 101), a marine who served with Van Riper in Mike Company in Vietnam recalls:
"He was a gunslinger...somebody who doesn't sit behind a desk but leads the troops from the front. He was always very aggressive but in such a way that you didn't mind doing what he was asking you to do. I remember one time I was out with a squad on a night ambush. I got a call from the skipper on the radio. He told me that there were one hundred twenty-one little people, meaning Vietnamese, heading toward my position, and my job was to resist them. I said, 'Skipper, I have nine men.' He said he would send out a reactionary force if I needed one. That's the way he was. The enemy was out there and there may have been nine of us and one hundred twenty-one of them, but there was no doubt in his mind that we had to engage them. Wherever the skipper operated, the enemy was put off by his tactics. He was not 'live and let live.'" (p. 101)
The point of Millennium Challenge was to show that, with the full benefit of high-powered satellites and sensors and super-computers, [the fog of war] could be lifted. [...] This is why, in many ways, the choice of Paul Van Riper to head the opposing Red Team was so inspired, because if Van Riper stood for anything, it was the antithesis of that position. Van Riper didn't believe you could lift the fog of war. [...] [He had become] convinced that war was inherently unpredictable and messy and non-linear. (p. 106)
Sound familiar? It should. The same model applies to the software development profession today. The predictive approach assumes it is possible to understand every variable about a proposed project in advance and in detail; to lift the fog of software development. The adaptive approach makes the opposite assumption, and employs tactics designed to cope with that reality. And those tactics are often counterintuitive, if not incomprehensible to the predictive thinker.
In the 1980s, Van Riper would often take part in training exercises, and, according to military doctrine, he would be required to perform versions of the kind of analytical, systematic decision making that JFCOM was testing in Millennium Challenge. He hated it. It took far too long. "I remember once," he says, "we were in the middle of the exercise. The division commander said, 'Stop. Let's see where the enemy is.' We'd been at it for eight or nine hours, and they were already behind us. The thing we were planning for had changed." It wasn't that Van Riper hated all rational analysis. It's that he thought it was inappropriate in the midst of battle, where the uncertainties of war and the pressures of time made it impossible to compare options carefully and calmly. (pp. 106-107)
When the exercise began, ONA told the Blue Team commanders how Red Team would respond to any and all possible tactics. Blue Team knocked out Red Team's fiber optic lines and microwave towers to force them to use cell phones and satellite communications, which Blue Team could easily monitor. They expected to be able to listen in on radio communications with pilots, and thereby know exactly where all Red Team's aircraft were and what they were up to.
Blue Team positioned an aircraft carrier group near Red Team's coastline and issued an eight-point ultimatum, including a demand for surrender. Then they waited for Red Team to respond as ONA predicted they would.
Red Team deployed hundreds of small boats into the Gulf, and at a certain moment they carried out a coordinated series of suicide attacks against the ships, supported by an hour-long assault with cruise missiles. The aircraft carrier and two helicopter carriers were were among the 16 Blue Team ships sunk. At no time did Blue Team intercept any radio or cell phone communications.
As Van Riper explained it to Gladwell,
"Who would use cell phones and satellites after what happened to Osama bin Laden in Afghanistan? We communicated with couriers on motorcycles, and messages hidden inside prayers. They said, 'How did you get your airplanes off the airfield without the normal chatter between pilots and the tower?' I said, 'Does anyone remember World War Two? We'll use lighting systems.'" [...] "[We knew] they were going to adopt a strategy of preemption," Van Riper says, "so I struck first." (p. 110)
By the end of the second day, Blue Team lacked the resources to mount an attack on Red Team's country from air or sea, and had lost five out of six amphibious troop carriers, so could not mount a ground assault. Red Team, apparently overmatched in every way, had won. They not only won, they completely routed the superior Blue Team forces. Blue Team seemed not to have understood Red Team's approach or tactics at all, nor could they adapt once the parameters of the battle had changed.
But Red Team's tactics were only common sense. They avoided doing anything Blue Team expected them to do. This is nothing more than basic Sun Tzu (easier said than done, of course).
The key point is that once Van Riper had issued the order to give the signal to attack — disguised as part of the call to prayer sung out from the minarets of Red Team's mosques — the rest was left up to the unit commanders in the field. They knew the objectives, and they were enabled to meet those objectives. There was no stopping to see where the enemy was and to confer about next steps. They knew what to do and they acted, and their commander trusted them to act. They understood the objectives and they knew how to do their jobs. When conditions in the field changed — when things came up that weren't anticipated in advance — they adapted and acted autonomously, always pushing toward the objective without having to be told what to do every step of the way, and without having to ask anyone's permission or approval. That's enablement.
The post-exercise analysis went on for several months. Traditional thinkers in the military kept trying to come up with excuses for Blue Team's failure. Maybe they had run the games wrong. Maybe in real life the ships wouldn't have been so vulnerable. Maybe there were glitches in the programming. They thought of every possible reason except the obvious one: That their initial assumptions about the approach had been mistaken.
So the military planners did the only thing they could do under the circumstances. They ran the exercise again. This time they took no chances with Van Riper's tactics. They instructed Red Team to respond exactly as ONA said they should respond. Basically, they choreographed the whole exercise. Naturally, Blue Team won, with Van Riper standing in the room with arms crossed, refusing to play along and muttering wise-cracks.
This should sound familiar to experienced software developers, too. How many large projects have failed, only to be re-cast as successes after the fact? Requirements get redefined in hindsight to match whatever was delivered. Budget overruns and schedule slippages are magically forgotten. The solution — probably never actually used by the intended user community — is deemed a success.
Why does that happen? What's wrong with simply learning whatever lessons experience has to teach? It happens for the same reason in the software industry as in the military: The planners have too much invested in the project to allow it to fail. Career. Ego. Status. Those investments are not to be taken lightly. They supercede questions of return on investment, or of national security.
And that's why JFCOM doesn't like to talk about MC02. That's why the lesson about enablement has largely been lost, and the official story of MC02 is all about the second run of the exercise, when Blue Team called all the shots for both sides. That's how it goes all too often in software development, too.
The moral of the story
"The more you tighten your grip, Tarkin, the more star systems will slip through your fingers."
— Princess Leia, Star Wars
I've mentioned industry assessments like the Chaos Report, published by The Standish Group , on other occasions. The 3Q 2004 Chaos Report indicates that some 71% of all software development projects fail to meet their objectives, stay on schedule, stay within budget, or are cancelled outright prior to completion. These projects follow a predictive or Waterfall development approach. When they fail, they fail as Blue Team did in MC02, and when companies assess their results they do it as Blue Team did in the second pass at MC02.
If we want to break free of the pattern of failure that has characterized software development since the advent of heavyweight process-oriented methods in the late 1970s, we have to stop worrying quite so much about career, ego, and status and concentrate a little more on delivering business value. It's clear enough that adaptive methods are often the best way to accomplish that. Enablement is a fundamental part of those methods. Project managers must stop relying on tight control of the details of projects, and learn to let go and take a step back. Keep your people informed of objectives, deal with organizational obstacles for them, and trust them to get the job done.
Yes, you'll surrender some control. But take solace in this: There's no surer way to make gains in the areas of career, ego, and status than by delivering genuine, quantifiable, hard business value.