Scrum brings out some bad in software dev, but the worst in product management. It makes the schedule more important than the work, and the meetings more important than the communication.
Fix it with Kanban. Or at least the Kanban-flavored way of working where you set top priorities, keep lines of communication open, and just do what matters.
All processes can be screwed up if your leaders try hard enough, but Scrum is almost never the answer.
There's nothing wrong with making the schedule more important than the work, as long as you make it clear to product managers that they have to trade off work to meet a schedule. Or trade off quality, I suppose. But I am perhaps lucky enough to have never worked with a product manager that wanted a piece of shit when offered the choice.
The advantage to scrum when dealing with product management: an evolving prediction of what features you get, and when you'll get them. If you're neglecting the part where your product manager decides which features he can do without in order to meet his schedule, you're missing a vital part of the process.
That being said, I get your point with respect to sprints. There's something irrational about dividing work into sprints. But having done both, I prefer sprints. I'm honestly hard-pressed to say why. Maybe something to do with the psychological effect of feeling that you've accomplished something and done it well every two weeks, instead of once a year.
It may be true that one of the key traits of a software developer is low need for external motivation. But having done it both ways, there is something rather pleasant about getting those 30 second moments of satisfaction at having performed your craft well once every two weeks, instead of once every major product release.
In Kanban, you get that prediction of when features will be delivered by looking at the speed with which cards (on average) move across the board. If the average card takes 3 days, and you have 4 team members, and Feature card X is Y number of places down the board... do the math to know the timing. (And yes, that average takes some time before it is consistent, but so does the velocity in Scrum)
It takes some getting used to, but in the end the PM not only has the information of when features can get delivered, they have more control because all they need to do to change a feature's timing is drag it higher on the board. No meetings, no fuss, just drag and be done.
I think PMs who declare they need Scrum for timing purposes have never explored the equivalent timings in Kanban. If they prefer Scrum, that is fine... but claiming that Kanban can't time features is incorrect.
Fix it with Kanban. Or at least the Kanban-flavored way of working where you set top priorities, keep lines of communication open, and just do what matters.
All processes can be screwed up if your leaders try hard enough, but Scrum is almost never the answer.