Agree to disagree. Nobody does scrum "correctly". Generally only the parts that are supposed to squeeze the most short term value from the employees are picked.
There's no reason why anyone should need to be "certified" for a methodology to be applied. There isn't even a reason why SCUM methodology should be applied as a sort of universally applicable process.
The funniest thing about SCUM is that every diagram someone makes of it looks nearly identical to the straw man that is "Waterfall."
I mean, tell me that you couldn't change some of the jargon on that diagram and fool just about everyone into thinking it describes Waterfall.
The only thing potentially differentiating between SCUM and Waterfall is that the former has (in theory) a smaller iteration window and has liaisons between development and management. But the latter argument is nonsense because generally non-agile teams still self-organize into having liaisons and middle-managers.
And as you pointed out, the answer to why SCUM fails always comes down to not doing it "correctly". If no one can do it correctly, that's because it sucks. I've seen agile principles applied in different ways successfully, but I've never seen SCUM actually work any better than no formal methodology at all.
Thanks for calling it what it actually is. We are having developers hired/not-hired on their descriptions of Agile/Scrum/TDD etc in interviews. Imagine that!
Nobody does it "correctly" because they try to use it for a bunch of things that it shouldn't be used for - like performance comparsions.
Scrum is only a capacity planning tool. Within a certain context, track velocity. When new work comes in, estimate it then compare to velocity. If you don't have the timelines you want, then you need to consider changing scope.
#/media/File:Scrum_Framework.png){kind=link}