All Posts in Strategy and Tactics

|In: App Dev Methodologies|Last Updated:

Consider the Titanic.

Based on entire minutes spent Googling, it appears the ship’s lookout spotted the iceberg that sank the ship when it was about 2,000 feet away. This seems like plenty of time to steer around a hazard, and it would have been plenty of time — at 20 knots, almost a full minute — had the Titanic been, say, a fishing trawler.

It wasn’t. It was the biggest ocean liner of its day, and even with a rudder 78 feet 8 inches high and 15 feet 3 inches long, its turning radius at full speed was about 1,900 feet.

1,900 feet being a shorter distance than 2,000 feet, it appears there was enough room for the Titanic to miss the iceberg. But history and John Cameron tell us it didn’t miss.

What went wrong? It turns out the decision as to whether to steer around the hazard or to maintain course turns out to have been quite a bit more complicated than hindsight makes it appear. If this makes no sense to you: The ship might have missed the iceberg, which was after all in motion, by maintaining course; trying to steer around the iceberg might have resulted in impact closer to the stern, doing more damage; reducing engine power to reduce speed would have reduced the rudder’s effectiveness, to name three complications among many.

In the end it was a judgment call that took 37 seconds to make — enough time for the Titanic to have missed the iceberg. If you’re interested, read “The 30 seconds that sank the Titanic — fatal delay in order to change course doomed liner,” Jasper Copping, Daily Telegraph, 12/4/2011.)

Which has what to do with the worlds of IT, business, and their intersection?

Start with 20/20 hindsight. I’m assigning you the mission to allocate blame … sorry, to determine the root cause. You start with the most basic question: Was the problem that the ship’s turning radius was too big, or that it took too long to decide to change course?

The answer is, of course, yes.

And now (at last!) we’re ready for business, IT, decision-making, and all things Agile.

As we all know, IT has to adopt Agile. If you don’t use Agile techniques by now you’re two hops short of current thinking, current thinking having moved to DevOps, which is itself a hop short of what’s actually needed.

Among Agile’s many benefits compared to Waterfall alternatives are two sides of one coin that gets far too little attention.

Side 1 is Agile’s ability to reduce the damage done by the management fad du jour.

Something largely unappreciated about fads du jour is that in the eyes of the managers who sponsor them they aren’t fads at all. They’re responses to important business trends, marketplace shifts, new and better thinking … that sort of thing. But time passes, sponsors move on or lose influence, gratification is less than instantaneous, and the executive leadership team (ELT) moves on to whatever is next in queue.

But in the meantime, through various governance mechanisms rooted in Waterfall-based assumptions about how much time and investment is needed to make change happen, a very large fraction of the company’s total discretionary budget is directed to turn the fad du jour into operating business reality.

Which in turn makes it unavailable for other, more valuable but less strategic uses for timescales measured in years.

With Agile techniques, companies can slow down or stop business change efforts sooner and still get some value out of them because Agile delivers working stuff in timescales measured in weeks (sprints), and tangible business change in months (releases).

One of Agile’s most important characteristics is a governance mechanism that, depending which Agile variant you use, changes priorities dynamically in these same timescales.

Which in turn means fads du jour‘s resource commitments don’t have to be any longer than this.

Side 2 is the exact same thing, only instead of mitigating the damage done by fads du jour draining resources away from higher-value efforts, it accelerates the value provided by projects that with Agile deliver business change in months instead of years.

In Titanic Governance terms, it means decisions about how best to avoid various business icebergs can be made faster and changed faster.

While it’s stretching the metaphor just a bit, Agile itself is parallel to reducing the Titanic’s turning radius. Agile Governance, done right, decides to turn to avoid the iceberg faster.

Done wrong, the same old governance, unconsciously based on the same old Waterfall assumptions, can crash even the best Agile project practices right into the same old decision-delay icebergs.

Comments

|In: Industry Commentary|Last Updated:

Metrics are less useful than you’ve been told. Even the best are just ratios that tell you whether you’re making progress toward a well-defined goal.

But not why, how, or what to do if you aren’t. As last week’s KJR pointed out, not only aren’t metrics explanatory on their own, in most cases a metrics change won’t have a single root cause. If, for example, you’re losing marketshare, you might have:

  • Missed a complete marketplace shift.
  • Lousy advertising.
  • No advertising, lousy or otherwise.
  • Poor quality products.
  • Deplorably ugly products.
  • Products that lack key features competitors have.
  • Hapless distributors.
  • Hapful distributors who like your competitors better.
  • A customer disservice hotline.

To list just a few possible causes, none of which are mutually exclusive.

Which is to say, root cause analysis is a multivariate affair, which is why analytics is, or at least should be, the new metrics.

But while multivariatism is an important complicating factor when business decision-makers have to decide what to do when success isn’t happening the way it should, it isn’t the only complicating factor.

Far more difficult to understand in any quantitative fashion is the nasty habit many business effects have of causing themselves.

Many cause-and-effect relationships are, that is, loops.

These feedback loops come in more than one flavor. There are vicious and virtuous cycles, and there are positive and negative feedback loops.

In business, the cycles you want are the virtuous ones. They’re where success breeds more success. Apple under Steve Jobs was, for example, a successful fanbody fosterer. (Don’t like “fanbody”? Send me a better gender-neutral alternative).

The more fanbodies Apple has the cooler its products are, making it more likely the next electronics consumer will become another Apple fanbody.

These loops work in reverse, too: Start to lose marketshare and a vicious cycle often ensues. Corporate IT pays close attention to this effect: When choosing corporate technology standards, products that are failing in the marketplace are undesirable no matter how strong they might be technically. Why? Because products that are losing share are less likely to get new features and other forms of support than competing products.

So IT doesn’t buy them, and so the companies that sell them have less money to invest in making them competitive and attractive, and so IT doesn’t buy them.

A frequently misunderstood nicety: virtuous and vicious cycles are both positive feedback loops. In both cases an effect causes more of itself.

Negative feedback loops aren’t like that. Negative feedback as the term is properly used is corrective. With negative feedback loops, an effect makes itself less likely than it was before.

Take business culture. It’s self-reinforcing. When someone strays from accepted behavioral norms, their co-workers disapprove in ways that are clear and punitive.

Want an example? Of course you do. In many companies, employees are known to complain about management. Not necessarily any particular manager, but about management.

An employee who, in conversation, makes complimentary statements about management is likely to be ostracized, no matter how justified the statements might be.

Symmetry requires negative feedback loops to have unfortunate as well as fortunate outcomes, just as positive feedback loops do. Here’s a well-known one: Analysis paralysis. It’s what happens when corrective feedback overwhelms all other decision criteria.

Where does all this go?

The idea behind “if you can’t measure you can’t manage” is well-intentioned. Underneath it is an important idea — that you should prefer to base your decisions on data and logic, rather than your mood and digestive condition.

The point here is that those who lead large organizations need to kick it up a notch. Measurement isn’t the point, and it isn’t the be-all and end-all of decision-making. It’s just a part of something much bigger and more important: Leaders and managers need to understand how their organizations work. That includes understanding the simple cause-and-effect relationships metrics tend to be associated with, and the multivariate causal relationships multivariate analytics can help you understand.

And, you should add to that at least a qualitative understanding of the various feedback loops that drive success or failure in your line of work.

A quantitative understanding would be better. It’s just not often possible.

Qualitative might be inferior to quantitative, but it’s much better than ignoring something important, just because you can’t put a number to it.

As Einstein … by all accounts a bright guy … put it, “Not everything that can be counted counts, and not everything that counts can be counted.

Comments