Scrum’s Fine Print
Side Effects May Include…
Every medicine comes with a little folded paper inside the box. You know which one? The one almost nobody unfolds (and reads!). We know what it stands for: it lists what the drug is actually for, who should not take it, and what happens if you take too much and so on. Most of us tear the box open, swallow the pill, and trust that it will help. The paper goes straight into the bin.
Another time, I was supporting a team that was told to work in sprints. (A sprint, for anyone standing outside the agile world, is a fixed timebox, usually one to four weeks, in which a team takes on a focused slice of work and finishes it.) Sounds reasonable. Except this team supports twenty-eight products. They do not own a single one of them. They are a support team, the people who keep other teams' things running. And they were handed Scrum anyway.
They have been saying this does not fit for years. The company's answer is reasonable on its face:
"We need one consistent structure. We need predictable delivery. We need to see who is working on what."
Those are valid needs! Any leadership group would want them, of course! The problem was never the wish. The problem is the prescription.
Scrum comes with that folded piece of paper, too. The difference is that its fine print never made it to the printer.
The Headache
Here is what the Scrum Guide actually asks for, even though it never calls them conditions:
It describes a Scrum Team as "a cohesive unit of professionals focused on one objective at a time, the Product Goal."One objective. One Product Goal, which is the single direction everything in the work points toward. It says the team is "cross-functional, meaning the members have all the skills necessary to create value each Sprint."All the skills, inside the team. It puts the size at "typically 10 or fewer people." And it calls the Product Backlog, the ordered list of everything the team will work on, "the single source of work undertaken by the Scrum Team."
Let me point it out again: Single. One list, one product, one direction, one small team that can build the whole thing.
Now hold the support team against that label. Twenty-eight products means there is no single objective and no single Product Backlog, there are twenty-eight of them. The skills to build and run twenty-eight different things do not live inside ten people, you would need a team of thirty before you even started. And ownership, the room to actually decide and shape a product, was never theirs to begin with. They fail at the first line. Not by a little.
The Guide is even honest about what happens next, in a sentence most people skim past: "Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless." And later, plainly: "While implementing only parts of Scrum is possible, the result is not Scrum."
We could consider this the fine print. I mean, it is right there. It just does not read like a warning label, so it rarely gets treated as one.
And here is the part that stings. The company wanted one structure and predictable delivery. By stamping the same Scrum shell onto every team without the conditions underneath it, they did not get scaled Scrum, the kind designed to coordinate many teams around one product, and they did not get anything you could honestly call an agile framework either. They got dozens of isolated little "scrum" frameworks running next to each other, each calling itself a "Scrum team." The side effects showed up fast: a monster of dependencies, blame games, and silos.
The cure, given for the wrong illness, produced the very disease it was supposed to prevent.
Visiting a Doctor's Office
So why does the wrong prescription keep getting written? Part of the answer sits in a quiet role confusion.
A Scrum Master is there to establish Scrum and make it run well, to tend it, to optimize inside it. The job is to get the framework working, not to ask whether the framework belongs here at all. An Agile Coach is supposed to do the opposite thing: diagnose the system. Ask whether this is even the right treatment. Recommend something better. Or do the hard work of reshaping the system until Scrum genuinely fits.
Most of the time, both of those live in the same person. And when they do, the role that installs tends to quietly swallow the role that questions. You cannot wholeheartedly set something up and seriously doubt it in the same breath. The administering hand wins, because administering is the part with a clear task and a tidy checklist.
I would never put myself on the level of an actual doctor, that is a different league entirely. But strip the comparison down to the system, and the role behaves the same way. A patient walks out of the office and never fills the prescription. Coaches know that feeling intimately, the right call made and quietly ignored. And the person giving the advice is not all-knowing either. They are human, they have blind spots, and over enough time they become part of the very institution they were brought in to see clearly. The in-house doctor who has been in the building long enough starts seeing the building the way the building sees itself.
Numbing It Down
Underneath all of it sits one comforting belief: Scrum can't really hurt, right? Worst case, it does nothing. Like swallowing too much vitamin C, the surplus just gets flushed away.
Well, unfortunately, there are two problems with that.
The first is that the wrong medicine for the wrong illness is not neutral. It delays the real diagnosis. It produces side effects, the cynicism, the ceremony fatigue, the dashboards full of numbers few people trust. And it occupies the chair where the right treatment should be sitting. Doing nothing would at least leave the chair empty.
The second is that even the vitamin C story is a myth. The surplus is not simply flushed without consequence. Mega-doses can cause real trouble, kidney stones, stomach problems. Even the excuse we reach for to say "it can't hurt" turns out to be wrong.
There is even a worse version of this, though: the doctor who stopped reading about new discoveries in medicine. Medicine moves. If a physician stops following what comes after the page they trained on, they keep prescribing yesterday's cure with full, sincere confidence. In the 1880s that confidence sold cocaine. In 1885 a pharmacy in Albany sold Cocaine Toothache Drops, fifteen cents a bottle, advertised as an "Instantaneous Cure!" with a cheerful picture of children at play. The National Library of Medicine keeps these in an exhibition called, fittingly, "Pick Your Poison." In 1898 Bayer sold heroin as a non-addictive cough syrup, for adults and children. Freud had published a paper praising cocaine in 1884, before the cost of it was understood.
None of those people were monsters. That was the state of the art. They were simply not yet on the next page. And then scale it up. Prescribe the wrong thing to one patient, and you harm one patient. Prescribe it to a whole population, and you do not just fail to cure. You create dependency. A nation hooked. An industry hooked on ceremonies, velocity counts, the velocity being the amount of work a team gets through in a sprint, and a sprint cadence that never once treated the thing it was brought in to treat.
There is a word for a medicine that cures everything: a panacea. It comes from Panakeia, a Greek goddess. (Which already tells you something.) In real medicine the cure-all is a myth, and the moment a remedy is sold as treating every condition, it stops being medicine and becomes snake oil. Scrum is not snake oil. It is a genuine cure for a genuine illness. But prescribed as a cure-all, purely by the way it gets used, a real medicine starts to behave like one.
The Diagnosis
Scrum is not the disease. It was never the disease. Drop it into the illness it was built for, a single team, a single product, the skills to build it sitting inside the room, the space to actually own the thing, and it works. That team exists. I have watched Scrum heal things for a team like that.
So the question was never "is Scrum good or bad." The question is the one that keeps getting skipped: do you have the illness it cures?
Asking that is the whole job. Diagnosing before prescribing, and staying current enough to know when the field has moved on, is the entire difference between handing out a remedy and actually coaching.
For my twenty-eight-product team, the honest prescription was never Scrum. It might be flow-based work, where the team simply pulls the next most important thing instead of forcing it into a fixed box (the core idea behind Kanban). It might be a real restructure. It might be something that does not come with a certificate attached. All of that is harder, and it threatens the tidy picture of one structure for everyone. Which is exactly why the unprinted label tends to stay unread.
Opening the box and swallowing the pill is the easy part. The diagnosis underneath is the part that gets skipped. So before the next framework gets rolled out across every team in the building, it is worth unfolding the little paper first and asking one quiet question:
What illness are we actually trying to treat here?
Feeling Sick? Let's adjust your medication. Book a free consultation call: