If you are a human with a TV, you’re probably familiar with Formula 1. Non-fans might describe it as a bunch of dudes driving in circles for 2 hours until somebody wins and an absolute waste of time to watch.
To fans, F1 is so much more – it’s about strategies, tire temperatures, pit stops, and rain on tracks, to name a few things.
Agile and Software development, two team sports compared
If you are working in software development, you are probably familiar with Agile or maybe even working in one of its frameworks. Agile is a mindset defined by four values, guided by 12 principles, and manifested through many different practices. And like F1, you either love it or think it’s pointless.
This is not where their similarities stop, so join me on this ride while I draw parallels between the two team sports.
Team, team, team
You read that right – both F1 and Agile are team sports. And while in Agile, the teams are kept relatively small, F1 teams can count over 1000 people if the budget allows. So besides two drivers, you’ll find a team principal, race mechanics, race engineers, data scientists, and many other experts. They are all working together as one team towards the common goal – winning the driver and constructor championships by gathering points in 22 races across five continents over the course of one season or nine months. The teams are cross-functional, assembled from driven professionals who each contribute to the bigger picture.
Formula 1 is a sport that has progressed a lot in its 100-year history. Not only are cars now faster, but they are using many technologies that people from the 1920s couldn’t have even imagined.
To create something new and groundbreaking, people need to be highly motivated but they also need to be able to fail without consequences or punishment. It’s not the fear of failure that stops people in their tracks, it’s the fear of repercussions for that failure.
There is no room for blame culture in a fast and stressful environment like an F1 race. Teams sometimes need to make split-second decisions, and you want them to be able to do that without being afraid of what will happen to them if the decision is wrong. If they fail, they fail together. They learn from it and come back stronger.
A team thrives in a healthy environment, receiving the support and trust it needs. When people feel like their work contributes to something bigger and they feel heard and valued, it motivates them to work even harder. Those are the people you want on your team.
The exact needs to happen in software development too. If we want to build quality products that make our users happy, we need to make room for people to fail and learn from their mistakes.
If we look at the F1 team from another angle and put the F1 driver in the user role, you can also see how vital the everyday collaboration is between him and the rest of the team. He is the one driving the car and can give the team the best feedback on how to improve the car’s performance. Our end users are the ones who should be driving our product development. There is no point in building something that no one will want or be able to use.
“You don’t expect to be at the top of the mountain the day you start climbing.“
Ron Dennis, McLaren CEO
I wanna go fast!
Agile is often equated to speed. But it doesn’t mean that developers will code faster. It means that we are focusing on delivering app functionalities little by little but more frequently. Agile means prioritizing the essential features and leaving the rest for later releases – that’s why we call the first iteration the minimum viable product. Short development cycles allow brands to launch products sooner, get feedback on them, and to be able to quickly react to market trends and changes.
In F1, cars change every season and each season’s car is the evolution of the previous one. They build a prototype each year, put it on tracks, learn something new out of each race, improve on it, and then test it again. The same is in Agile development. You usually start with some MVP, release it to the users, then gather their feedback on it, and based on that, work on improvements and new features.
F1 races happen almost every weekend, giving teams a short feedback loop that is valuable in Agile. Instead of trying to plan for every possible situation or problem in advance, they take it one race at a time. By taking those small steps, they eventually end the season with the best car possible.
Agile’s preference for short iteration in software development tries to do the same thing. It doesn’t just enable you to build your products step by step, but it also gives you more opportunities for better risk management. If you don’t know what is ahead of you, it doesn’t make sense to waste time and plan for everything that could happen. Instead, think about your short-term goals and prepare for them – both on how you want to achieve them and how to mitigate possible risks.
Copy Lewis, we’ll chat afterward
One of the staples of Agile is constant reflection. Call it retrospective, or inspect and adapt, or lessons learned. The point is the same – learn something from what you’ve just been through. There is no progress without change. You need to learn from your past experiences to become better. As a team, as a developer, and as a person. In fast-paced environments like F1 and software development, there will always be something that you could’ve done better.
F1 teams know this all too well. Whether a Grand Prix has gone well or wrong, they talk about everything that happened over the weekend to see what can be learned. They highlight the good but also examine what went wrong and how to avoid it in the future. It brings the whole team together, both people on track and in the factory, to give their feedback, perspective, and the bigger-picture overview of the race. As a result, they come out of it smarter and more focused for the next one.
“If everything seems under control, you’re just not going fast enough.”
Mario Andretti, F1 driver
Checkered flag
If the agile approach works for something as complex as building the fastest Formula 1 in the world, you can be sure it will work for your next software development project. Give your team a chance to talk to their users. Trust that they know what they are doing. Give them a safe environment where they can fail, and help them learn from their mistakes.
Take Guenther Steiner’s word for it.
