Industry Commentary – Page 69 – IS Survivor Publishing

Agile and OODA

Why have Agile methodologies (including DevOps, which adds agile deployment to Agile development) made such inroads in IT? Why is OODA (observe, orient, decide, act) so important for business strategists?

Agile/DevOps is OODA applied to application development; OODA depends on business agility, applying many of its core concepts to external threats and opportunities.

It starts with the gunnery problem. In case you aren’t familiar with it …

You’re shipboard. You man an anti-aircraft gun. The shells you fire have an initial muzzle velocity of around 2,500 feet per second, decelerating due to gravity as they ascend toward the aircraft you’re shooting at.

The aircraft is a bomber. It flies at something less than 1,000 feet per second. Being a math whiz you can project exactly where the bomber will be when your shell reaches its altitude, allowing you to aim at the exact spot in the bomber’s trajectory where your shell and the bomber would attempt to occupy the same space at the same time.

But, the bomber is piloted by someone who, all things considered, would prefer that their aircraft’s trajectory and that of your shell don’t intersect, and so they don’t just fly in a straight line.

In application development terms, by the time your shell reaches the target’s altitude, the requirements will have changed.

Why Agile? So IT can deliver the software needed to support business changes (where you aim) in time for the planned change to still be relevant to the business’s new situation (before changes in the bomber’s flight path make your aim wrong).

Why OODA? Same answer: The attacking plane is a competitor, or the overall marketplace, or some important change in circumstances that will affect your business.

Your planned actions have to still be relevant when they “reach the attacker’s altitude” … when the changes you anticipate become real, recognizing that the more time that elapses the less predictable the future (the bomber’s position) is.

See, there’s a reason we’ve settled on the term “Agile” instead of “Fast,” which is that depending on what you mean by “fast,” waterfall is much faster than Agile, as was pointed out a few months ago in this space. It’s faster in that, assuming you have a useful way to measure software functionality, waterfall generally delivers more of it in a unit of time than Agile or DevOps.

But, waterfall delivers it all at the end of a long trajectory, during which business circumstances might change and change again. Waterfall design and development have a lot in common with a gunner shooting a slow, heavy shell that packs a lot of explosives at the spot a bomber would be in were it to continue flying in a straight line.

It’s a big bang that misses the target: Waterfall’s fixed requirements and specifications and need to develop and deliver the whole system in one piece conspire to deliver results that are largely irrelevant when delivered.

Pushing the analogy to the limits, Agile, and even more so DevOps, is less like a shell than a surface-to-air missile. They’re able to track changes to the target’s trajectory and adjust course accordingly.

Waterfall still has its adherents. Their near-universal explanation of waterfall’s high failure rate is that business people “don’t know what they want,” which presupposes there’s a way for them to know the answer to the question, “What do you want the software to do?”

Someone once studied people who design and build their own houses. Turns out, they’re rarely satisfied with the first one they live in. Generally, they aren’t satisfied with their second try, either.

If it takes three tries to design the house you want, keeping in mind that living in a house isn’t exactly terra incognita for most people, expecting a business manager to know in advance exactly how a piece of software should behave is several percentage points less than realistic.

And that’s starting with the false assumption that “What do you want the software to do?” is the right question to ask. It isn’t. A far better question is, “How do you want to run your part of the business differently and better?”

Even when IT asks the right question, the fundamental difference between the past and the future still intervenes. Presumably you know what this difference is: You can, in principle, get a pretty good handle on what’s already happened.

The future isn’t like that.

OODA and Cognition

If you want to understand what a Cognitive Enterprise is, look no farther than the OODA loop.

OODA stands for:

Observe: Look around you to see what’s going on that might affect you.

Orient: Interpret what you observe, recognize how your own biases affect your interpretation, and determine the implications of your observations for your current situation.

Decide: Choose the course of action that will give you maximum advantage … or that will put an opponent at maximum disadvantage.

Act: Do whatever you decided to do, skillfully and without hesitation.

It’s a loop because every time you Act, you then Observe the result and take it from there.

The OODA loop differs from other negative-feedback-loop-based mechanisms popular in business circles … PDCA (Plan, Do, Check, Act) comes to mind … in that these other loops all have an inward focus. They’re about monitoring, stabilizing, and improving internal functions.

This is why OODA matters much more than PDCA when it comes to making an enterprise cognitive.

When businesses engage in PDCA or one of its equivalents, they’ve decided what they’re going to do for a living. Their customers can either adapt to it or take their business elsewhere.

When businesses make use of OODA loops, in contrast, in most cases they should first decide which competitor or competitors they want to beat. And in fact, when my colleagues and I engage a client at the strategy level, this is often our first order of business: Choosing the right competitor. Once that’s done, it’s OODA all the way.

To understand why choosing the right competitor matters so much, consider the sad case of Best Buy. Back in the early 2000s, it focused its competitive tactics on winning customers from Circuit City — a goal it succeeded at in spectacular fashion, driving Circuit City clean out of business.

Its success was the source of its failure: It was by choosing Circuit City as its competitor to beat that Best Buy turned itself into Amazon’s showroom.

OODA isn’t, by the way, limited to competitions — it’s useful in any situation where understanding your situation and acting to achieve a better one is a good way to go about things.

OODA is, when you get right down to it, a pretty good model for what it means to be cognitive. Whether a wolf, human or business, any entity that’s aware of its situation (it observes), understands it and its implications (orients), uses that understanding to choose a course of action (decides), and then actually does something about it (acts) can with considerable justice be said to think.

Which is why OODA has such strong ties to enterprise cognition. Or, to be accurate, vice versa. OODA came first, and strongly shaped our ideas about the need for enterprises to be more cognitive. OODA is a model for enterprise cognition; cognitive enterprises build their plans around OODA loops.

While OODA isn’t limited to competitive situations, in competitive situations OODA loops have a fascinating property: Whoever has the shorter loops generally wins. Why is this? The answer is a thing o’ beauty: whichever side acts first changes the situation of both competitors. This makes the other side’s observations, orientation and decisions obsolete, forcing it to start over.

To the side with faster loops, the slower side becomes completely predictable, while to the slower side, the faster side becomes completely unpredictable.

Understand, this doesn’t mean OODA is good and PDCA is bad. Not at all: When an entity acts, its actual actions should be as close to its intended actions as possible. PDCA and similar feedback-driven improvement mechanisms are what make this possible.

So PDCA isn’t inferior to OODA. It’s subordinate to OODA.

* * *

Want more? Two colleagues and I authored a Dell white paper on the subject, “Winning with Digital Velocity.” It explores OODA in more depth, illustrating its possibilities using examples from Amazon, Apple, and ESPN.

You’ll find it here. And don’t worry about it having “Digital” in the title. While speed has particular significance for businesses engaging in so-called digital transformations, it’s just as important for businesses pursuing more traditional strategies.