Scrum Won a War and Then Became an Occupation

Somewhere in a drawer, I have a certificate that says I am a Professional Scrum Master.

I earned it properly — studied the Scrum Guide, sat the assessment, passed. PSM I. I was, on paper, the kind of person the framework wants embedded in every team: trained, certified, fluent in the liturgy. And here is the complete list of employers, managers, and colleagues who, across all the years since, have ever asked about that certificate, referred to it, or cared in any detectable way that I held it:

Nobody. Not once. Not in an interview, not in a planning meeting, not in the middle of a sprint going wrong — which would have been the moment, you’d think, to consult the certified man. The industry that made the certificate a hiring keyword had no use for its contents. I’d memorized the rules of a game everyone claimed to be playing and nobody was actually playing — which was my first clue, though it took me years to read it, that the game itself might be the problem.

So let me establish my standing before I begin, because this is a trial and the defense will reasonably ask who I am. I am not an outsider sniping at agile from a waterfall bunker. I’m certified. I have run the ceremonies and sat through them, for years, on teams large and small, sincere and cynical. I’ve been the one moving the cards, the one assigning the points, the one saying “let’s take that offline, we’re past the timebox.” I believed, then I doubted, then I watched — and what I watched, on team after team, was a method that consumed real hours, produced theater, and got quietly suspended the moment anything serious happened. What follows is the prosecution’s opening statement.

And because my book has rules, so does this essay: the prosecution carries the honest counterargument, at full strength. Scrum’s defenders get a better defense in these pages than my objections ever got in a retro. Let’s begin with what the defendant actually is.

---

What Scrum is, fairly#

Strip the industry around it away, and Scrum is a small, almost elegant thing. The Scrum Guide is around thirteen pages. It says, roughly:

Work in fixed-length iterations: sprints, typically two weeks. Before each, hold sprint planning: the team selects what it will commit to and forecasts the effort, commonly by estimating items in story points. Every day, a fifteen-minute daily scrum to synchronize. At sprint’s end, a review to demo the increment to stakeholders, and a retrospective to improve the process. Three roles: the product owner, who owns what gets built and orders the backlog; the developers, who own how; and the scrum master, who owns the process itself and clears impediments. The whole thing aims at a rhythm: commit, build, show, learn, repeat — short cycles, empirical control, inspect and adapt.

Described like that, you can see why it conquered the world. It’s teachable in a day. It’s installable in any company. It produces visible artifacts (boards, burndowns, velocity charts) that management can watch. And it was sold against a genuinely terrible incumbent: the multi-year waterfall death march, the spec frozen in 2003 for software shipping in 2006. Against that, Scrum was liberation, and the people who remember the before-times are not wrong to be grateful.

My argument is not that Scrum is worse than waterfall. My argument is that Scrum won a war and then became an occupation, and that what it occupies, on the average team, is the thing my book defends from its first page: hours of human attention, the only resource software is actually made of.

---

How a generic framework got welded to software#

To understand how a thirteen-page guide became a planetary bureaucracy, you have to start with a document that’s even shorter: the Agile Manifesto. Four value statements, twelve principles, one page. Individuals and interactions over processes and tools. Working software over comprehensive documentation. Responding to change over following a plan. I agree with every word — my book is, in a sense, a long agreement with that page.

But notice what the manifesto is not: it is not operational. Agile, taken literally, is too vague to run on. It tells you what to value, never what to do on Monday. “Individuals and interactions over processes and tools” does not tell you how to plan a quarter, when to ship, or what to say to a CFO who wants a date. The manifesto created a vacuum where a method should be: a values statement in search of an operating system.

Vacuums get filled by whatever is most packageable, and Scrum was magnificently packageable: named roles you could hire for, named events you could schedule, named artifacts you could inspect, a certification industry ready to print credentials (I own one), and consultancies ready to install it anywhere — because, and this is the crucial property, Scrum is generic. Nothing in those thirteen pages is about software. It mentions no code, no tests, no deployment, no architecture. It’s a general-purpose framework for iterating on work under uncertainty — which sounds like flexibility and functions as a void. All the hard parts of running a software team (the pipeline, the dependency discipline, the decision system) are outside Scrum’s scope, delegated to a footnote, assumed to exist. The industry adopted a process that organizes the meetings about the work and says nothing about the work, then certified hundreds of thousands of people in the meetings.

That’s the weld. Software needed an operating system and bought a calendar.

---

Everybody knows Scrum, nobody knows it#

There’s a quiet consequence of all that certifying, and it may be the most corrosive thing about the whole arrangement: everybody knows Scrum, and nobody knows Scrum.

Everybody knows it in the sense that the vocabulary is universal: every developer can run a standup, hold up a planning poker card, facilitate a retro, recite the roles. It’s the lingua franca; it’s on every CV. And because everyone “knows” it, nobody examines it. It has the status of grammar: invisible, assumed, beneath discussion. You don’t debate whether to have a sprint any more than you debate whether to have Tuesdays.

But scratch the shared fluency and it dissolves into dialects. To one person Scrum means strict adherence to the Guide; to another it’s whatever their last company did; to a third it’s just “agile,” a vibe; to a fourth it’s the specific Jira configuration they inherited. Put five of these people on adjacent teams and they will use the same words to mean different practices and never discover the difference until, under pressure, the difference breaks something. The universal vocabulary creates an illusion of shared method that is, if anything, more dangerous than open disagreement, because open disagreement at least knows it needs resolving. “Everyone knows Scrum” is how a building full of people running five incompatible processes can each believe they’re all running the same one. The certificate in my drawer certifies fluency in the vocabulary and calls it competence in the work. The thing that actually matters, shared understanding across real humans under real pressure, was never on the exam, because it can’t be.

