The root problem in my estimation is that people want a boilerplate bureaucratic process which they can follow and achieve good enough™ results.
A lot of the activities done in agile or scrum or whatever processes are potentially useful tools in specific situations. But people don't want to understand the history and reasoning behind the tools nor do they want to apply them judiciously as appropriate.
They want a one size fits all process that produces results, if not optimally, at least consistently. And whatever Agile flavor of the month is popular is just that, it's good enough. And the benefit is that you get this fun mind trick to deflect blame ("I don't know what happened we followed the process. People don't fail processes do.") or ("I'll tell you what went wrong we didn't follow the xzy process. If we had just agiled a little harder this project would have shipped on time").
A lot of the activities done in agile or scrum or whatever processes are potentially useful tools in specific situations. But people don't want to understand the history and reasoning behind the tools nor do they want to apply them judiciously as appropriate.
They want a one size fits all process that produces results, if not optimally, at least consistently. And whatever Agile flavor of the month is popular is just that, it's good enough. And the benefit is that you get this fun mind trick to deflect blame ("I don't know what happened we followed the process. People don't fail processes do.") or ("I'll tell you what went wrong we didn't follow the xzy process. If we had just agiled a little harder this project would have shipped on time").