Google “Scaled Agile” and among the 148,000 or so results (148,001 including this article) you’ll find several claiming to provide best practice.

Here’s the problem: The first mention of Scaled Agile was in or around 2008.

Sacrifice the first three years to just selling the idea to a few adventurous clients willing to try a new, untested approach to things and you’re left with just four years in which to try it in enough environments to even call it a well-tested practice. Proven practice? I don’t think so. Best practice? Not a chance.

But what I just said was wrong. I said, “Here’s the problem,” when I should have said, “Here’s just one of the problems.” The Scaled Agile frameworks I’ve read about or seen put into practice have problems far worse than semantic puffery.

Even if you aren’t a student of Agile you’ve seen its four core principles:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

You know what’s coming.

Look at your typical Scaled Agile framework (pick one from your Google search). You’ll find it has more moving parts than an F-22, and if that’s an exaggeration you’ll find it does have as many moving parts as most depictions of waterfall software development.

Scaled Agile violates the first principle of Agile — it emphasizes processes and tools over individuals and interactions.

It also violates the fourth principle — not intentionally but because of what most Scaled Agile frameworks exist to accomplish. In theory their purpose is to scale Agile up so it can take on the big problems. But taking on big problems presupposes you think in terms of big problems in the first place — in terms, that is, of taking a big problem and, through a process of successive decomposition, creating a detailed enough view of its components that everyone’s work will come together into a coherent solution.

Create a detailed view like this and everyone involved in its creation will do what they can to avoid making adjustments to it, for the simple reason that it’s hard enough to create a big plan in the first place. Fiddling with it means tracking down all the ripple effects of the proposed change, which is hard, skull-busting work.

Thanks very much for your brilliant idea. We’ll take it under advisement.

And then, as the famous Sidney Harris cartoon has it, a miracle occurs: Scaled Agile calls for a multi-day meeting that includes all members of all teams working on a release — easily 50 or more participants. Think “participant” is an accurate description of most people attending a meeting that big? “Audience” is more likely. Conducting an effective multi-day meeting with that many participants would take a miracle.

One more gripe before coming to grips: Based, at least, on my unscientific sample, if you squint at your average Scaled Agile framework you’ll find one or more committees lurking in the shadows.

It isn’t that committees aren’t sometimes necessary. It’s that “committee” and “agile” are organizational opposites. Committees meet on a defined schedule. That schedule acts as a sort of “governance governor.” It establishes the pace of change over whatever it is they govern.

Based on the companies my colleagues and I have looked at, Scaled Agile generally turns out to be, not only not Agile, but slower and less flexible than its waterfall alternatives.

Let’s reel all this back in and start over. Agile got its start because it faced a reality of business that conflicted with waterfall’s most important hidden assumption — that detailed specifications will still be relevant when they’re turned into code.

But more often than not, for a big piece of software, by the time this happens through waterfall’s feasibility/requirements/specifications/coding/testing/deployment cycle, the business marketplace will have changed. The software solves a problem that no longer exists while failing to solve the new problems that do.

Agile’s primary virtue is that it stops the pretending. Like waterfall it breaks big problems into small ones, but it solves them now, one or a few at a time, in order of their current business priority.

Did priorities change since the last look at the list of small problems? Discard the ones that aren’t relevant any more, add whatever new ones have been discovered, and return to solving today’s problems right now.

Have a problem big and complex enough to require Scaled Agile? Waterfall is probably a better choice.

But a change in business attitude would be better yet. Very often, solving today’s problem today followed by a fresh reconnoiter is just what the strategy doctor ordered.

Or should have.