It depends.

For instance "No true Scotsman is born in Tuscany to Romanian parents and has never ventured west of Florence" isn't an instance of the fallacy because it truly does violate what it means to be a Scotsman.

Similarly, no true agile team would, say, agree to a single 6-month "sprint" at the end of which they will deliver the end product to a customer who has never seen it before, based only on a set of specs drawn up by an analyst.

And yet corporate shops that do similar absurd, not-within-the-common-idea-of-agile things will routinely label themselves as agile shops.

So what? It doesn't absolve the team of the fact that they're doing Agile incorrectly. Call them whatever you want, they're still Doing It Wrong.

The hitchhikers guide to the galaxy gave the most succinct advice for how to fly. You fall down and miss the ground.

The upon reading this and in the absence of any native examples of flying animals the pelzo decided to directly follow this grand advice. After 100 billion attempts, over a billion broken bones, and hundreds of millions of deaths the great zaxuvex finally discovered that the correct way to do so is to reach orbital velocity above the atmosphere in a space ship that provides an internal atmosphere, comfortable temperature, shielding from harmful radiation, chemical rockets to slow down, AND most importantly a heat shield and parachute for reentry. Two weeks later a vising dignitary introduced the idea for wings which was was deemed heretical and started the 42 great war.

PS: If your 'training courses' don't provide enough information to actually implement your process in the real world then it's practicably worthless.

Love this metaphor and there's some truth here but no amount of training is going to make a manager butt out when the manager is the problem.

Isn't it ironic that by simply capitalizing the word 'agile' you can change its meaning to describe something that's the very antithesis of agility?

If a methodology is so brittle that any diversion from the straight and narrow (a) means you're no longer using that methodology and (b) ostensibly (or actually) invites disaster, then that is a very, very rigid methodology.

That's like saying Javascript is a very rigid language because your program breaks if you change braces to parenthesis.