I've raised some criticisms of Scrum and Agile recently, and gotten a lot of feedback from Scrum advocates who disagree.
My main critique: Scrum's full of practices which very readily and rapidly decay into dysfunctional variants, making it the software development process equivalent of a house which falls apart while people are inside it.
Most Scrum advocates have not addressed this critique, but among those who have, the theme has been to recite a catchphrase: "Inspect And Adapt." The idea is it's incumbent upon any Scrum team to keep an eye out for Scrum decay, and prevent it.
Scrum can be described as a framework of feedback loops, allowing the team to constantly inspect and adapt so the product delivers maximum value.
From an Agile glossary site:
“Inspect and Adapt” is a slogan used by the Scrum community to capture the idea of discovering, over the course of a project, emergent software requirements and ways to improve the overall performance of the team. It neatly captures the both the concept of empirical knowledge acquisition and feedback-loop-driven learning.
My biggest critic in this Internet brouhaha has been Ron Jeffries. Here's a sampling of his retorts:
Mr. Jeffries is a Certified Scrum Trainer and teaches Certified Scrum Developer courses.
In a blog post, Mr. Jeffries acknowledged that I was right to criticize the Scrum term "velocity." He then added:
For my part in [promoting the term "velocity," and its use as a metric], I apologize. Meanwhile you’ll need to deal with the topic as best you can, because it’s not going away.
He reiterates this elsewhere:
Mr Bowkett objects to some of the words. As I said before, yes, well, so do I. This is another ship that has sailed.
The theme here is not "Inspect And Adapt." The theme is "you're right, but we're not going to do anything about it."
This isn't just Mr. Jeffries being bad at handling disagreement. It's also the case with Scrum generally. I'm not the first or only person to say that sprints should be called iterations, or that "backlog" is a senselessly negative name for a to-do list, or that measuring velocity nearly always goes wrong. Scrum also has a concept of iteration estimates which it calls "sprint commitments" for some insane reason, and this terrible naming leads to frequent misunderstandings and misimplementations.
These are really my lightest and most obvious criticisms of Scrum, but the important thing here is that people who love Scrum have been seeing these problems themselves over the twenty years of Scrum's existence, and nobody has fixed these problems yet. In each case, all they had to do was change a name. That's a whole lot of inspecting and adapting which has not happened. The lowest-hanging fruit that I can identify has never been picked.