The pointy thing of spikes

There was just no possibility to get an agreement. We did not know this new technology and that is why we had quite the disagreement whether it would be easy to implement, or very hard. Half the team pokered two storypoints the other half eight. This refinement was going nowhere and we were starting to run late. “Let’s do a spike” my product owner proposed. Really? I thought, a Spike? That’s the solution?

(Photo by jami jari)

Strictly looking at the meaning of spikes, my Product Owner could be right — but I think spikes are sometimes more of a symptom of something worse than that they are a solution. A way to plug a hole with gorilla tape. Yes it works, and is the way to go in some cases, but don’t see it as a way to plug a hole in your cruise ship — at least not permanently.

So what are spikes?

Spikes are actually taken from Extreme Programming. A spike is used in an uncertain environment — for example when you are considering introducing a new framework or technology in your code. A new technique which could have either a big added value or save a lot of time on the long run. The technology is new to the team, so it needs investigating.

Spikes are usually time bound. Like, spend eight hours investigating what the new database functionality with the upgrade could bring us. Spikes are also usually ended in a presentation — not towards the stakeholders, but to the team, where the investigating team member shares his new gained knowledge and the results. The presentation should assist the product owner on whether he wants to continue with whatever has been investigated.

Spikes are usually product backlog items which aren’t pokered or discussed in refinement in the traditional sense. It’s also easy to imagine why — an unknown technology is very difficult to have a feeling for how much work the team needs to invest and, how much value it will give to the users.

Two ways to misuse spikes

I have seen spikes being misused in two interesting ways. First off, a spike can be a hidden way to refine a story, and there is a fine line between that and an actual spike. If you need to spend a few hours refining a story, that’s OK, so just spend it. Don’t use your scrum board as an accountability tool.

The second way spikes are misused is by attempting to work around the Definition of Done, especially in case of a functional spike. If you just want to have a quick and dirty mock-up of a new functionality, a spike looks enticing, because the result doesn’t have to adhere to the Definition of Done. But that usually costs more than it delivers on the long run. That DoD is there for a reason, and working around it erodes the quality of your increment. Yes, you can do the documentation, quality and performance tests later — but are you, really? Are you ever going to plug that hole which requires Ops to regularly fix stuff on production?

(Photo by Canva Studio)

So should we stop using spikes?

Short answer — no. Although I will always look at spikes with some healthy suspicion, I have been proven wrong before as well. Using spikes to investigate a new possibility for your product is the way to go to keep on innovating and to prevent your system to become an outdated Mastodon nobody dares to touch, let alone work on. However, we should be mindful in the way we use them and how they are being done. Some tips to work around the most common pitfalls:

• Make sure to time limit the spike, to make sure that you have a regular way of checking whether you should continue investing, abandon the plan, or turn it into a story. Make a guesstimate on at which point you would at least expect some result, and make that the time limit. This also helps focusing the spike on the subject it’s supposed to have.
• The assigned team member has to present the spike to the rest of the team and the PO. This doesn’t have to be a fancy, well rehearsed presentation, but can be quick and dirty. The goal is twofold: share knowledge with the rest of the team, and assist the PO in making a decision on how to move forward.
• Don’t accept more than a few spikes in your sprint. A spike is a risk, and more spikes increase the risk of the sprint goal nog being achieved. You want to have a potentially shippable product at least at the end of the sprint — a sprint full of spikes does not achieve that.

Closure

Spikes can be dangerous things (you knew it was coming), but they also have their uses. A spike used in the right way is a good way to keep innovating and investigating into unsure areas of the product and the team. However, they can be easily manipulated into working around the rules we have set in place for a reason. So, what do you think about spikes? Have you used to poke a hole in a new technology or challenge in your team?

What did you think about my blog? Do you have any improvement suggestions or ideas or topics I should write about? Leave a comment or reach out to me on LinkedIn!