That's an easy thing to say. The harder thing is what system should replace sprints, and why is it better?
* Engineers rushing to wrap up for the sprint (stress and decreased quality is bad for morale)
* Engineers getting monitored and measured on a task level since all tasks need to be estimated (micromanagement, lack of trust)
* Agility is decreased since everything needs to be planned (lack of autonomy)
Sprints tend to become “phony deadlines”, a key component in “Teamicide” (from “Peopleware”).
I’ve been trying to come up with benefits but I’m coming up short. Wish someone could tell me!
I get the sense most managers stick to scrum and all the unnecessary overhead mainly because they are creatures of habit. Pushing a non-scrum system in an organization that fully embraces it is hard (especially when senior leaders enjoy the micromanaging aspects of it).
That's in the unicorn-rare case that you're in an org that can do "agile" right, but still has the problem of clueless stakeholders shitting everywhere and no discipline or expectation that PMs are empowered to tell them (politely) to fuck off without the support of this kind of framework. Otherwise, yeah, they're not that useful. You can track velocity and such without them, so that's not a good reason to have them.
The dysfunction can certainly go the other way (the stakeholders are competent and reasonable, but the teams are broken) in which case I'd not expect sprints to be helpful, and possibly abusable in the ways you suggest.
> if a team can only plan a couple of weeks ahead, how should stakeholders be able to plan?
When it's done right (ha, ha, ha) there absolutely is long-term planning, but adjustment of priorities sprint-to-sprint (which should be happening due to stakeholders and product managers and such making decisions, since they set those priorities) can affect that—the flux in long-term planning should be a reflection of the reality of choices made sprint to sprint that differ from the original plan, not due to a lack of planning, so that no-one's surprised when the mark that's hit in six months differs—for the good reason that the direction of the project was modified in-flight—from the one that was originally targeted. The entire point of sprints is to allow flexibility without day-to-day thrashing, while also capturing the effects of each sprint's work on that longer-term planning to avoid big surprises farther into the project.
Again, that's all if it's done correctly, and if the situation even warrants using sprints in the first place. Which, every now and then all that's true, but I'd not say it's the norm. I don't think most orgs even think very hard about what the point of having sprints is, before imposing them.