The 90% Untrue but 100% Useful Origin Story of the “Spike” in Agile
If you’re doing any kind of agile software development you’re making “spikes” for little bits of research, proofs of concept, or whatever you need to figure out cheaply before committing to real development. There are different versions of how the “spike” got its name. The one I love to use is most assuredly not true, but it is the best analogy I’ve heard…
Rock Climbing
When someone is “lead-climbing” on a rock face, they add protection as they go, clipping their rope into loops attached to the rock face. Before clipping in to the next protection, risk increases rapidly, as your fall doubles your climb: first you fall the distance above the protection, and then you fall the same distance further from the slack in the rope.
How far a climber will go before stopping to ensure protection depends on how risky the climbing feels. If they’re likely to fall, they might clip in sooner to make the risk more affordable.
Now, in the old days, before removable protection, if you were the first to climb a route, adding protection literally meant driving a spike into the rock.
(Yvon Chouinard, the founder of Patagonia, got his start by blacksmithing climbing spikes.)
And that’s how I think about spikes in the backlog. When the next move feels too technically risky on its own, a spike helps insulate uncertainty from consequence. This makes the risks affordable and leads to safer bets with the stories that follow.
