One of the most reliable indicators I know of a dysfunctional team is on average how many times whether what being proposed is sufficiently agile is put to question per meeting. If this is greater than some epsilon much smaller than 1, then you have trouble.

Overall "is that really agile though?" is such a fantastic thought stopper. It's can be thrown out to derail any sort of proceeding. It moves all focus from what's practical and applicable and relevant to the situation at hand, and moves it to an endless discussion about philsophical alignment.

And in fact (if you read to the end) that is exactly what the author is claiming. Which is why the title is clickbait.

It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman.

Whether it is or isn't depends on your feelings on scrum, but it's not a fallacy to try to defend the initial definition before it was co-opted by anyone with an Agile cert.

"Hammers suck at driving nails." "You're holding a rubber mallet." "No true Scotsman!"

This. People love dunking on Scrum because they have colleagues and managers that wield it as a weapon (often in conjunction with JIRA, which, although not an especially simple or well-running piece of software, is really only as bad as you choose to make it). It's actually a very simple process that was designed as the _antithesis_ to a lot of the atrocities committed in its name (based on a reading of this thread).

If you have managers/PMs/TMs/HMs/BDFLs that can't see the forest from the trees and a corporate mandate to use Scrum (or Agile generally) then of course they'll pervert it to suit their own ends. Slow-moving organizations with complex incentive structures like the government and Fortune 500s are especially good at this. If you want to be upset with somebody then blame them. I've worked on teams where stand-ups were less than ten minutes long, we delivered every two weeks, and we had properly-specified Scrum Master and Product Manager roles and it worked swimmingly because we _actually did Scrum_, not "Scrum, but...".

Scrum is a prescribed process. It is not the performative act of dragging work items into Sprints in JIRA then using various Scrum terms for 5-hour-long weekly meetings.

> It's not a "no true Scotsman" (scrumsman :)) if the counterexample is in fact not a Scotsman.

Every bad Scrum/Agile situation I've been in has orchestrated by people who were convinced they were doing it "the right way"

Every defense I've read has been from other people who weren't there who insist that it must be "the wrong way".

If you define the "right way" such that it can only be good, then you conveniently dismiss all of the negative criticisms at once. Yet in the real world, there appear to be a lot of us stuck in companies who think they're doing it by the book but it's still not working out.

Let's do a thought experiment. Imagine you have the same organization, same people, but a different methodology or perhaps no methodoligy at all. Would things get significantly better?

I can't imagine how it could get any worse.

It became really difficult to push back on or change anything because the Program Managers would band together and brandish their Scrum certifications, Scrum books, Scrum podcasts, and other credentials to show that we couldn't argue with them. Unfortunately, it worked with management.

Wipe all of that away and let all of us work together toward a methodology that worked for everyone without Product Managers playing the Scrum card at every disagreement and I have no doubt it would have been better.

In fact, I have some proof: There were a few pockets of small teams that got to operate outside of the Scrum madness either because their tasks were thought to be too small or temporary, or because they existed in islands of the org chart that were free from the reaches of the Scrum people. These small teams ran circles around everyone else, but that would come grinding to a halt as soon as their projects got assimilated into the Scrum catastrophe.

I always wonder if they have retrospectives in those situations. And if so, what they actually do there.

In my opinion, retrospectives give the power to the team to improve their own process. Without self-organizing teams, you have no agile. So without retrospectives, you have no agile. So I always wonder if and what they do during these retrospectives.

And agile methodologies are not agile by the definition. Agile is a set of relative values, not a methodology. The first being to value people and interactions over processes and tools. No process is agile, no process can be.

I hear these aphorisms a lot, but none of it actually matters.

Agile has been plastered over certifications, podcasts, books, conferences, trainings, and everything else for years. The people I referred to above had been through it all and brandished it like a weapon. You can tell me all day that it's not true agile but it didn't make an iota of difference to how things play out.

Judging by the comments, my experience is not unique.

You make a good point! But scrum as we know it today is not Agile:

"Individuals and interactions over processes and tools."

Processes and tools (i.e. Jira, sprint planning, retrospectives, etc.) dominate all implementations of Scrum I've seen.