How we approach spikes
If you have worked according to the agile development methodology then you will most likely already be familiar with spikes. A ‘spike’ can be described as something that requires investigation before it can be estimated and where there is a higher element of unknown complexity relative to other stories. The exact reason behind the descriptive name is matter of opinion but one interpretation is that it is because a spike helps to ‘drive deep into a problem’. This translates to a time-limited and focused period of exploration and experimentation concerning a technology or technique. This may involve writing code, prototyping locally, background research, evaluating products, or a combination of all of these.
The outcome of a spike may result in code or a process that can be implemented in production but this is not guaranteed. It may simply turn out to be a valuable learning experience or an indication that we need to do something different entirely. In short, spikes allow us to make better informed decisions that benefit us in the long run.
Identifying the need for a spike
Although generally we aim for a balance of Features, Chores, and Bugs in our two week sprints, some may be much more spike heavy than others. For example, if a sprint closely precedes the development of a new feature, product, or architectural implementation then it is likely we’ll be working on one or more spikes.
The need for a spike is usually identified by the team during our sprint planning sessions and engineering team meetings but it might also arise from other discussions. Once agreed, it is added to our agile task tool along with a description and a list of starter questions to guide areas of research. We categorise a spike as a chore because this story type does not involve a story point estimate. We’ll also tag it with the label ‘spike’ along with project specific labels to keep track of it and distinguish it from other chores.
Allocating work
We don’t have any strict rules with regards to allocating work for spikes; every member of the engineering team is eligible to state an interest in or volunteer to work on any spike. We would declare this during our daily stand-up meetings so that everyone is kept informed as to who is doing what. Depending on the nature of the spike we will also decide whether it would be beneficial to split the work or pair on it. Most frequently though, one person will be responsible for undertaking the initial research.
Guiding direction and initial research
As mentioned above, we have come up with a list of questions that we feel are useful in guiding spike research:
1. What is the complexity?
2. What is the latency (to the user)?
3. How does the user experience differ compared to now?
4. Is there a skills gap? Have we used this approach before? Are there any documented reports of using this approach?
5. Is there a cost implication?
6. Is there a monitoring implication?
7. Is there an availability implication?
8. Is there a productivity implication?
This is usually the starting point for a team member when undertaking a spike. A spike most often involves investigating a number of alternative approaches, methods, or tools so addressing these questions with regards to each one can help us compare them and determine relative strengths, weaknesses, and potential pitfalls. Of course we can and do adapt and extend this question set according to each particular spike.
Sharing findings with the rest of the team
An important characteristic of a spike is that work on it should be time-limited. Ideally we recommend that the person undertaking the spike report their initial findings to the team after a day or two of focused research. This ensures that work on the spike continues to stay on track and benefits from the feedback and insights of other team members. With this in mind, the person undertaking the spike is responsible for scheduling a team meeting when they are ready to demonstrate or discuss their work so far. Based on this discussion the team will then agree on follow-up actions and decide what the next steps should be.
The road to implementation (or not)
The initial spike meeting may show that the spike needs more work or iterative discussion. It may be that it allowed us to fail fast (that is, rule out something that is not not viable) or highlight that a completely different approach or line of thinking is needed. If this is the case a follow-up meeting will be scheduled to review the existing spike or a new spike may be created if parameters have changed significantly. On the other hand, it may be possible to commit to a particular approach or to using a particular tool. In this case, the team will then discuss how best to break up the spike into stories that can be estimated and added to future sprints with a view to implementation. Regardless of the outcome the time we take to invest in spikes is always valuable.
Examples
Here are some examples of previous spikes that did make it to implementation and became great Kudos Engineering blog posts:
Choosing the elastic stack as a time series database
Converting AWS lambdas from Apex to native Go
Secret management in Kubernetes and GCP, the journey
If you like what you read and think you could contribute to our team at Kudos then take a look at our careers page to see what roles we currently have open.
