The Invoice ■ Episode 10
“We do Scrum.”
Three words that tell you everything about how an organisation spends its engineering budget and nothing about how it builds software. Scrum is the methodology that replaced “individuals and interactions over processes and tools” with a process, administered through a tool, by a person whose two-day certification has a 98 per cent pass rate.
Let us examine the invoice.
The Ceremony Budget
A standard Scrum team: six developers, a two-week sprint, 80 working hours per person. The ceremonies prescribed by the Scrum Guide are not optional. They are mandatory. Here is where the hours go:
Eighteen hours. Twenty-two per cent of every sprint, per developer, spent not writing software but discussing the writing of software. For a team of six, that is 108 developer-hours per sprint, approximately $154,000 per year in meeting costs alone, assuming a rather modest billing rate.
According to Atlassian’s own research, 72 per cent of meetings are considered ineffective by attendees. The industry’s response to this finding? Seventy-four per cent of organisations schedule more meetings. One admires the consistency, if not the logic.
The $126,000 Role
Every Scrum team requires a Scrum Master. The average salary is $126,000 per year in the United States. The qualification for this role is a two-day course (sixteen hours of classroom time) followed by an examination with a 98 per cent pass rate. There are no technical prerequisites. You need not have written a line of code, deployed a service, or debugged a production incident. You need a laptop, a credit card, and a weekend.
For context: a Certified Kubernetes Administrator exam requires hands-on practical demonstration and has a pass rate under 50 per cent. A Scrum Master certification requires you to be awake for two days.
The role exists to facilitate the ceremonies. Remove the ceremonies, and you remove the role. This is not a flaw in the argument. It is the argument. You are paying $126,000 per year for someone to administer the overhead that would not exist without the methodology that created the role.
The Spillover Problem
Twenty-two per cent of your sprint is ceremonies. But the true cost is worse, because Scrum introduces a secondary tax that rarely appears on the invoice: sprint spillover.
Work that does not fit neatly into a two-week box gets sliced, deferred, or carried over. Industry data suggests this extends actual delivery time by approximately 30 per cent. A feature that would take three weeks of uninterrupted work takes two sprints (four weeks) because the arbitrary boundary forces context switches, re-estimation, and re-prioritisation.
Then there are “hardening sprints”: entire iterations dedicated to fixing what the previous iterations broke. This is paying twice: once to build it under artificial time pressure, and once to repair the damage caused by that pressure. In any other industry, this would be called rework. In Scrum, it is called a process.
What Was Lost
Scrum did not emerge from nothing. It was extracted from Extreme Programming, which had rather more to say about software development than how to organise meetings. XP prescribed pair programming, test-driven development, continuous integration, and relentless refactoring. These were engineering practices that directly improve code quality.
Scrum kept the meetings. It dropped the engineering.
Martin Fowler identified this as early as 2009, coining the term “Flaccid Scrum”: teams that adopted the ceremonies without the technical practices, producing precisely the limp results one might expect from a methodology that mandates how you talk about code but says nothing about how you write it.
The left column is process. The right column is practice. Scrum is a methodology that optimised for the half that does not produce software.
The Creators Speak
One might dismiss this as the grievance of someone who simply dislikes meetings. But the people who built these methodologies are saying the same thing, and their words are rather more difficult to wave away.
Ken Schwaber, co-creator of Scrum, 2011: “75 per cent of organisations using Scrum will not succeed in getting the benefits.” The man who invented the framework telling you the framework mostly does not work. One expects this level of candour from a doctor, not from the person selling the prescription.
Ron Jeffries, co-creator of Extreme Programming, 2018: “It breaks my heart to see these ideas used to make developers’ lives worse.” He titled the article “Developers Should Abandon Agile.” Not a reformist position.
Dave Thomas, co-author of The Pragmatic Programmer and signatory of the Agile Manifesto, 2014: “The word agile has been subverted to the point where it is effectively meaningless.”
Martin Fowler, 2018: “The Agile Industrial Complex imposing methods on people is a travesty.”
Four architects. Four independent conclusions. The same diagnosis: captured, corrupted, commercialised.
The Certification Economy
Who benefits from Scrum remaining complicated enough to require professional guidance? Follow the money.
The Scrum Alliance, a registered nonprofit, reported $20.7 million in revenue. Its chief executive earned $856,000, rather generous compensation for an organisation that exists to certify people in a methodology whose creator says it mostly does not work. Scrum.org generates approximately $76 million. The broader enterprise agile market, according to Allied Market Research, is valued at $27.6 billion.
Twenty-seven point six billion dollars. Built on a manifesto that fits on a single page and explicitly warned against precisely this outcome. The manifesto said “individuals over processes.” The industry heard “processes, with individuals to sell them.”
The Alternative
The question is not whether Scrum should be reformed. The question is whether you need it at all.
Kanban: pull-based, no sprints, no ceremonies, no artificial time boxes. Work flows when capacity exists. No standup required to determine what is obvious from the board.
Shape Up: six-week cycles, no daily standups, no estimation theatre, no story points. Basecamp built it, uses it, and ships software with a team that would make most Scrum organisations weep with envy.
Competent adults with clear ownership: the option that requires no framework, no certification, and no $126,000 facilitator. Give someone a problem. Let them solve it. Check in when they ask for help or when they ship. This approach has a name in most other professions: working.
The Verdict
The Scrum tax is not a single line item. It is the compound of ceremonies that consume 22 per cent of your sprint, a facilitator who costs $126,000 and requires no engineering background, sprint spillover that extends delivery by 30 per cent, hardening sprints that pay for the same work twice, and a certification economy that generates $27.6 billion from the proposition that software teams cannot be trusted to organise themselves.
The co-creator says 75 per cent will fail. The people who inspired it are begging you to stop. The creators of the manifesto it claims to implement are calling it a travesty. And yet the industry renews the subscription, sprint after sprint, because questioning the methodology would require a retrospective, and the retrospective is already booked.
The manifesto asked for fewer processes. Scrum responded with five mandatory ceremonies, a dedicated role to administer them, and a $27.6 billion industry to certify the administrators.
The engineering practices that actually improve software (pair programming, TDD, continuous integration, refactoring) require no ceremonies, no certifications, and no facilitator. They require only competence, discipline, and the organisational courage to trust your developers.
The Scrum Guide is 13 pages. The manifesto it claims to serve is 73 words. Somewhere between those two documents, the purpose was lost and the invoice was born.