February 25, 2026

What Curling Can Teach Us About Agile - Mike Cohn

5 minutes

With the Olympics underway, I’ve been watching a few events I don’t normally pay much attention to—like curling.
At first glance, curling looks almost comically simple. Someone slides a stone down the ice. A couple of teammates run alongside it frantically sweeping the ice with brooms. The stone glides… and somehow ends up exactly where they want it.
But the more you watch, the more you realize curling isn’t about making a perfect throw.
It’s about making adjustments after the throw.
And that’s what makes it a great analogy for agile.
For a long time, traditional software development treated projects as if teams only had one chance to get everything right. The goal was to write the requirements document, create the design, then implement everything exactly according to plan. If you did enough planning up front, the thinking went, you could get it right the first time.
The problem is that software development rarely works that way.
Even if you have smart people and a solid plan, you’re still operating on uncertain “ice.” Customers don’t always know what they need until they see it. Stakeholders often describe what they want in ways that are incomplete, or ambiguous, or shaped by assumptions that turn out to be wrong. And developers—no matter how experienced—can misunderstand what they hear.
That’s not incompetence. That’s just reality. Communication has friction. Uncertainty is built in.
In curling, the team knows that too. They can’t control the ice. They can’t assume the stone will behave exactly the same way every time. Conditions vary. The surface isn’t perfectly predictable. If the players just stood there and watched the stone slide, hoping it ends up in the bullseye, they’d lose most of their matches.
So instead, they sweep.
Sweeping doesn’t completely change the outcome. It doesn’t teleport the stone to the target. But it nudges the stone’s speed and direction. It helps the team adjust to what’s happening in real time.
That’s what agile does for software development.
The plan is like the initial throw. It matters. You need to aim. Once the stone is moving, you don’t get to stop everything and start over—you can only respond. But agile recognizes that aiming once isn’t enough.
The best teams don’t aim once—they keep aiming.
They build something small, show it, listen, learn, and adjust. They use feedback to steer the product toward what users truly need—not just what they said they needed, but what they meant. The known needs and the unstated ones.
In other words, agile isn’t about getting everything right up front.
It’s about staying close enough to reality to make course corrections while they’re still cheap.
One of the biggest mindset shifts agile asks of us is to stop treating change as failure. In the old model, change meant the plan was wrong. It meant rework. It meant someone made a mistake.
But in agile, change is often a sign that learning is happening.
Curling teams don’t apologize for sweeping. They don’t view it as an admission that the throw was bad. Sweeping is part of the game. It’s what turns a decent throw into a great result.
Agile teams do the same thing. They don’t just launch work and hope it glides perfectly to the finish line. They inspect, adapt, and steer as they go.
That’s how you succeed with agile.
And in the meantime, enjoy the Olympics.