Failure is not usually something organisations want to talk about.
We prefer words like delivery, progress, efficiency and success. Those are good things. But in Agile work, some of the most important learning comes from small failures that happen early enough to do something about them.
The key is not to avoid failure completely.
The key is to make failure safe enough, small enough and visible enough that the team can learn from it.
Continue reading What teams taught me by failing safely
The second supporting agile/XP practice that I want to explore is ‘spike solutions’ or simply ‘spikes’.
The name ‘spike’ comes from rock climbing. A piton (sometimes called a pin or peg) is a metal spike or wedge that is hammered into a crack in the rock to act as an anchor to secure the rope. This protects the climber from the consequences of a fall and to assist progress. The spike itself doesn’t move the climber closer to the top but it helps provide a safe path to do so.
Similarly, in software development, spikes help developers determine a safe path forward when knowledge is lacking about how to do something.
A software spike is a technical investigation—a small experiment to research the answer to a specific problem about how to do something.
Continue reading Spikes: supporting agile practice