If a methodology is so simple that it only requires you to do a few things and you're not doing those, than "you're doing it wrong" is not an excuse, it's an objective fact.
Besides that, given that Scrum is such a lightweight methodology, it's pretty hard to fail for competent programmers to fail using Scrum. Worst that can happen is that they find Scrum isn't an improvement over whatever they were doing before, which is cool. There's no one size fits all.
But failure is usually caused by other factors. The standard excuse for failing projects is of course blaming the methodology... Ever notice that in places where Scrum "fails" that is usually not exactly the first failure?
I disagree, Scrum's whole design and methodology (simple though it may be) contains serious flaws. Things like iterations (are we releasing iterations or features here?), as well as the poorly defined responsibilities of positions like the product owner and scrum master. Also it fails to adequately define how teams should confront the problems found in retrospective. Overall it often leads to a stuck process for the many, many teams that struggle with Scrum, and blaming everyone else for "doing it wrong" seems like a defensive cop out.
Scrum is to the product management process as management games like "colors" are to office team building and group psychology. Overly simplistic to the point of being nearly meaningless. By itself I find it provides very little real-world guidance for how teams should improve themselves and their process at all.
Thoughtful Edit: Don't get me wrong, I think Scrum has an initial value, but it is "meatless" for want of a better term. Anyone who really wants to improve a process for a dysfunctional team dynamic is going to need more than just some iterations and stories. Scrum is a starting point, but more often than not I think it is little more than that. Blame the team if you want, but I'll put at least some of the blame with the methodology not providing enough long term guidance.
I don't think it's reasonable to expect the process to define how a team should confront the problems found in a retrospective. Those project and team specific problems are likely to be unique and giving the team the framework to choose the best course of action is likely to more effective than some prescriptive process that says "If A then do B".
It also wasn't meant to provide guidance on how teams should improve themselves, that's up to the team to choose the best route to get there. It excels at enabling the team to make those decisions for themselves.
Besides that, given that Scrum is such a lightweight methodology, it's pretty hard to fail for competent programmers to fail using Scrum. Worst that can happen is that they find Scrum isn't an improvement over whatever they were doing before, which is cool. There's no one size fits all.
But failure is usually caused by other factors. The standard excuse for failing projects is of course blaming the methodology... Ever notice that in places where Scrum "fails" that is usually not exactly the first failure?