The Agile Bicycle: A Better Analogy for Software Development
In a recent software development seminar, we discussed a famous analogy for agile development. If you’ve ever read a book or attended a training sessionon on agile/Agile development, you’ve probably seen it, too. Henrik Kniberg created the original and best known version of the drawing.
The image is not meant to be taken literally. Instead, it’s intended to show some of the key benefits of agile development over waterfall methods, particularly with regard to Minimum Viable Product (MVP):
- Value is delivered at each stage of development.
- The solution is delivered and improved upon in an iterative model.
- At each stage, the solution can be evaluated and adjusted if needed.
I heartily endorse agile and the concept of MVP for all of those reasons, but this image really bothers me, for several reasons.
- This is neither incremental nor iterative development; you can never build a car by starting with a skateboard, bicycle, or motorcycle. As Kniberg notes in his blog post about the image, it describes product development, not software development.
- The image requires too many hypotheticals to create a viable path for development. In my seminar, the leader proposed that the actual problem to be solved was moving boxes across a parking lot, and therefore a skateboard was a working solution. (Never mind that the final solution — a four-door sedan — is terrible for moving boxes.)
- If I were hired to build a car, and I delivered a skateboard as my first working prototype, I would be fired immediately.
To make matters worse, my CEO is an engineer by training, who ran our manufacturing facilty for several years before becoming CEO. If I were to ever show him this analogy, I would spend the entire meeting defending this image, and we might never get to the actual topic of agile development.
Images and mental models are never perfect, but they do have to be good enough. This venerable image simply isn’t good enough. In the real history of automobile, it took many years of development before an automobile could outperform a horse in simple tasks, and we’ve since had a century to improve automotive technology. Explanatory images should be simpler than the concept that you are trying to illustrate, and this image is more complex than agile development, because it tries to compress 125 years of automotive development into a few images. Further, for anyone who actually knows something about automobiles or manufacturing, this image is more of a hindrance than a help.
Hidden within this image, however, is a much better analogy waiting to be unpacked: the bicycle. Nearly everyone has ridden a bicycle at some point, and both the technology and history of its development are simple enough to be grasped quickly. Furthermore, the development of bicycle technology — at least in the early years, at a large scale — was both iterative and incremental in a trule agile way.
The Agile Bicycle
For 200 years, bicycles have been trying to solve the same basic problem:
How can I move faster and farther than walking or running, while still using only my own power?
Iteration 1: The Velocipede
The earliest bicycles adapted two technologies that were well-established by the 1800s — wheels and saddles.
This solution worked pretty well for a first attempt, and you can still buy children’s bicycles that use this same basic design. To move forward, however, you had to push against the ground, then lift up your feet. You could only move forward a few yards at a time, and there was no way to control or sustain your speed.
Iteration 2: Pedals!
The second iteration added a pair of pedals attached directly to the front wheel.
Now, riders could maintain speed without having to put their feet on the ground. They were able to travel faster and farther than before. But the pedals were inefficient, making poor use of the power of the rider’s legs.
Iteration 3: The penny-farthing
To increase the efficiency of pedaling, the front wheel was made larger. With each turn of the pedal, the wheel traveled a much farther disance. The rear wheel, now less important, could be reduced in size to save weight.
The penny-farthing bicycle became popular among wealthy young men, but the expense and danger of this design — just think of falling off that seat! –limited its user base.
Iteration 4: The safety bicycle
How could a bicyle retain, or even improve, the efficiencies of the penny-farthing, while making the vehicle safer? By adding a rear-wheel drive.
Now, the wheels could be kept the same size and the seat kept low to the ground. The pedals turned a gear connected by a chain to a gear connected to the rear wheel. The ratio of the gears could be adjusted so that the bicycle moved just as quickly and efficiently as the penny-farthing, yet much more safely.
This version of the bicycle was enormously popular. After decades of development, the bicycle became a mass market success. The user base exploded, and development could focus on more complicated, incremental improvements, such as…
Iteration 5: The ten-speed
Multi-speed bicycles!
The derailleur, the device that allows riders to change gears on a bicycle, was invented around 1900. With multiple gear ratios on a single bicycle, riders could maximize their efficiency, using lower gears for increased power when starting or on hills, then shifting to higher gears for greater speed. The bicycle had arrived at its essentially modern form.
An Improved Analogy
Why is the history of the bicycle a better analogy for agile software development?
- Each iteration of the bicycle focused on solving the same basic problem: using human power to move faster and farther.
- The technology of the bicycle is familiar and relatively easy to understand.
- The bicycle’s development was truly incremental, adding new technologies at each stage but using the same essential paradigm. At some stages, existing bicycles could even be retrofit with the new technologies.
- The development was also iterative. Different versions of the bicycle were released to the public by competing manufacturers, allowing user feedback to inform the direction of development. Some technologies, like the pedal, were kept in subsequent iterations, while others, like the penny-farthing’s giant front wheel, were discarded fairly quickly.
Now, can someone turn this analogy into an awesome cartoon for the next bestselling agile textbook?