---

The cost accounting#

Now the prosecution’s first exhibit: the hours. Let me do the arithmetic the framework never does, for an ordinary team of seven on two-week sprints, with ordinary ceremony lengths — not the pathological versions, the normal ones.

Sprint planning: two to four hours, everyone. The daily scrum: fifteen minutes, ten times a sprint — call it 2.5 hours per person, and that’s the disciplined team that actually stops at fifteen. Backlog refinement, the scoring meetings: an hour or two, everyone, most weeks. Review, an hour; retrospective, an hour to ninety minutes. Total it honestly and an ordinary team spends eight to twelve hours per person per sprint inside the liturgy — ten to fifteen percent of all working time, before a line of code, before anyone’s actual collaboration, forever. For the seven-person team, that’s roughly three to four full person-weeks per month of the scarcest thing the team has. The introduction of my book promises a scene: precious hours dying so that a number can be assigned to a task nobody fully understands. That scene runs on a loop, in every Scrum shop on Earth, and everyone calls it progress.

Now — hours spent are not hours wasted if they buy something. There is only one test that matters: a ritual earns tenure by output. So put each ceremony on the scale. And here the pattern I watched, across teams and years, is damning in a specific way: the ceremonies' outputs are almost always available cheaper elsewhere. The standup’s synchronization: ambient, free, in a team with an up-to-date board and real bandwidth between the people — the meeting re-announces what the room already knows, at the price of fifteen minutes of held attention. The review’s feedback: continuous, in a team that ships every afternoon and talks to its users. The retro’s improvement: ask the sticky note that attended thirty retrospectives and changed nothing. What remains, irreducibly Scrum’s own, are the two I haven’t weighed yet — the estimates and the timebox. They get their own sections, because they’re not merely costly. They’re costly and structural, and what they hold up is mostly fiction.

---

The estimate problem#

The scoring meeting deserves slow motion, because nothing in modern software is stranger when you actually watch it.

Seven intelligent adults sit in a room. A ticket appears on the screen: a feature in a part of the system half of them have never touched, depending on an API none of them has called, for a stakeholder need that’s one sentence long. They are asked to assign it a number. Cards are held up. The numbers disagree (of course they disagree; the disagreement is the only honest data in the room), so there’s a discussion, which mostly surfaces how little is known, and then a second vote converges, because meetings end by converging, and the ticket is now a 5. Everyone experiences this as work. Something has been measured, surely.

Nothing has been measured. An estimate of a task nobody understands is not a measurement of the task — it’s a measurement of the room’s mood. The genuinely unknown parts (the ones that will actually determine the duration: the surprise in the legacy module, the API that lies, the requirement that changes on contact with reality) are the parts no one can see from a planning room. You can’t fully trust experience even about code you know; my book calls that code blindness. Story-pointing extends the same false confidence to code you’ve never met.

The most common sentence in any refinement is we need more information on this ticket, and the information never comes, because the perfectly written user story is a unicorn — the person who could write it would have to know the thing the ticket exists to find out. If the points stayed inside the team (a rough conversation-starter, a flag that says “we disagree about this one, investigate“), the cost would just be the hours. But points never stay inside the team. They get summed into velocity; velocity gets charted; the chart travels upward, where it undergoes the most reliable transformation in corporate physics: the estimate becomes a commitment. Now the team owes the fiction. Now sprint-end is a deadline against numbers invented in a mood, and someone is asking why the burndown bends. The team responds rationally: pads the next estimates, games the points, splits tickets to farm velocity, and the metric, like every metric under pressure, stops measuring the work and starts measuring the team’s skill at protecting itself from the metric. Hours were burned to manufacture a number; the number was then used against the people who manufactured it. That’s the scoring meeting, audited.

---

The timebox problem#

And then there’s the sprint itself: the load-bearing wall of the whole framework.

Think about what a sprint is, mechanically: a fixed batch. Two weeks of work, selected up front, committed as a unit, evaluated as a unit. Now recall the one law that never reverses: everything good in modern software comes from making batches smaller — and at the limit, the batch is one change, flowing the moment it’s ready. The sprint is a batch boundary reimposed from above on work that no longer needs one. A dam built across a river we spent decades teaching to flow.

You can see the dam’s effects at both ends of every sprint. At the end: the crunch — the unnatural end-of-sprint push to drag tickets across the line before the review, the corners cut to satisfy a boundary that exists only on the calendar. At the start: the drift — the slack Monday, the re-planning, the picking-up of context dropped at the boundary. And in the middle, the subtler tax: the commitment wall. Something genuinely important arrives mid-sprint (a customer discovery, a market change, the “responding to change” the manifesto enshrined), and the framework’s structures push back: don’t break the sprint; put it in the backlog; we’ll score it at the next refinement. The method built to honor change ends up defending a two-week plan against it. Meanwhile the work that was committed gets finished — and then waits, sometimes days, for the boundary, because the sprint trained everyone that the sprint is the unit of done. Cost of delay, self-inflicted, on a schedule.

A team with the machinery (a pipeline, every change releasable) doesn’t need the dam. The river already flows in smaller units than the sprint can see. Which leaves the dam doing the only job it still has: providing a stage for the ceremonies — a boundary so there can be a planning, a boundary so there can be a review. The batch exists to justify the meetings about the batch.

---