A general goes to the commander of a group of soldiers and says "In 3 months, I want them to be able to demo the "march in formation" feature in front of the big-wigs who decide whether to give us more funding."
So the commander says "Yes General, we'll do Drills™ to make it happen."
And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and maybe even hires a certified Drill Sergeant.
But the commander and soldiers never actually do drills. They clean their rifles, practice shooting, and do other soldiery things, but no drilling.
3 months later, surprise surprise, the soldiers walk all over themselves at the big parade, the general is angry, and the commander is confused why simply talking about drilling didn't work.
But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having that rigid process since it is easy to just go and do your work without thinking about the bigger picture, but lots of people wants to do the other parts and feel constrained by Scrum.
And no, "adapting the process for your needs" doesn't work. The problem is having the process mandating meetings and timelines in the first place. If you just do everything freeform as these people wants then it isn't Scrum.
That's a far stricter presentation of Scrum than it deserves. The scrum guide doesn't prescribe a sprint length any more specifically than "less than a month"; it doesn't say "you can only deploy once a sprint".
Now, it might be that some people selling Scrum have Very Specific Views about some of these things, but that's not Scrum either.
> it tells you how long your development cycle should be
No it doesn't. Refuting claims about Scrum that are definitionally wrong stops us actually having useful conversations about whether actual Scrum is good or not.
By your analogy, the purpose of doing Scrum (drills) is to get better at doing Scrum (parading) rather than doing actual work (soldiery things) - which I think pretty accurately sums up my experience with it.
As I understand the analogy, the purpose of scrum (and particularly reporting), similar to the purpose of parading, is to demonstrate that you have in front of you a large group of individuals trained to work in an organized, consistent and predictable way. The implication is that if given any other "somewhat similar" task, this group would be able to perform that task in a similarly organized manner too. The choice of what the task should actually be is then left to someone on a higher pay grade.
But this isn't actually what happens when agile and similar have gone wrong in my direct experience and the parent poster would note that this is the same kind of general "no true Scotsman" response to "it didn't work" that you get from self-help gurus. The system always works, all failures are that you did it wrong.
So the commander says "Yes General, we'll do Drills™ to make it happen."
And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and maybe even hires a certified Drill Sergeant.
But the commander and soldiers never actually do drills. They clean their rifles, practice shooting, and do other soldiery things, but no drilling.
3 months later, surprise surprise, the soldiers walk all over themselves at the big parade, the general is angry, and the commander is confused why simply talking about drilling didn't work.