You would use a spike to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Spike are only built to address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.
Broadly:
analysis of the overview and breaking into tasks is a functional spike.
gaining new information on proposed or prototyped implementation and strategy is a technical spike
-
To mitigate risk - especially when using a technology that we’re not entirely familiar, which we will be constantly- we don’t want to make any promises we can’t keep!
-
When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk
-
If your team is having trouble on estimating the size of the user stories
-
If accurate estimates are crucial because there is no contigency for project overrun.
-
In building a complex architecture to allow the architecture to develop rather than being fully designed upfront as BDUF.
- Define a goal.
The most important thing to do when spiking a solution is to define your goal. Defining a goal provides focus. Without focus, you’ll waste valuable time doing too much. Remember, you’re singular purpose is to vet a solution. You want to gain confidence that you can accomplish something, not actually accomplish it. Remember, code developed during most spikes is meant to be thrown away. If you find, given the constraints of the project, that you can’t accomplish a task, you’ve done your client a huge service.
- Limit your scope.
Just because your spike isn’t meant to deliver production ready code, doesn’t mean you shouldn’t start with a plan. The more you intentionally limit the scope of your spike from the beginning, the faster you can move towards your goal. Filter out what are your unknowns -the bits you are trying to investigate. Then find out which bit of the code can be faked out, simulated, or stubbed to use your time effectively.
- If the goal is too broad repeat, if not evaluate the solution.
Ensure that you have small, focused, and independent goals to meet your needs. Doing so will allow you to move forward with greater confidence that you could meet our customer’s deadline.
You would pair with someone but spike with different approaches to solve the same problem. Each will research and code independently and compare their notes during the day.
Unlike production code, spikes are isolated, small, throwaway code; therefore, don't have to adhere to extreme programming mandate by being pair-programmed code. This leads to multiple solutions which is better practice to avoid confirmation bias.
Extreme Programming GDS blog on implementing technical spikes