Project Management – Page 20 – 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.

The Cognitive Enterprise debuts

It’s time for businesses to think.

The Cognitive Enterprise (Bob Lewis and Scott Lee, Meghan-Kiffer Press) has been released into the wild. The questions of the hour: (1) What makes an enterprise cognitive? (2) Why does it matter?

There seems to be a strong negative correlation between the size of an organization and its ability to respond in sensible ways to changing circumstances. And this lack of good organizational sense seems to be independent of how smart the organization’s leaders and staff are.

It’s as if there’s an impenetrable barrier that prevents the considerable intelligence available in a business from influencing the behavior of that business.

Superimposed on this is the industrial model of business management — the notion that businesses should be “designed by geniuses to be run by idiots.”

This is the driving philosophy of most business process design: Simplify, simplify, simplify. Which, depending on the process and its goals, often is the best answer. In truly industrial situations — manufacturing and its analogs, where the goal is to create large numbers of identical work products — simplification and standardization make all kinds of sense.

But (you know “but” was just floating in the air, waiting to be uttered …)

With a few exceptions, business is first and foremost a game. It’s about winning and losing. In the short term, it’s pretty close to a zero-sum game, where one company selling more products to more customers means some other business will find itself selling fewer products to fewer customers.

There just aren’t that many games where success comes from streamlining, simplifying, and standardizing. In football, the winning teams aren’t the ones with the skinniest playbooks. In baseball, pitchers don’t throw every pitch exactly the same. If they did, they’d get shelled.

If you don’t like athletic metaphors, consider chess. Think a grandmaster is going to win by always playing the same opening?

* * *

Business designers follow a well-worn formula: People, process, technology.

Except it’s really PROCESS, Technology, people. No, it’s worse. People are an actual impediment. Carefully designed processes, written standard operating procedures, and automation are all established to overcome the limitations of we pesky human beings.

This worked just fine in the past because of a key and rarely explored metric — the stay-the-same to change ratio.

That business cycles are compressing isn’t a new insight. What’s often missed: Establishing well-defined and (more important) well-practiced business processes, supported by optimized automation, takes an investment of time, effort, and money. Having invested, businesses need a long enough period of stability to recoup that investment.

Business cycles are compressing — the stay-the-same piece of the ratio is shorter — but the change side of the ratio hasn’t compressed anywhere near as much.

Same investment, less time to get a return from it.

Which is why Scott and I are proposing a new framework. Instead of people, process, technology, cognitive enterprises will emphasize customers, communities, and capabilities.

Start at the end: A capability is anything an organization can do, independent of whether it’s doing it right now. Capabilities are what let an organization adapt to changing circumstances.

Communities next. More and more, the men and women who contribute their efforts to an organization’s success have less loyalty to their employer. (Employers, of course, jettisoned the quaint idea that they owe their employees any loyalty long ago.)

Supplanting, or perhaps augmenting employees’ relationship with their employer is their relationship with their profession and their peers in that profession. Developers, for example, constitute a thriving community, whose members are better at their trade in proportion to their community participation.

And their employers benefit from this by getting better programmers with a smaller investment in training.

Communities build capabilities.

And then there are customers. It might seem strange that customers need mentioning, but they do. Industrial businesses have a strong internal focus — so much so that most of the business considers other parts of the business to be their customers. This internal-customer focus is the source of untold mischief.

In a cognitive enterprise, everyone has the same customer — the real, paying customer who makes buying decisions about the company’s products and services.

And, understanding what these customers want, cognitive enterprises are able to marshal their capabilities to deliver it, whether or not they have a well-define process in place to do so.

Is this all there is to it? Of course not. If it was, Scott and I wouldn’t have had to write an entire book.

And we wouldn’t be asking you to read it.