Engineering management is a culture. Cultures have shared mythologies and values that bind the tribe together, that tell members who they are and their place in the world. Two key commitments of this particular culture are metrics and standardization.

Otherwise rational and pragmatic leaders will either pretend not to hear you or look at you like you have three heads when you make an argument that seriously challenges one of these commitments. Very smart ones have some trite stock answers as defense mechanisms. This is because you are committing a type error. This kind of argumentation is valid with respect to rational strategies adopted instrumentally towards goals. The commitment to uniformity is deeper than that.

Scrum is the recognized best practice; we make sure that all tendrils of the organization follow a standard and that this standard is aligned with recognized best practice because that is the kind of people we are.

From my experience the problem is that Scrum guides say (or used to say, it might have changed) that in order to do Scrum, you need to do it all. So all the certified Scrum Masters learn that they have to do daily stand-ups and all the other meetings, and because they believe their job is to implement Scrum (instead of making the team more productive), they enforce it all.

Every time I worked with certified Scrum Masters I had exactly the same struggles.

You raise a good point, and I’ve seen this in other contexts.

Team wants to be better at X. Y is a tool or process that helps them get there.

At some point, the goal of X is forgotten and Y subsumes everything, sometimes to the detriment of X.

It’s like a weird correlate or inversion of the XY problem and I’ve seen it in a lot of contexts.