Notice the title doesn’t say Scrum “Software” Projects, because I believe Scrum can be applied to many different types of projects. Having music and motorcycle riding as the other passions of mine, I find myself drawing comparisons and reapplying learnings where I see fit.

In a talk about building trust through delivering results in Scrum software projects, analogies with hitting the apex at a race track have come up, and I felt I had to expand on that idea. So for this post, I’ll consider a software project, but again, the ideas can be applied to many types of scrum projects.

I’ve only started learning about apices and race lines when I started riding a motorcycle at a race track in 2017, so my comparisons here come from my understanding on the subject as of November of 2020. As I learn more, I may need to update this post in the future.

If you’re a fan of races (motorcycles or cars, it doesn’t matter), you are most likely aware that racers know how to hit an apex consistently and why they should hit them.

Consistency is key; hitting the apex consistently, lap after lap is extremely important. Hitting the top speed on a straightway isn’t as important as hitting consistently high average speeds, which yield fast lap times.

Reaching 200mph on the straight and then running off track isn’t the most efficient way to turn fast laps (not to mention you might crash when you run off). Working crazy hours during a Sprint to deliver a high number of story points isn’t an effective way to turn good quality software and keep doing it lap after lap; I mean, sprint after sprint (not to mention you may crash; I mean, get burned out).

The apex is typically the slowest part of a corner. The soonest you can get to WOT (wide open throttle, which means you’re using the vehicle’s fullest acceleration potential), the faster you can get to the next corner. But then, you also need to know that you will have to slow down in order to make that next corner. If you’re looking down to the speedometer to keep marvelling at how fast you’re going, chances are that you will be running off track. If we keep solely looking at number of story points, we may lose track of where we’re going.

In order to find the proper race line, with the respective apex for each turn, we need to analyze each turn backwards. We need to know what comes after each turn to be able to plan a strategy for getting in and out of the corner as fast as possible; if turn 2 is a slow hairpin, then we may never get to WOT coming out of turn 1. If turn 4 preceeds a long straightway, then we need to make sure we exit that corner as fast as we can, getting to WOT as soon as possible.

However, opening the throttle too soon, may cause us to run wide, creating a need to slow down, before accelerating to the full potential (a process that causes loss of precious time).

In a motorcycle, if we open the throttle too much too soon, it may cause loss of traction. Depending on how we handle the situation, when the bike regains traction, it may send us on a trip to the moon and back. Not pretty. How do I see that in a scrum project? Maybe we’re forcing performance optimizations when it’s not the right moment?

Back to planning the corner backwards: we need to see what’s coming. We need to have a vision. We plan for it. Then we execute it (by riding laps). As we do, we look ahead, through the corner.

We may misjudge how much speed we can take into a corner and brake too much. Next time around, we brake a little less.

We may not have good reference points (brake points, turn in points, apex, exit points) around the track to help us assess our speed and strategies. On every lap, we stay aware of those things, so we can fix it next time. Remember sprint retrospective meetings?

Such approach can only work if we are not going recklessly around the track. If we’re riding without control, we will not be able to evaluate our execution; we won’t learn anything from it. So we can’t improve it. We can’t come up with better strategies.

Only hitting the apex isn’t enough. Racers have different strategies for hitting the apex. If they’re trying to make a pass, they may decide to take an early apex, so they can carry more speed into the corner, hopefully passing the other rider, but at the expense of coming out ot the corner slower.

On the hand, if they’re trying to turn consistently fast laps, they may take a late apex, where they carry less spead into the corner, but are better placed to accelerate harder out of it.

See the riders in the photo below: some are trying to pass, some are planning to pass, some are trying to avoid being passed. Their plan to hit the apex varies based on their desired next result (turn a faster lap to stay ahead of the others, get closer to the rider in front and set up for a pass, etc.)

Each lap is a sprint. One fast lap does not guarantee a race win.
Each race is a release. One race win doesn’t guarantee a championship win.

Consistency is key.

Vision, plans, execution, evaluation, tweaks, repetition, strategies, using them accordingly, focus, flow. Wait, am I describe racing or a scrum project?

Image source: Pixabay