Curling: The Framework That Replaces Scrum

There are exactly four people on a curling team. They rarely speak during a throw. There is no standup. There is no sprint planning. There is no retrospective. And they coordinate more effectively than any fourteen-person Scrum team I've ever seen.

I argued in Scrum Is Dead that the framework designed to kill bureaucracy became bureaucracy. But tearing something down is easy. The harder question is: what do we replace it with?

The best team I ever worked on had four people. We didn't know we were practicing Curling. We just knew that when someone was building, everyone else's job was to clear the path. PRs got reviewed in minutes. Questions got answered before they became blockers. We shipped more in three months than the previous team of twelve had shipped in a year. I've been trying to figure out why ever since.

I think the answer is on the ice.

Why Curling?

If you've ever watched Olympic curling, you know the silence is the first thing that hits you. One person crouches, stone in hand, reading the ice. Two teammates crouch ahead with brooms, watching the stone's trajectory in real time, ready to sweep. A fourth stands at the far end of the sheet and calls the strategy.

Here's the detail that makes curling unique among team sports: the thrower releases the stone and then cannot touch it again. This is the Release Point. Once the stone leaves the thrower's hand, only the sweepers can influence the outcome. They read the curl, judge the weight, and sweep friction off the ice to adjust speed and direction.

Sound familiar? It should. In software, once work is in motion, the job shifts from creation to clearing the path. The best teams already know this instinctively. They just don't have a name for it.

Curling originated in 16th-century Scotland. Teams of four have been coordinating on ice without managers, without standup ceremonies, without certification programs, for 500 years. Maybe that should tell us something about how many people you actually need to get things done.

But beneath the simplicity is extraordinary depth:

The Skip (strategist) reads the entire playing field and calls the shots, not by doing the work, but by seeing the big picture.
The Sweepers remove friction from the path, adjusting in real time based on how the stone is moving.
The Thrower executes with precision, releasing at exactly the right moment with exactly the right weight.

This is how the best software teams already work. Curling is just the name for it.

The Curling Principles

1. The Stone Is the Work

A user story at a typical enterprise touches five ceremonies before a single line of code is written. It's created in backlog refinement. Estimated in sprint planning. Pulled into the sprint. Carried over when incomplete. Re-estimated in the next sprint.

In Curling, the unit of work is a Stone: a single, well-defined deliverable that moves from conception to delivery. A Stone touches one ceremony: the moment someone picks it up and commits to the delivery.

You don't half-throw a curling stone. You commit.

The research supports this. Gerald Weinberg's work on context switching showed that working on two projects simultaneously reduces productive time to 40% per project, with 20% lost to switching. Three projects? 20% per project. 40% lost entirely. The sprint model, with its constant re-prioritization and carry-over, maximizes switching. The Stone model minimizes it.

There's a manufacturing parallel here. Taiichi Ohno, the architect of the Toyota Production System, demonstrated that single-piece flow, processing items one at a time through a system, is faster than batching, even though batching feels more efficient. Sprints are batches. You load up a two-week container with stories, process them in parallel, and deal with the carry-over. Stones are single-piece flow. One piece of work. All the way through. Done.

2. Sweep, Don't Stand Up

Here's what Sweeping looks like at 2 PM on a Tuesday. A developer pushes a PR. The tech lead sees it in Slack, reviews it within the hour, leaves two comments. The developer addresses them by 3:30. The feature is in staging by 4. Total elapsed time: two hours.

Under Scrum, that PR would have been mentioned at tomorrow's standup, reviewed sometime during the sprint, and merged three days later. Same work. Three days instead of two hours. The difference isn't effort. It's friction.

Sweeping is the active removal of obstacles from the path of work in progress. It's proactive, not performative. You don't wait for someone to report a blocker in a ceremony. You watch the Stone's trajectory and clear the ice before friction slows it down.

Google's engineering practices documentation recommends reviewing code within one business day. Their internal data shows that review latency is the single largest contributor to development cycle time. Sweeping is the formalization of this insight: make code review, question-answering, and obstacle removal continuous rather than periodic.

This means:

Reviewing pull requests within hours, not days
Answering questions asynchronously when they arise
Removing bureaucratic hurdles before they become blockers
Deploying infrastructure changes ahead of the features that need them

There's a cross-disciplinary parallel that makes this vivid. The flight deck of a USS Nimitz-class aircraft carrier has the highest personnel density of any workplace in the world. Dozens of aircraft, hundreds of crew, jet fuel, live ordnance, and a 300-foot landing strip. There are no standups. There are no sprint retrospectives. Each crew member watches the space around them and proactively clears hazards. The deck runs on continuous sweeping, not periodic status reports. Because when you're operating at that tempo, waiting until tomorrow's ceremony to report a blocker means someone dies.

Your codebase is less dramatic. But the principle is the same.

3. The Skip Sees, Doesn't Steer

The German military has a concept called Schwerpunkt: the focal point of effort. The single most important objective that all activity should orient toward. The commander's job isn't to direct every action. It's to identify the Schwerpunkt and point.

The Skip (team lead, tech lead, or product lead) has one job: maintain strategic awareness. They see the whole house (the target), know the score, and call the next play. They identify the Schwerpunkt: where should the team's energy concentrate right now?

But they don't micromanage the throw. They don't tell the sweepers exactly how hard to sweep. They trust the team's expertise and adjust strategy based on outcomes, not activities.

Basecamp's "Shape Up" methodology works this way. Senior people define the appetite and boundaries of a project (shaping), then hand it to a small team that has full autonomy over implementation. The shaper is the Skip. They read the ice. They don't steer the stone.

