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.

It’s pop quiz time. The quiz has one question: Which application development methodology is gaining the most popularity?

If you answered “Agile,” Blaaaaaaat! Wrong answer bucko.

If you tried to demonstrate your more in-depth knowledge of the app dev landscape by answering “Scrum,” Blaaaaaaat! Nice try, but wrongo.

Test Driven Development (TDD) or one of its variants, Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD), you’re just showing off. But Blaaaaaaat! TDD might be a technician’s paradise, and for that matter it might be a very good idea, but it isn’t what’s gaining the most acceptance.

Want one more guess? I’ll give you a hint: What do you get when you combine a change in process with the same old attitudes?

Now you’ve got it. The app dev methodology that’s sweeping the world is (drumroll) … Scrummerfall!

Scrummerfall (not an original term) is what you get when you stitch a Waterfall head onto a Scrum body. It’s what happens when you do want iteration and incrementalism, but for one reason or another want developers to do nothing but write code to specifications — you have no interest in their understanding the context, business purpose, or user predilections.

To be fair (an excruciating exercise but I’ll try) there are good reasons for going this route. In particular, if you’re willing to trade off Agile’s high levels of team engagement, enthusiasm and commitment for the large savings in raw labor rates you get from sending work offshore, Scrummerfall might be the right choice for you.

This is especially true in organizations that consider financial measures to be the only measures that matter, because from a purely financial perspective, it’s iteration and incrementalism that drain most of the risk from Waterfall’s combination of long-range planning and short-range planning accuracy. If all you do is wait as long as possible before making design decisions, that by itself will increase your project success rate.

What do you have to lose?

Quite a lot, as it happens. The problem is, what you lose by settling for Scrummerfall is much harder to quantify, because with Scrummerfall, what you keep is form but what you lose is essence.

Another way of saying it: Scrummerfall is an excellent example of what goes wrong when you mistake a business practice for a business processes. For the difference, see “Is it a Process, or just a process?KJR 5/17/1999, although when I wrote it I used lowercase “process” where “practice” is now my preferred vocabulary.

In any event, with a true process, following the right steps in the right order gets you to the desired result. They’re repeatable and all that. The assembly line is your model.

That isn’t true with a practice. Following the right steps in the right order is just the ante that lets you play the game.

With a process, the steps are the essence. With a practice, they’re separate, and following the steps while losing the essence means the steps generally degenerate into nothing more than a bunch of check boxes people follow because they have to, not because they add any value to the proceedings.

And so to the differences between Agile and Scrummerfall. Start with the basics: Writing user stories and estimating them by assigning story points. (If you’re unfamiliar with these terms, user stories are the Agile equivalent of requirements; story points are vaguely equivalent to function points only they’re heuristic, not algorithmic.)

With Agile, the whole team writes the stories and assigns the story points, which means the whole team understands all of the requirements and commits to their estimated difficulty.

With Scrummerfall, business analysts write the stories and assign the story points. Team members only understand the user stories assigned to them for development, and instead of assigning story points … estimates of relative difficulty … the business analysts estimate the time that should be needed for development.

Anyone who’s been on either side of any exercise in delegation knows the difference between me telling you how much time you should need to achieve your assignment and the you telling me how much time you’ll need.

What’s the financial impact of the difference? We can envision what the research needed to answer a question like this might look like, but I certainly can’t imagine who might pay for the research, let alone any business leaders making decisions based on this research.

There’s one more piece of this puzzle to mention right now, and that’s the core model for The Cognitive Enterprise — that cognitive enterprises replace the old people/process/technology model with customers, communities, and capabilities.

With true Agile, developers and business stakeholders form a community.

With Scrummerfall, they’re just cogs in a machine.