[JoeAltmaier]

They are certainly part of Scrum-master training. They're a widespread practice. At this point, they can be grouped as 'part of Scrum' with fair confidence, in any implementation you can point to.

Resorting to definitions is not helpful, when you work in a dysfunctional organization, and instituting Scrum was the root of the disfunction.

[mindcrime]

They are certainly part of Scrum-master training.

I am certified as a Professional Scrummaster, and none of those things were taught as part of any training I went through, nor were they mentioned on the certification test.

Referring to definitions is useful, when many people are misunderstanding the definition. If anything, we should be screaming from the hilltops "For the love of FSM, go read the Scrum Guide, and the Agile Manifesto, and show your managers and shitty Scrummasters what they're doing wrong." If we, as developers, are not willing to draw a line in the sand and take a stand sometimes, then what right do we have to complain? And if management won't listen to us on this, they aren't going to listen to us on anything else and we're back to "toxic management is the problem, not scrum."

[JoeAltmaier]

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

Looking at 'scrum master certification test questions' online I don't see anything about technical debt, variable-length time boxes, re-prioritizing work during a sprint etc.

A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work. Sure, making a list of tasks is quite useful. But the time-boxing and task atomizing can dissect the work to the point of dysfunction.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.

[mindcrime]

Or, not do Scrum. Do another process, like having an experienced team that respects the other team members to plan their time and prioritize tasks, with good communications between members of the team.

That seems orthogonal to the question of how desirable (or not) scrum is. You can have scrum (or not), and/or have "an experienced team that respects the other team members to plan their time and prioritize tasks" and shitty management is still going to wreck things.

A real and reasonable criticism of Scrum or Agile is, the structure is not helpful to the actual work.

I 100% agree that there are times when the structure imposed on a team in the name of Scrum (whether it's actually prescribed by Scrum or not) is harmful. Don't mistake what I'm saying here as a massive endorsement of Scrum. It's not actually my preferred methodology. But I do think Scrum can be useful to very many teams in very many situations, and I feel like a lot of the criticisms directed at scrum are somewhat misplaced.

If nobody is doing Scrum right, we're right on the edge of a No True Scotsman argument.

I think I get what you mean by that, and I probably agree to a point. But I don't think it's quite "No True Scotsman", as Scrum has an actual definition, to an extent that "true Scotsman" does not. But I'll buy the suggestion that "if everybody is doing it wrong, then there's something fundamentally wrong with the whole situation".