Scrum is basically warmed-up Taylorism[1] for the 21st century, couched in buzzwords like "sprints" and "retros". It's an attempt to make software development an industrial process, stripping developers of autonomy and creativity in return for predictability. Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!"), because they like to be "data-driven".
The irony is that one could still have predictability and metrics without Scrum, and they would likely say as much if not more. Instead of expecting your devs to manually participate in rituals, you can use their actual output over a large time frame and extrapolate those.
Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating.
Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.)
I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
> The irony is that one could still have predictability and metrics without Scrum
I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites.
Honestly, while my cynical self would love this to be true, generating basic metrics (numbers of bugs solved, number of features added, average time a developer spends in meetings, etc.) doesn't require a lot of technical competence and already say far more than a vague metric like "velocity" (which, most of the time, is really just speed). Especially if the tool allows one to do this with a few clicks.
More likely is that, if teams were truly "self-managing", the number of management, management-lite and pseudo-management roles should be lowering drastically every year (or at least converting to hybrid roles). Yet I barely if ever see a Scrum adoption result in the majority of managers losing their jobs or changing the type of role they are performing. I also doubt data scientists would appreciate these middle-school tier statistics be called data science.
Why would you say that? There's nothing in the theory of scrum that makes a claim on the autonomy and creativity of developers. On the contrary, if you look in the scrum guide, you will find words like self-management, and independent, and cross-functional.
> Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!")
Story points do not figure anywhere in the theory of scrum. It is quite a different invention.
The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
> The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
I'm really struggling with this argument.
So if someone reads a text, picks from it things that he likes, throws away things he doesn't like, tries to apply the result in practice, but without success — how come he gets to blame the original concept rather than his own invention? Why call the method derived via picking, choosing and mixing with bits from other texts by the same name as the original text? What makes people think that they are "doing scrum" when they are not?
[1] https://en.wikipedia.org/wiki/Scientific_management