You Don't Know How to Sprint

I used to think I knew what sprinting meant in software development. Two weeks of work, a few meetings, rinse and repeat. But I was wrong. Dead wrong.

It took learning how to ride a motorcycle to really understand what a sprint should feel like. And no, I’m not trying to be clever with metaphors here - there’s a very real lesson about tempo that changed how I think about building products.

Riding a motorcycle is a constant dance between throttling and braking. When I approach a corner, the first thing I need to do is to place my motorcycle so that I take the shortest possible route (cutting the corner, as my teacher said) and brake much, much harder than I thought reasonable.

The braking I had to learn to do on a motorcycle was far more aggressive than the braking I do when I drive a car. The reason for it is that I can’t brake in the corner. Physics will make sure I run off the road if I do. I do, however, get a very smooth journey through the corner. And if I do it right I will have set up my bike to exit the corner like a bat out of hell (my teacher seemed to think that the speed limits were more guidelines than rules).

So what does riding a motorcycle have to do with building products and companies? Remember how I said it was a lesson in tempo? The same principle of braking and accelerating applies to how I see most people run sprints. Or rather, how most people don’t run sprints.

Most sprints I’ve seen have a constant speed and no real pause in between to take direction. Yes, the Scrum Guide says to have a planning day and a demo day and have a sprint goal to align work. But let’s be honest. Most teams don’t take a full day for demos and most teams simply drag forward the tickets that didn’t get done in the previous sprint instead of really adjusting direction.

So what is supposed to be a sprint towards a goal turns out more like a long distant run with watering stations where people run until they drop. In other words, most people don’t know how to sprint.

This is important because people burn out by this non-sprinting and because the company loses a lot of productivity if the speed is low enough to not burn out.

Just as with cornering with a motorcycle, I think there are three key elements to sprinting properly: Proper braking, setting direction, and high intensity.

Braking means stopping work completely for a while. A day or two, at least. This feels weird at first - no one likes feeling like they’re losing momentum. But this pause gives everyone a chance to let go of the tension that has been building up and it allows everyone to engage in the second step.

The second step is setting direction. What is the goal the upcoming period? How does that align with the goals of the business? What will we do differently from last sprint? These are the questions we skip when we’re rushing, but they’re critical for keeping the team on track.

Finally, you need high intensity. A team that focuses on a single goal for a fixed period of time can get a lot done in a short amount of time. But this intensity depends on two things. Firstly the team needs to trust that this sprint will end when it says it’s going to end. Second, every member in the team needs to hold each other accountable to not waste time on things that aren’t part of the goal.

This isn’t rocket science. Business folks do it with strategy days, military teams do it with their OODA loop. Even nature seems to pause during the winter. Yet when it comes to software development it seems to be hard for people to pause and reflect.

The irony is that by trying to maintain constant speed, we actually go slower. Just like a motorcycle that doesn’t brake for corners, we end up taking wider, longer routes and risk crashing.

But when we master the rhythm of intense sprints followed by real brakes, something magical happens. Teams become more focused, more energised, and ultimately more productive. They learn to throttle hard when it matters and brake decisively when needed.

So next time your team feels stuck in an endless sprint cycle, remember: sometimes you need to brake harder to go faster.