Metrics – Page 13 – 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.

Data, information, knowledge, judgment, and wisdom

The dullest, and probably the most important chapter in The Cognitive Enterprise (Bob Lewis and Scott Lee, 2016) addresses a central topic when it comes to cognition: What does it mean for an organization to “know” something?

We started with the tired old “knowledge pyramid” — you know, the one that starts with Data and progresses through Information and Knowledge until arriving at Wisdom (DIKW).

The old pyramid gets just about everything wrong, at least as it’s usually explained. And the flaws matter: For an enterprise to act as if it thinks, getting this right is essential.

Here’s an overview. To get the whole story you’ll need to buy the book. It pains me to say this, and I plan to continue in my agony until you … that’s right, you, the person reading these words right now … until you get yourself a copy and write an honest review on Amazon.

Where was I. That’s right — the old DIKW pyramid and what to do about it.

Start with Data. Most of DIKW’s proponents would have you think that every byte stored on your company’s hard drives, NASes and SANs is data. When you read an awe-inducing statistic about the data explosion, it’s probably based on the every-byte-stored definition. You’d think the GIGO principle (Garbage In/Garbage Out) was still waiting to be formulated.

Data (plural of datum if anyone still cares about such things) is actually a collection of individually verifiable facts. Your eye color is a datum. So are your driver’s license number, your annual income, and how many miles you walk every week.

Data aren’t always verified, but they must be verifiable.

Information next. No, it isn’t data that have been processed to provide something useful. Definitions like this entirely ignore the well-developed branch of mathematics upon which the entire data process industry is founded: Information theory.

Information is the stuff that reduces uncertainty. It comes in bits, one of which is the quantity of information that cuts your uncertainty about something in half. The classic example is a coin toss. You know it either landed heads or tails. One bit of information will resolve your uncertainty about the result.

For the most part, though, information doesn’t eliminate uncertainty. It reduces it — a very different matter. Even in the case of the coin toss, if someone tells you it landed heads you still aren’t absolutely sure. Your informant might, for example, be an untrustworthy source.

Information is, by the way, what a good system of metrics provides.

Which gets us to knowledge – a word that’s been hard to pin down since Plato first wrote about it a few millennia back, not that he got anywhere with his ponderings.

I’m not criticizing, mind you. Epistemology is an eyeball-crossing domain.

Scientists generally rely on Karl Popper’s approach to things: You start with a proposition and do everything you can to disprove it. A proposition that’s survived all the tests human ingenuity can subject it to — nobody can think of any more tests that might disprove it — is considered by scientists to be something they “know,” in quotes because they know that everything they “know” is just one additional test away from being something they used to know, only now they know better.

Business managers (and, for that matter, consultants) don’t have the luxury of subjecting their knowledge to testing that’s as thorough as what scientists are able to manage. We have to make do.

Scott and I are practical guys, not epistemologists. We figure you know something if you’ve looked into it extensively and have concluded there’s just no point in worrying about it anymore. You still might be wrong, but you’re more than certain enough to act.

Then we added a new layer: Judgment. It sits between knowledge and wisdom in the pyramid. Judgment is about tempering your knowledge about something with related insights that come from experience. It’s your safety net when making difficult decisions.

At the top of the pyramid there’s wisdom — broad principles about important subjects, which you don’t find very often, and when you do it’s rarely in the domain of commerce.

Now, finally, we’re ready to talk about what it means for an enterprise to be cognitive. It means the enterprise does a fair imitation of knowing things, as distinct from the people in it knowing things.

In a cognitive enterprise, when it comes to the most important subjects, most people share similar views, with similar levels of certainty, and so can be trusted to make similar decisions when it’s their turn to do so.

A different way of saying it: In a cognitive enterprise, knowledge becomes culture, and culture becomes the centerpiece of governance.