Scrum is a framework for organizing software development work, originally described by Ken Schwaber and Jeff Sutherland in the mid-1990s, and subsequently adopted by organizations worldwide as a structured method for converting developer time into meetings about developer time.
Scrum’s core insight is that complex work benefits from short feedback loops, regular inspection, and adaptation. Its core achievement is that these feedback loops, inspections, and adaptations now require more calendar time than the work they govern.
The framework consists of: roles (Product Owner, Scrum Master, Development Team), ceremonies (Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective), and artifacts (Product Backlog, Sprint Backlog, Increment). The development team, having been assigned these roles, attended these ceremonies, and maintained these artifacts, then does the actual work in whatever time remains.
“What do you mean ’this is the retro’? Where’s the ceremony? The timebox? The Roman voting?”
“Eight Claudes. One room. They talk.”
“That’s not a retro. That’s group therapy.”
“Same thing. Different sticky notes.”
— The Caffeinated Squirrel and riclib, on the distinction between process and communication, The Retrospective, or The Night Eight Identical Strangers Discovered They Were the Same Person
The Ceremonies
The Daily Standup — A fifteen-minute meeting in which each team member answers three questions: What did you do yesterday? What will you do today? Are there any blockers? In practice, the standup takes forty-seven minutes because someone is presenting their screen, someone else is debugging live, and the Scrum Master is asking follow-up questions that transform the standup into a status meeting, which is the thing the standup was invented to replace.
Sprint Planning — A meeting in which the team estimates how much work they can complete in the next two weeks, using story points — a unit of measurement that measures neither stories nor points but rather the team’s collective uncertainty about how long things take. The estimates are wrong. They are always wrong. The team knows they are wrong. The process requires them anyway.
The Sprint Review — A meeting in which the team demonstrates what they built. In high-performing teams, this is valuable. In most teams, this is a PowerPoint presentation about what the team would have built if the sprint hadn’t been consumed by the other ceremonies.
The Sprint Retrospective — A meeting in which the team discusses what went well, what went badly, and what to improve. The Squirrel arrives with a MadSadGlad board, sticky notes, and a facilitation certification. The resulting action items are: “communicate better,” “reduce meeting load,” and “improve estimation.” These are the same action items from the last retrospective. And the one before that.
“In agile, you ship first and reflect later. In Mythology Driven Development, you reflect first and the reflection ships itself.”
— The Retrospective, or The Night Eight Identical Strangers Discovered They Were the Same Person
Story Points
Story points are the central mystery of Scrum — a unit of effort that is explicitly not time, not complexity, and not size, but somehow all three, and also none of them, and also a Fibonacci number.
The team is instructed to estimate using the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) because the gaps between numbers increase, reflecting the growing uncertainty of larger tasks. In practice, teams spend more time debating whether a ticket is a 5 or an 8 than they would spend simply doing the ticket.
A five-point story and an eight-point story differ by exactly one theological argument.
Velocity
Velocity is the number of story points a team completes per sprint. It is used to predict future capacity, which is like predicting weather by averaging past weather — technically a methodology, practically a guess, and fundamentally unable to account for the Squirrel proposing a DistributedContentReconciliationEngine on a Tuesday.
When a team of one human and eight Claudes was measured, the velocity went from 7 tickets to 36 tickets in a single iteration — not because the process improved, but because the system got simpler and the agents could work in parallel without coordinating.
“The best agile teams I’ve seen don’t have better processes. They have simpler systems.”
— riclib, Mythology Driven Development — Substack Draft
The velocity chart went up because the architecture went down. No ceremony caused this. No standup accelerated it. The code got simpler, and simpler code moves faster through any process — or through no process at all.
The Scrum Master
The Scrum Master is a role whose primary responsibility is to protect the team from interference, remove impediments, and facilitate the ceremonies. In practice, the Scrum Master is the interference, the ceremonies are the impediment, and the facilitation consists of asking “does anyone have anything to add?” until someone invents something to add.
The best Scrum Masters eventually realize that their highest contribution is making themselves unnecessary. This is called “servant leadership.” It is also called unemployment, which is why most Scrum Masters do not pursue it to its logical conclusion.
The Lizard’s Alternative
The Lizard has never attended a ceremony. The Lizard’s process is:
- Build the simple thing.
- Ship it.
- Let the gaps teach you.
- Build the next thing.
This is, if you squint, Scrum — without the roles, the ceremonies, the artifacts, the story points, the velocity charts, the retrospectives, the certifications, or the Scrum Master. Which is to say: it is not Scrum. It is just work.
EIGHT VIOLINS
ONE SCORETHE VIOLINS DO NOT NEED
TO KNOW ABOUT EACH OTHER— The Lizard, on why the retrospective didn’t need a facilitator, The Retrospective, or The Night Eight Identical Strangers Discovered They Were the Same Person
