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.

In response to my recent plugging of my daughter’s nascent contract programming business and my reference to the POTUS’ Twittering support of his own daughter’s business to justify it, a long time subscriber and correspondent wrote, “I am SICK TO DEATH of the politicization of EVERYTHING. Strike two, I unsubscribe next time.”

Huh. I thought I’d indulged in nothing more than a harmless wisecrack, and in fact, unlike various recent Oscar winners, I’ve restrained myself from political commentary in KJR in spite of near-daily temptations.

And, let me cast my vote in the same direction: I’m also sick to death of the politicization of everything, although I doubt my correspondent and I mean the same thing when we say it.

Which brings us to this week’s anti-politicized topic: dealing with politicization in the organization you work in.

But first, let’s be clear about what “politicized” means.

At the easiest-to-deal-with level, politicization means talking about politics in the office. It’s easy to deal with because given the current public political climate it’s an awful idea. Nothing good can come from it … no one will persuade anyone who isn’t already on their side of a given issue and there’s no need to persuade someone who already is.

Either way the most likely outcome of a political conversation is inflammation for all conversing parties, who all also risk damaging their personal relationships with the each other party in the bargain.

At the next level, politicization is a synonym for tribalism: Dividing the world into us and them and viewing them, not as opponents, but as enemies. In the public sphere this is what has made our political climate so toxic. In the enterprise it’s one of the root causes of organizational silos with high walls and minimal collaboration.

Worse is that tribalism almost invariably escalates, as each side views hostile behavior on the other’s part through a magnifying lens, calling for an even-more amplified response.

It’s my impression that silo-driven attitudes and behavior are, as a broad trend, becoming worse in most enterprises, although, as there is no good measure of organizational silo height I can’t prove the point. Nonetheless, whatever the trend line, politicized organizations in this sense of the word handicap themselves when competing with their more cognitive counterparts.

But not as badly as organizations that take politicization to the next level. Call it political epistemology.

Epistemology — the study of what it means to “know” something — is, in addition to being eye-glazingly opaque, quite frustrating to deal with. Peel the epistemological onion and you’ll reach two equally unsatisfying conclusions: (1) It is sensible to be more confident of some propositions than others, based on the comparative levels of evidence and logic in their favor. But (2) it isn’t sensible to be completely certain of any proposition, with the possible exception of the proposition that certainty isn’t possible.

Political epistemology is what happens when what to believe and how certain to be of it depends on an individual’s tribal inclinations.

Never mind public policy and how someone’s party affiliation shapes their beliefs about What Works. There are plenty of business examples right in front of you, from decisions about strategy, to IT’s choice of virtualization technology, to which PaaS provider is best, and whether to deploy its technology stack inside the corporate firewall or to contract for external hosting.

No, no, no, no, no. I’m not saying Democrats favor private clouds while Republicans prefer public ones. Among the metaphorical breakdowns here: Businesses tend to have more than just two major metaphorical political parties. Heck, IT tends to have more than just two, with many IT professionals enjoying at least dual citizenship besides, with such fracture lines as Windows vs Linux, COTS (commercial off-the-shelf) vs open source, Waterfall vs Agile, and Engineering-and-Architecture vs Management-and-Finance.

The hazard doesn’t come from individuals having these inclinations. They’re natural and probably inevitable.

No, the hazard comes from the close-minded certainty that starts with “my tribe is good, my tribe’s allies are good enough, and every other tribe is deluded and evil” and finishes with the by now commonplace phrase “confirmation bias,” which means, if you’re among the uninitiated, that people uncritically accept any and all inputs that affirm their pre-existing beliefs while nit-picking to death anything that appears to contradict them.

Is Keep the Joint Running becoming politicized? As the poet Robert Burns wrote,

O wad some Power the giftie gie us
To see oursels as ithers see us!
It wad frae mony a blunder free us,
An’ foolish notion

Which is to say, you’ll have to tell me.