Quick and dirty implementation to reduce technical or business uncertainty.
When developing products, there are many uncertainties.
The Ends-Uncertainty refers to What to build? And
The Means-Uncertainty refers to How to make it?
There can also be social uncertainty that relates to how well people collaborate, but let’s assume that people like working together.
Because if people involved are not getting along, then that is the most considerable risk, and all other concerns pale in comparison.
A Story in Agile development refers to valuable functionality your team can develop within an iteration. To implement the Story, the developers need to know how to make it, and the Story “donor” (Product Owner or Stakeholder) needs to know what to build. But when the team is working on new architecture or developing functionality that cuts through a messy codebase, there can be a high degree of uncertainty on how to do it.
A Spike is a quick and dirty implementation to reduce the technical or business requirements uncertainty. As an investigative technique, a Spike enables the team to try building essential connections between architectural components or modify the legacy codebase in “safe mode,” so the developers can learn more about how to make it and reduce the Means-Uncertainty. Because the Spike is an investigative technique to maximize learning, the code is not production quality and does not meet the Definition of Done.
Early in development, the team does not have enough experience and knowledge of the systems, so novice agile teams make the mistake of implementing too many Spikes. Instead, the team should stage Spikes to implement learnings immediately. And also, because exploratory work can meander in many ways, it is helpful to set up a fixed time-box for a developer pair to investigate and share learnings from their Spike. The team may decide to invest in another time box to explore the Spike even further, but this has to be a conscious team decision.