At Adaptavist we've been empowering the world's most complex organisations with Agile for a decade. We think we're pretty good at it but that doesn't mean we can't learn anything new. In fact, one of the key lessons of Agile is a willingness to keep learning. The experience we've had working with the Sahara Force India Formula One team this year has massively contributed to that process.
One of the first things you realise is that F1 has been doing Agile development for years. It just the way F1 works rapid prototyping and product development within incredibly tight time constraints. The viable part of your Minimum viable product really matters when it has to travel at over 200mph.
Here are five things I've learned about how Agile works best through experiencing it in F1.
- Continuous delivery of the best possible product. The Formula One year is effectively: build a prototype, test it, learn something from that and test again. And this is exactly how Agile should be. The teams proceed like this throughout the season in a constant quest for incremental gains. Waterfall development is: let's plan for jumping across this giant chasm. Agile, in contrast, is about taking a small step, checking where you are, and then taking another step, in a constant feedback loop. In essence, Agile is about recognising that your destination is reached via many small steps, which is exactly what an F1 team does.
- There's a clear goal and everyone knows what it is. All F1 teams are in pursuit of a single clear goal: get faster. Winning every Grand Prix would be unrealistic for most teams. They will set their own targets to get on the podium, to score a certain number of points or whatever, and that will constitute winning to them. In the meantime though the clear, unequivocal goal is simply get faster. It gives them the kind of clarity of purpose that should underpin and drive all Agile development.
- Collaborating with your customers is key. It turns out that in an Agile context, the F1 driver is the customer. Essentially, the engineers are building a car to suit their characteristics, so they can drive it as fast as possible. Interestingly, the most successful drivers tend to be the ones who are best at giving feedback on the car's performance; and the most successful teams are the ones who are best at extracting feedback from the driver. This is how it should be in all Agile development. The customer has to be both willing and able to provide actionable feedback after every iteration, just like an F1 driver.
- Individuals and interactions are more important than prescribed tools or processes. F1 is about one man driving round a track very quickly, backed up by hundreds of people, every one of whom is vital to the car's success. It's crucial that they all work together coherently and do their part very well. And this is exactly how it should be with Agile. The teamwork of motivated individuals with a clear goal is what underpins its success.
- Development is cyclical and continuous. Finally, F1 development is in loops within loops. There's actually an Agile cycle within each race itself the team is continually getting feedback and making adjustments to the car. Then there's the one or two-week cycle around each race preparing for a specific track, and testing and refining the car on that track ahead of race-day. Aerodynamic testing in the wind tunnel is a three-week cycle. Around it all there's an annual cycle of car development. Work on next year's car will begin mid-season and be informed by what's being learned every day about the current car.
This year, we've had a whole new perspective on Formula One. Being Sahara Force India's Technical Partner obviously adds extra interest to the races. It also inspires to push our own Agile development further. The combination of restless, continual striving is what Agile, for me, is all about.
Adaptavist is a Technical Partner of Sahara Force India Formula One team.