Industry Commentary – Page 51 – IS Survivor Publishing

There’s no need to fear. Scrummerfall is here!

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.

Market failures, volume 3

We’ve been talking about market failure and how it applies to IT departments that are “run like a business” that sells information technology to its “internal customers.”

When it comes to causes of market failure, monopolies might be the most obvious, but the Tragedy of the Commons is the monster.

Discovered by William Forster Lloyd in 1833 and popularized by Garrett Hardin a century and a half later, the tragedy of the commons is what happens when someone with access to a shared resource gains an economic advantage by using as much of it as they can. It happens because everyone will do the same, collectively wreck the commons they all rely on.

Sadly, most of the easily recognized examples are political or politicized, as in the case of The Cuyahoga River, which runs through Cleveland. It was, in the 1960s, a waste disposal resource. Because it was both shared and unregulated … that is, everyone relied on market forces to allocate it fairly and efficiently … any company that wanted to could and did dump as much as they wanted into it.

Not only was there no economic incentive to avoid overusing the Cuyahoga, the opposite was true. For every industry in Cleveland, dumping their pollutants into the river was cheaper than any other waste disposal alternative.

As a result, the Cuyahoga River became flammable, leading to one of Randy Newman’s better songs and the birth of the Environmental Protection Agency.

Not to mention how the fire department probably responded when the call came in. I see Bob Newhart, or maybe Lily Tomlin plays the part of the fire chief: “What’s on fire?” A snort. “So what do you want us to do — aim our firehoses at it?”

But you’re leading IT, not the Cleveland fire department and your commons isn’t a river, it’s the collective IT architecture.

If you’re a monopoly provider, you can control access and use because it’s your commons. You own it. You don’t let anyone else make any changes to it. You rent its capabilities to your internal customers, with rent payments coming in the form of chargebacks.

But then you’re a monopoly provider, which makes you a cause of IT market failure — see “Market failures, volume 1,” KJR, 5/22/2017).

You could open the technical architecture to all comers, resulting in shadow IT gone wild. It would be like a housing development where someone buys a lot and erects a 20 story hotel there because land and property taxes are lower.

And then, because the one hotel is profitable, other hotel chains do the same thing, all connecting their buildings to water and sewer systems designed for a collection of single family houses.

This doesn’t happen in the suburbs because municipalities have zoning laws, regulating the use of their shared services.

But, as The Economist pointed out a long time ago, analogies aren’t the same thing as being the same thing. IT isn’t a municipality, so I’m not sure there’s a lot a CIO can learn by exploring the differences between how, say, Washington DC, Lake Forest, Illinois, and Beaver Bay, Minnesota manage their respective commons.

Instead: If you must run IT as a business, don’t want to be a monopoly, and still want to preserve the integrity of your company’s technical architecture, here are a three steps you can take that let the business gain the considerable advantages to be had from shadow IT, without it trashing the IT commons.

Establish enterprise architecture governance: Returning to the urban metaphor, standards are IT’s zoning laws and enterprise architecture governance is how IT sets its standards. Shadow IT is just fine and dandy so long as it’s in the right zones.
Culture is the new governance: As pointed out in this space and in The Cognitive Enterprise, there’s nothing in an organization so slow that a committee can’t brake it even more. So while you need zoning laws and zones, their enforcement should be 90% cultural — defined as “how we do things around here” — and only 10% through formal committee-driven reviews.
Create a Superfund: If you’re running IT as a business and some shadow-IT-based application messes up your technical architecture, whoever made the mess should pay you to clean it up. You’re already charging back. This is just another line item.

Not that I’m advocating running IT like a business. But if you’re going to do it, you might as well prevent market failures as you do.