This is an excerpt from The Art of Agile Development, Second Edition. Visit the Second Edition home page for additional excerpts and more!
This excerpt is copyright 2007, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.
We perform small, isolated experiments to inform our decisions.
You’ve probably noticed how much Agile teams value concrete data over speculation. Whenever you’re faced with a question, don’t speculate about the answer—conduct an experiment! Figure out how you can use real data to make progress.
That’s what spike solutions are for, too. A spike solution, or spike, is a technical investigation. It’s a small experiment, in code, to research the answer to a problem. It usually takes less than a day. When you have the answer, the spike is discarded.
People often confuse spike solutions with walking skeletons: bare-bones code that demonstrates an idea from end-to-end. It’s the beginnings of a production implementation. In contrast, a spike is narrowly focused on a specific technical problem, and it’s thrown away afterward.
Spike solutions use code because nothing is more concrete. You can read as many books, tutorials, or online answers as you like, but to truly understand a solution, write working code. It’s important to work from a practical point of view, not just a theoretical one. The best way to do so depends on what you want to learn.
...to continue reading, buy the book!
In this Section
- Spike Solutions
- Quick Questions
- Third-Party Dependencies
- Design Experiments
- Making Time for Spikes
- Alternatives and Experiments