Spikes in Agile Software Development environments are used to investigate a concept and/or create a simple prototype. Basically, a spike is a quick (typically less than a sprint of effort) exploration by coding of an area in which the development team lacks confidence. The spike is concluded when you learn what you needed to learn. So-called because a spike is “end to end, but very narrow”, like driving a spike through a log.
The term “Spike” was introduced by Extreme Programming advocate, Kent Beck, who occasionally consults with us at Planview.
“Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build the spike to only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increasing the reliability of a user story’s estimate.”
Mankind always pays attention to the thin interface between the trivial and the impossible, and that boundary is where spikes live. If your development staff knows for sure how to accomplish something, then the process of estimating and tracking progress against estimates via velocity produces a predictable, repeatable process that confines risks. Although not trivial to the people working on it, to an observer outside the team the work is essentially trivial, and therefore a snore.
Spikes are used to expand the realm of the trivial by establishing beachheads into the realm of the impossible. Build a hypercube out of one million facts in 12 seconds? Impossible — until you prove that it can be done with a simple spike. Like all good magic, the trick is simple once you see how it is done.
I cannot improve upon this maxim, but perhaps it can be enriched with some real-world experience.
We have used spikes for a number of purposes at Planview. Here are just three that stand out:
- A spike was written to create a Silverlight grid that could support 50,000 cells to test the claim that this was possible with good performance (it is). This was done by one engineer in about 5 days of effort.
- The performance of a custom hypercube implementation was tested using a spike. This took about 7 days of effort.
- We tested the inclusion of very powerful dynamic graphic elements and an abstract machinery for utilizing.
None of these were velocity-generating. Each was done outside the bounds of our formal agile process which tracks progress against estimates of effort, yet each was critical in its own way to the success of a project. In keeping with the quote above, we use spikes to learn something — generally if a given approach will work, and often to eliminate the risk that a software company we don’t control is up to snuff. Of course, in a well-run development effort, you want to be doing that at beginning of the development cycle rather than at the middle or the end, but sometimes a problem and its solutions are not presented until late within a project.
If an organization cares too much about velocity, it can fall into a subtle trap of dysfunctionality: missing great opportunities because it is unwilling to invest a small amount in broadening the realm of the trivial into the impossible. It is relatively easy to run a software project to do something that everyone agrees can be done with enough effort. But if it is easy for you, it is easy for your competitors as well. To be truly excellent, a software development organization must utilize spikes in a disciplined manner to produce the best possible overall result for a given amount of effort.
![Product Portfolio Management in the Digital Era [Webinar]](https://blog.planview.com/wp-content/uploads/2017/09/Product-Portfolio-Management-in-the-Digital-Era-750x400.jpg)
![The 2018 Product Portfolio Management Survey Shines A Light on Top Performers [Video]](https://blog.planview.com/wp-content/uploads/2018/06/PDPM-study.gif)
