The Indianapolis 500 has been a part of my life for as long as I can remember. And after years of building software at SEP — an Indiana company through and through — the similarities are striking. The pre-race strategy sessions. Testing assumptions during practice sessions. Real-time adjustments during pit stops. The moment when weather throws your whole plan sideways. Strip away the speed and pageantry and you find something surprising: agile. The techniques race teams use to compete at the highest level mirror the techniques we use to build software that matters — strategy, discovery, delivery, iteration, and constraint management.
Let’s break it down.
Strategy: How Race Teams (and Software Teams) Plan to Win
Before we build anything, we need a strategy. What problem are we trying to solve? On the racetrack, the ultimate goal is to win the race. But, race teams face challenges familiar to product developers.
What does success look like? That definition, like product definition, is driven by constraints. Every team wants to win, but many face a reality that other goals are more achievable. Pole position. Finish in the Top Ten. Attract sponsorship money. Some teams are just trying to make it into the race.
This mirrors how we map our projects—documenting objectives and making tradeoffs to fit our timeline, team availability, budget, and other finite resources.
Discovery on the Track: Testing Assumptions Before We Build
Practice sessions provide opportunities to learn about the car’s performance, driver preference, and racetrack conditions. Teams confirm assumptions about aerodynamics, mechanical grip, tire wear, and fuel mileage. How will the weather affect the car? Driver preferences are discovered. Small changes have large effects – like moving the brake pedal half an inch to prevent the driver from inadvertently tapping it and losing speed.
Just like product developers, race teams use practice sessions to identify key assumptions and dependencies. They iterate their design to prepare for race day.
Like product discovery, race teams work to uncover as many unknowns as possible.
Race Day Delivery:
Why Agile Teams Think in Sprints, Not Finish Lines
A modern racecar doesn’t carry enough fuel to complete 500 miles. Tires wear out. The race is divided into stints. Think of stints as sprints. Before each stint, the team determines short-term goals and key constraints. Each pit stop is an opportunity to iterate. Race constraints include fuel mileage, tire wear, aerodynamic adjustments, and weather. During the stint, teams monitor performance and develop a set of changes for the next pit stop. After the pit stop, they retro on the resulting performance improvement.
Managing Fuel Like Managing Releases
Fuel is heavy, so you want to carry as little as possible. Refuel too often and lose track position. Striking the balance between weight (performance) and position is critical.
Let’s assume a full tank lasts about 30 laps at the Indianapolis 500. For a 200-lap race, we would need to stop on lap 30, 60, 90, 120, 150 with a final stop at lap 180. The last stint is only 20 laps. Work backwards from the end, and we can stop on lap 170, 140, 110, 80, 50, and 20. Same number of stops. You can stop anytime between laps 20 and 30 and still make only six pit stops. This is the fuel window.
In an agile development context, fuel windows are similar to release planning. Some releases have a few more features and some a few less.
Tire Wear and Feature Synchronization
Tire management adds another variable. Tires perform best when new and their performance degrades towards the end of a stint. Degradation is affected by car set-up. More downforce leads to faster degradation. Teams balance performance against longevity. Ideally, tire windows and fuel windows are synchronized.
In agile development, this is similar to synchronizing features. We need the cloud services ready before our new mobile app can use them. Ideally, these development timelines are synchronized.
Optimizing at Every Pit Stop — and Every Sprint
At each pit stop, the car is optimized for track conditions, traffic, and weather —adjusting wing angles, tire pressures, or fuel usage. Dialing this in will maximize the performance over each stint. Optimizing the changes at each pit stop maintains the performance advantages as conditions change.
Product development is no different. Techniques and strategies that worked in early sprints may not be as effective in later sprints. Maintain those optimizations to maintain performance.
When It Rains: How Agile Teams Handle External Disruptions
Weather constraints can take a few forms. The weather we had during practice may be significantly different than the weather on race day. Or, there is a sudden change in the weather during the race. On road courses, for instance, a sudden rain shower can force a change of tires or aerodynamic settings.
Even though we don’t race in the rain at Indianapolis, rain still affects planning. If more than half of the race is completed, whoever is leading when it starts raining wins. Sometimes getting a solid MVP out early beats waiting for the fully featured release.
Weather is similar to other external factors that product teams face — market shifts, competitor releases, infrastructure changes. Teams prepare for ideal conditions and adapt when it starts to rain. The best teams build flexible strategies that work across conditions rather than relying on a perfect scenario.
Yellow Flags and Production Bugs: When to Pit, When to Stay Out
Yellow flags after crashes can play havoc with our strategy. Every team faces the same question: “Should we pit?” Stay out and gain track position. Come in for fresh tires and fuel. The answer depends on your current situation and how many laps of the race remain.
Find a bug? Server down. Product teams must decide: hotfix now or wait? The calculus is different every time, and the best teams can adapt their strategy on the fly.
The Checkered Flag: Why Iteration Wins the Race
Motorsports, like product development, is a game of continuous iteration. Teams that succeed aren’t the ones with the perfect strategy—they’re the ones who iterate, who evaluate and adapt for every stint.
In your next planning meeting, remember the race team’s approach: align on vision, test your assumptions, build in iteration points, manage your constraints, and stay agile. Whether you’re chasing a checkered flag or a successful product launch, the principles are similar. There is something to learn from every lap.
