Yes, I have seen Scrum work well. The key is to recognize it is a tool for increasing team performance, team member autonomy, and increasing organizational transparency.
It is not a product management framework that should be used to manage inch/milestones and the like.
As soon as some sort of top-down control is (almost invariably) applied, it breaks Scrum. And most organizations want top-down oversight and control, not a high-performing team that may be resistant to organizational processes that negatively impact product development while satisfying other organizational needs (like LOC metrics or something else equally pointless).
Scrum is just empirical process control and improvement. The iterations aren't just to do the next thing on the backlog, but to improve the team's ability (and speed) to create working software that satisfies business needs.
The main reasons I have seen scrum fail are:
1) The organization implements a layer of management on top of Scrum that "won't effect it", but it does, because if you don't understand Scrum/agile, modifying it usually won't have the desired outcome.
2) Inexperienced Scrum Masters who act as a team leader, when their actual defined role is that servant coaches whose goals are to protect the process from interference and the team from organizational intrusion during sprints.
3) The transparency required for Scrum to operate reveals inefficiencies or actual malpractice at higher levels, and those levels are protected by management, creating a roadblock that cannot be passed.*
As you can tell, yes I have drunk the Kool-Aid, but I have seen Scrum (and other agile implementations) drastically improve performance and software quality, but you have to have buy-in and support from the highest levels to make it a success. When the process meets a roadblock that cannot be removed, it kind of kills the whole thing.
* Personally, I have seen it reveal:
- VPs who are actively preventing projects from succeeding (but who are protected by their level),
- Rockstar (cowboy) coders whose poor development practices (no source control, no testing, code in production) negatively impact the rest of the software teams, but as they are the CEO's buddy, nothing can be done to address the behavior,
- Database teams who successfully blame their errors on software development teams, because the Director of DB is a buddy of the President, so his word is taken over actual evidence