Iterative and Incremental Software Development — A Formula 1 Analogy
I want to talk a little bit about iterative software development here. I am sure most of you are familiar with the concept as it’s not a new approach to software development. However, this is one of those principles that makes a product team effective and yet, it’s so easy to disregard. That, I find it quite surprising!
Back to Basics
For that reason, let’s refresh our memory on what this method is really all about. I am going to copy this directly from the Wikipedia article as it does a pretty good job of articulating the approach. However, I will make this easy for you a bit and highlight the parts that has the key insights 😉
The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. Learning comes from both the development and use of the system, where possible key steps in the process start with a simple implementation of a subset of the software requirements and iteratively enhance the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added.
The way I interpret this boils down to two simple words: opportunity cost. This method fundamentally makes you derisk the chances of getting the decisions wrong as you are going to be constantly learning about the value of your work through the use of the system.
There is a great analogy here that I would like to use (a simplified one, I’m sure there are details here that I’m about to miss but that’s not the point 😉). A Formula 1 team’s goal might well be to take their car’s straight line speed from 350 km/h to 375 km/h.
What options do this team have here? Let’s look at the two competing ones 🔍
Option 1
Get into the factory, work as hard as they can to take the car to 375 km/h and make it available to be used in the races. This has taken 6 months for the team to achieve this goal.
- Advantage: Goal is clear and the team essentially hit their goal.
- Disadvantage: There might be unintended consequences off the back of the changes introduced here due to many parts being changed to hit the goal and real test is happening on the track during the races. This has two consequences: one is that it will be hard to pin point what’s not working due to many moving parts having changed. The second one is that till the root cause of the issue is identified and fixed, the team has to rollback to the previous car which has straight-line speed deficit.
- Disadvantage: While changes were being made, the competition was still going on and team lost potentially valuable points due to their car producing 350 km/h straight line speed.
Option 2
The team would get into the factory, work as hard as they can, take the car to only 360 km/h straight line speed and make it available to be used in the races. It has taken the team 3 months to achieve this. Then, they spot issues and provide fixes for these which required half more month to be spent. Then, the team would work as hard as they can and take the car to 370 km/h straight line speed. This has taken 1 more month. Then again, the team spot issues and provide the fixes which takes another half more month. Finally, team take 2 more months and hit the goal by getting the car to go 375 km/h straight line speed. In total, you have spent 7 months.
- Advantage: You got the competitive edge over your competitors over the course of the season for the races that you were able to bring an improvement.
- Advantage: Risk of getting things wrong from both strategy and execution point of view as the go-to-market cycle got shorter.
I am sure you can relate this if you are part of a software development team or even working close to one! However, this doesn’t only consist of pink fluffy clouds. This approach can get hard for the team sometimes and even demotivating as it may seem like the team is not hitting their goal even if they are continuously getting closer. There could also be the misperception around team being inefficient towards achieving the goals as it took them 7 months whereas it could be possible to do this in 6 months.
However, one might ask the killer question here: is their goal to deliver improvements or win the championship at the end of the season? 🏎 I will let you figure out the answer to that one 🚀
👋 If you enjoyed this post, there is high chance that you might enjoy one of the recent talks I have delivered at NewCrafts Paris about Lean Software Development.