"But doesn't this just mean the Skip is a product manager with a different name?"

No. A PM writes tickets. A Skip reads the ice. A PM defines what to build. A Skip defines what to aim for and trusts the team to find the path. The distinction is between specification and orientation.

4. Ends, Not Sprints

In curling, the game is divided into Ends: complete rounds where each team delivers all their stones. An End is complete when every stone has been thrown and the score is tallied.

In Curling methodology, an End replaces the Sprint. But unlike a Sprint, an End doesn't have an arbitrary time box. An End is defined by completion of a strategic objective. It ends when the work is done, not when the calendar says so.

This matters because arbitrary time-boxing creates artificial urgency on the wrong axis. Some features take three days. Some take six weeks. Forcing both into the same two-week container distorts both. Parkinson's Law says work expands to fill the time allotted. Its inverse is equally destructive: work gets sliced into meaningless increments when the container is too small. Sprints trigger both failure modes simultaneously. Small tasks expand to fill the sprint. Large tasks get hacked into "sprint-sized" pieces that don't stand alone.

Ships in the Age of Sail weren't built in two-week increments. They were built in phases: keel-laying, planking, rigging, fitting. Each phase ended when the work was done. The phase defined the work, not the calendar. An End works the same way.

5. The House Is the Goal

The House is the target: concentric circles representing the ideal outcome. In software, the House is the user outcome you're optimizing for.

Gary Hamel and C.K. Prahalad introduced the concept of strategic intent in their 1989 Harvard Business Review article. Canon's strategic intent was "Beat Xerox." It didn't specify how. It didn't break the mission into two-week sprints. It specified where, and trusted the organization to figure out how. The House works the same way. Aim for the center. Adapt on the way.

Not every stone lands in the button (the bullseye). Some stones guard, blocking the opponent's path. Some knock opponents' stones out of scoring position. In software, not every deliverable is a user-facing feature. Some work is infrastructure. Some is technical debt reduction. Some is positioning for a future play. The House framework legitimizes all of these as strategic, because every throw has purpose relative to the goal.

Teams That Already Curl

You don't have to take my word for it. The Curling pattern already exists in the wild. It just doesn't have the name yet.

Basecamp/37signals runs six-week cycles with teams of two to three people. No backlog. No daily standups. No story points. Their "shaping" process is a Skip reading the ice. Their "cooldown" period between cycles is the pause between Ends. Jason Fried and David Heinemeier Hansson documented this in Shape Up and it's the closest thing to a published Curling playbook that exists.

Valve, the game studio behind Steam, published an employee handbook in 2012 describing a flat structure with no managers. Employees choose their own projects. Desks are on wheels so people can physically move to form teams around work. This is Stones: people gravitate toward work that matters, deliver, and move on.

Special Operations teams are the clearest parallel. A Navy SEAL platoon of 16 divides into squads of 8, then into fire teams of 4. The team leader provides intent (Skip). The operators execute (Throwers). Everyone watches for and clears threats (Sweepers). No standup needed when your coordination is continuous and your trust is earned through selection and training, not through ceremonies.

Four people. Clear roles. Continuous coordination. No ceremonies. This pattern repeats everywhere high performance matters.

Isn't This Just No Process?

I can hear the objection. This is cowboy coding with a sports metaphor.

Fair. Every methodology critic eventually arrives at "just trust good people to do good work," which is true but useless as advice.

Curling isn't no process. It's different process. It has defined roles (Skip, Thrower, Sweeper). A unit of work (Stone). A completion model (Ends). A coordination model (Sweeping). A strategic framework (the House). That's five structural elements, the same number as Scrum (roles, artifacts, events, rules, values).

The difference is where the structure lives. In Scrum, the structure is enforced by the calendar: every two weeks, these ceremonies happen whether they're needed or not. In Curling, the structure is embedded in behavior: you sweep when the stone is moving, you plan when you're reading the ice, you evaluate when the End is complete. Less ceremony. More structure. It's just invisible to anyone who thinks process means meetings.

Curling vs. Scrum: A Quick Comparison

| Concept | Scrum | Curling | |---------|-------|---------| | Unit of work | User Story | Stone | | Time box | Sprint (2 weeks) | End (completion-based) | | Daily sync | Standup (status) | Sweeping (obstacle removal) | | Leadership | Scrum Master (process) | Skip (strategy) | | Progress metric | Velocity | Stones delivered to the House | | Planning | Sprint Planning | Reading the ice | | Completion | Carry-over to next sprint | Stone is delivered or not thrown | | Coordination | Synchronous ceremonies | Continuous async sweeping | | Failure mode | Zombie stories, velocity inflation | Missed throw, visible and correctable |

Try It Tomorrow

You don't need a certification to practice Curling. You don't need a book. You don't need a conference. You need one week.

Pick one Stone. Tomorrow morning, instead of opening Jira and scanning the sprint board, pick one thing. Define it as a Stone: what does done look like? Who is it for? What is the target in the House?
Sweep for someone. Find a PR that's been open for more than a day. Review it. Find a question in Slack that hasn't been answered. Answer it. This is sweeping.
Kill one ceremony. Cancel your next backlog refinement. See if anyone notices. If they don't, you found ceremony that was overhead, not value. If they do, figure out what actual information was being exchanged and find an async way to exchange it.
Run one End. Take a feature or project and run it as an End instead of a sprint. No time-box. Define the strategic objective. Let the team execute. Evaluate when it's done. Compare how it felt.

The bigger shift is already underway. The question is about to change from how we organize work to who throws the stone.

The ice is ready. Let's play.