At some point in your career, you’ll come across a problem with no clear solution. Further, you won’t even know if it’s possible. What is a programmer to do? Well, obviously you spike it out! For those that don’t know, spikes (in Agile) are time-boxes used to explore an issue or proposed feature. The goal is to determine the best solution and the required effort.
Spikes are great for exploring and de-risking problems. Typically, the emphasis during most spikes is to find a solution and create an estimate. However, this can lead to a loss of other lessons learned. Below, I outline how I approach spikes by focusing on two objectives:
- Gathering as much information as possible
- Create lasting value over the life of the project
1. Set clear expectations/concerns.
The first step is to clearly state the problem we need to solve. Context is important. While stating the problem, documenting the current assumptions and known design limitations allows us to track the state of the world before investigation. Additionally, this allows us to clarify as a team what those assumptions are, and how they may affect the given problem. If you skip this step, you may skip over out-of-the-box solutions, ruled out by unstated assumptions.
Based on the outlined problem, we want to propose a number of possible solutions. When stating these solutions, we want to answer several questions:
- How does this address the problem?
- How complex is the proposed system?
- Will this solution affect overall project risk, and if so, how?
- How likely is this solution to work?
Based on these questions, we then can break down what order to evaluate the proposals, and, more importantly how much time we should allocate for evaluation. When determining how much time to allocate, we should time-box not only the individual proposals but also the overall time-box for the spike. This enveloping time-box should be based on the importance of the feature and the long-term risk of bad or subpar solutions. Once we have established the problem, proposals, and time-box, the only thing left is to evaluate.
2. Answer just enough.
Now we have the proposals in hand along with our expectations. How do we use this information to produce quality results quickly? The key is to answer just enough to de-risk or prove viability. A common anti-pattern of spikes is to find a solution and then carry the work into a complete feature. However, since you are eschewing normal programming patterns such as testing and documentation during a spike, incorporating the work into a feature often requires retroactively adding these expectations. The retroactive work leads to missing documentation, poor test coverage, and lack of code review standards.
The better solution is to take the solution just far enough to determine plausibility, as well as provide a reasonable estimate of how long the work will take. Additionally, since there were possibly several proposals, quickly determining viability allows you to either succeed early or evaluate several proposals faster. Now that we know our most viable proposal, the only thing left to do is estimate and work it into a feature. Right?
3. Document the results and conclusions.
Nope. We want to document all of the lessons learned, not just the best proposal. To do this, we want to produce a spike overview or report. This doesn’t need to be long, but it should capture a few key factors and info:
- State the problem, assumptions, and proposals we created in step 1.
- Provide an overview of the most viable solution. Implementation lessons and example code is particularly useful in this section. This work should clearly state the key findings, as well as an outline of any shortcomings or potential edge-cases determined.
- Document all failures or proposals deemed nonviable. Concisely state why this proposal was discarded. We will want to preserve this for a possible future where we need to revisit the problem.
You should store this document in your project documentation, as well as briefly present it to your team at the conclusion of the spike. This will provide a jumping-off point for whichever pair is assigned this in the future. The document will also provide rationale for why the issue was approached this way for the project if this problem is every re-evaluated.
Conclusion
Above, I outlined three steps I take to make sure that spikes have lasting value for your project. The first step is to make it clear what problem we are solving and how we think we can achieve it. Next, we test each proposal just enough to determine if it is viable and solved the problem in question. Finally, to make sure we remember lessons learned and why we arrived at our solution, we document how we got there. Hopefully, this helps you produce spikes with lasting value for the future when you will need them.