Scrum: A Framework for Agility Experts?
Many voices are criticizing Scrum without any real arguments, simply because it’s fashionable to dismiss the most popular agile framework as outdated. Some even pit Scrum against the no-estimate movement, which is absurd given that the word “estimate” does not appear in the Scrum Guide. Thus, Scrum has become the scapegoat of Agility.
For my part, a certain contrarian streak almost makes me want to defend the unloved child. But as time goes on, I must admit that I, too, am finding more and more reasons to distance myself from it.
Here are three of them, even if it means joining the chorus of critics.
1. It’s an overly academic framework
It tells you what to do, why to do it, but above all, how to do it: roles, ceremonies, artifacts—everything is laid out, right down to the duration of meetings. Meeting duration is important: up to 8 hours of sprint planning for a 1-month sprint (good luck with that).
So, Scrum takes you by the hand—by both hands, in fact—which may be reassuring for a first encounter with Agility but doesn’t really teach you how to think for yourself. How many project managers have we seen, sensing the tide turning, cramming for two or three days and hastily retraining as Scrum Masters, without understanding a thing about the fundamentals of Agility?
“The criticism is unfair,” you might say: Scrum isn’t responsible for how it’s used. Yes, except that Scrum invites these abuses by perhaps—just a little—treating people like idiots.
2. Scrum says nothing about functional design
The guide briefly mentions “refinement” without really giving it much attention. At most, it suggests doing it during sprint planning. Except that if you wait until Monday morning at the start of the sprint to work on your user stories, you can kiss your evening at the opera goodbye.
Thus, functional design is the hole in the racket—the great forgotten element, the unconsidered aspect of Scrum. Yet it represents a significant workload and often requires back-and-forth communication with stakeholders (users, domain experts, etc.). If you don’t plan for it, you’re in deep trouble on the first day of the sprint.
By the way, Example Mapping will certainly be useful for producing a high-quality design and helping the entire team build their expertise in the domain.
3. “Scrum is eXtreme Programming without the technical practices that make it work”
Another criticism that may be unfair, since Scrum does not claim to be exhaustive. The guide actually warns us about this: “[Scrum] functions well as a container for other techniques, methodologies, and practices.”
However, this Agile framework does not explicitly state which aspects it intends to address and which others it chooses to leave out. This is true of functional design as well as everything that enables frequent delivery (DevOps) while minimizing technical debt. These are, after all, somewhat essential aspects that aren’t even mentioned—not even to indicate that they’re outside the scope.
Thus, to the novice, everything suggests that Scrum is self-sufficient. This would imply that Scrum is, in fact, a tool for experts: a framework containing many well-founded ideas, but one that isn’t aimed at the right people.