About the same percentage as that of “Agile” software development shops that put people and interactions above processes and tools.
OTOH, at any place that is considering implementing either, there are decision makers who can influence (or in the case of Scrum more than Agile, authoritatively direct) whether or not that's the case, so for them, at least, it's worth distinguishing between problems with Scrum as prescribed and problems which often occur because decision-makers decided to ignore key parts of Scrum-as-prescribed.
Given that, I think it's worth considering that the problem is Scrum. Especially given that Scrum is not just a process, but an organization and an army of "certified" people that sell services.
When something generally doesn't work for its stated purpose but keeps making money, I think it's worth asking what its real purpose is. E.g., things like crystals and psychics. As Eric Hoffer wrote, “Every great cause begins as a movement, becomes a business, and eventually degenerates into a racket.”
No, most nominally Agile shops are also nominally doing Scrum, but actually doing not-Scrum in a not-Agile context, largely due to sabotage of both core principles of Agile and foundational elements of Scrum by management.
It doesn't matter what name and superficial ritual you put on the process if it's all window dressing over top-down disempowering command-and-control by persons who are neither doing the work nor experts on the work.
Which isn't to say that the Agile and Scrum bodies of work aren't part of the problem: neither really addresses as a key point how the team effectuates ownership of process and how interaction with management works, which means those gaps get filled in (or rendered moot, in the first case) in ways which compromise what those bodies of work do prescribe because.
Lean, which comes from basically the same perspective (while they don't cite exactly the same values as expressed in the Agile Manifesto, being Lean essentially implies being Agile and vice versa) and is a good body of knowledge to draw from alongside Agile, is better in this regard, and so places nominally drawing on Lean seen to be more likely to be doing what they say, because Lean doesn't leave as much of the core vital parts without good guidance.
This process adjustment usually means "sorry about your vacation" and/or "you aren't doing enough overtime".
(Of course, if the wrong actor is monitoring velocity and controlling process, then the team has an incentive to mask the effect of tech debt but continuously adjusting estimates to maintain the illusion of constant velocity, a d avoid the first bad response, or, if that opportunity is missed, to avoid the subsequent external interventions.
No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iterations.
> munching through backlog items fed to them by product managers.
That's...not actually Scrum, as it implies that either the role of Product Owner is taken by a PM outside of the Scrum Team or that that the Scrum Team is not self-organizing, either of which is a significant (even if common) deviation from Scrum.
> the blinkers of "sprints" encourage growth of tech debt because nobody has an eye on the future
Tech debt should manifest in reduced velocity which should be noticed, taken as a signal of a process defect, and addressed in the Scrub Team’s various inspection and process adjustment points.
OTOH, if the Scrum Team is properly cross-functional and self-organizing instead of having a non-team-member imposed as Product Owner, then including appropriate restarting as components of completion of relevant backlog items shouldn't be a problem.