How to Run a Four-Minute Mile and Accelerate Software Development

The “impossible” four-minute mile was accomplished by Sir Roger
Bannister on a windy day in May of 1954. Now you can do it too. It is
not that complicated when you think about it: just run four consecutive
quarter-mile sprints in under sixty seconds each.
Okay, so maybe the actual execution isn’t trivial. But his approach to the problem correlates directly to successful software delivery: measure, manage, execute.
Bannister pioneered measurement, assessment and adjustment in
competitive athletics. He studied how his body reacted to exhaustion.
He modified his running technique to eliminate unnecessary movements.
And he created a specific plan to track his progress and achieve his
goal of being the fastest man in the world.
So how does all this relate to the software industry?
We all have development goals that can seem as daunting as the
four-minute mile. All too often, our attempts at sprinting devolve into
a death march to failure.
One reason, I propose, is that we are failing to capture what
efforts are working and what efforts are failing. We often know very
little about the actual source code we produce. And we rarely invest
resources into measuring important data that could materially affect
the way we manage our teams.
Bannister set up a regimen of ten quarter-mile sprints, meticulously
measuring his results until he could accomplish them all in sixty
seconds each. He recorded his times and tracked his progress. He
adjusted his strategy based on the results.
What are you measuring related to the code generated by your teams?
Do you know how much code is regularly produced? Do you know how
complex the code is? Have you calculated test coverage? Do you have
visibility into module dependencies? What is the percentage of
duplicated code? How long does it take to generate a complete build?
What about a complete build on an entirely new machine?
Have you established internal targets for any of these metrics?
The end goal is not to create less complex code, reduce
defects or lower integration times – these are just the positive time
results of quarter-mile sprints. The end goal is to accelerate delivery
of reliable software. But you cannot achieve that larger goal by simply
showing up at the track and running as fast as you can. You have to
measure, plan, train and improve execution.
And it all starts with a simple question: how well do you run the
quarter-mile and what measured factors are preventing you from running
faster?
Originally authored by Stelligent at testearly.com