4 x 100 Metres Relay
I’m a big fan of sports, athletics included. The 4 x 100 metres relay usually are a very interesting and exiting event at the World championships or in the Olympics.
The current world records (for men):
- 400 Metres: 43.18 seconds, by Michael Johnson from Sevilla (26 Aug 1999)
- 4 x 100 Metres Relay: 36.84 seconds, by Jamaica from London (11 Aug 2012)
The relay time by the Jamaican team is 15% faster, but Michael Johnson is one of the best athletes ever lived. How can this be? There are two reasons:
- Each individual in the Jamaican team could run at maximum capacity (400 Metres is not long, but it is not possible to run with the same speed as for 100 Metres)
- No loss in speed in the exchanges of the relay baton
So in this case 1+1+1+1 don’t become 4, it becomes something even more! How can we translate this to a Lean/Agile context?
One piece continuous flow
In Lean the true ”Nirvana” is one piece continous flow. Where one piece is flowing between the value adding steps in the work process without any waiting time or stocks in between. Like the relay baton! Which of the reasons above can we start to work with? Of course you can (and should) hire the most skilled people and make them perform at their best, but the most interesting thing are the exchanges between the runners. Most time can be won here. In fact a country with less skilled runners can compete and do really well in the Olympics or World Championships if they practice their exchanges to perfection. Usually one of the favorite countries will fail in an exchange and thus be disqualified.
In your organization, do you practice on the exchanges between the steps in your process? Or is your focus only within the process steps?
Let’s say that the ”runners” in the 4 x 100 Metres Relay are represented by:
- Analyst
- Developer
- QA
- Deployer
How is the exchange of the requirement (= the relay baton) happening between the analyst and the developer? Do the developer ”get up to speed” on the requirement before it is handed over? Do the analyst ”run along” together with the developer to make sure that nothing is lost in the exchange (to make sure that the developer fully understand the requirement)? My guess is that in most of the cases the requirement is queued up in between (for example as a state change in a tracking system with a shift in responsibility).
Learnings
What is there to learn from this example? First of all we need to practice on the exchanges to make them as smooth as possible. This can’t be done when we are ”in competition mode” (i.e. doing our daily work delivering to our customers). We need to take a step back, reflect on our behavior, and then make changes (to get continuous improvements). Second is the focus and information sharing if you like. All runners are fully aware of what to do and when to do it. They have all the information needed as they can oversee the whole race.
I’ve made a presentation on Slideshare that you can use for inspiration and to generate ”buzz” around this topic.
The Agileist 