If you're doing Scrum, then you might have noticed that the Scrum Guide considers the contents of a sprint to be a "commitment" on the part of the team. That "commitment" is usually built by taking the number of story points delivered last sprint, and bin-packing the same number of story points from the backlog into the next sprint.
If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.
> If you don't think toxic managers and scrum masters
If your managers and PM's are toxic you've already lost and no process is going to fix it. The only move is to change your team in that case. If everywhere you look you only see toxic managers though, maybe you're the problem.
The non-technical managers and agile coaches are the problem. That's why the best software projects don't have them. Linux kernel developers don't run story ticket velocity poker sprints.
An obsession with technical knowledge being superior to everything else is one of the most grating things about this community.
> The non-technical managers and agile coaches are the problem.
No, shitty managers are. In fact, most of the utterly useless managers and leaders I've had have been technical who just assumed that management, soft skills and leadership are "easy".
> That's why the best software projects don't have them.
There's no one definition of "best" software projects. And something being good software doesn't mean it serves a products needs.
> Linux kernel developers don't run story ticket velocity poker sprints.
The Linux kernel works because the project management knows their audience. The project is managed differently and ran differently. If I drop into an email thread talking about a large feature and say "I think that will take 2 days" people will disagree with that. That's all planning poker really is - once you've decided to do something, have a gut check on how much work it is.
Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?
Sometimes Scrum does get called "lots of very short waterfalls". It's not entirely wrong, in the current incarnation. [On edit, I see you've made this point below. Yes.]
Note that until relatively recently (2020, I think), the Scrum Guide referred not to "commitments" but to "forecasts". That was a much better framing, and I don't know why they changed it.
That's exactly waterfall - make a plan up front, commit to it and focus exclusively on delivery.
Scrum does that because it considers waterfall on a 2 week cycle to be training wheels for people who have been doing it on 6 month increments and because it considers that "closer" to agile.
If you don't think toxic managers and scrum masters are going to use that "commitment" to death-march the team if it looks like the sprint goal is going to be missed then you have a far more optimistic view of humanity than I do.