Spikes: supporting agile practice

man rock climbing
Header photo by Jonathan Ouimet on Unsplash

The second supporting agile/XP practice that I want to explore is ‘spike solutions’ or simply ‘spikes’.

What is a spike?

The name ‘spike’ comes from rock climbing. A piton (sometimes called a pin or peg) is a metal spike or wedge that is hammered into a crack in the rock to act as an anchor to secure the rope. This protects the climber from the consequences of a fall and to assist progress. The spike itself doesn’t move the climber closer to the top but it helps provide a safe path to do so.

Similarly, in software development, spikes help developers determine a safe path forward when knowledge is lacking about how to do something.

A software spike is a technical investigation—a small experiment to research the answer to a specific problem about how to do something.

When is it appropriate to create a spike?

It can be helpful to think of spikes as a part of backlog refinement. The Scrum Guide sets aside 10% of a sprint to backlog refinement.

The purpose of backlog refinement is to remove uncertainty and create a common understanding among the team about the work required to build new features.

There are, generally speaking, three types of uncertainty around user stories:

  1. Why do we need to build this?
  2. What do we need to build?
  3. How can we build this?

The first two questions are the responsibility of the product owner and customer, the third can be answered only by the engineers.

By the end of refinement, each of these uncertainties should be answered. If the ‘how’ can’t be answered then a spike may be the way forward.

Spike solutions should be the exception not the rule. Don’t spike everything. It is natural that there may be some uncertainty when estimating user stories but often these will be uncovered as you dig into a user story. The DSDM agile project management framework is quite explicit about this: the development phase is called ‘exploration and engineering’ because it recognises that there will always be an initial exploratory element to any development.

Guidelines when creating a spike

1. Timebox spikes Do not score a spike using story points. Instead, simply timebox it. The tasks team currently timeboxes spikes to two days.

2. Set SMART objectives A spike should have one explicit question to answer. It can be helpful to set a SMART (specific, measurable, achievable, relevant and time-bound) objective to ensure this.

3. Know who is accountable Once an answer to the question posed by the spike is known, it should be clear who should be told, in order to further refine the user story the spike emerged from.

4. Schedule spikes ASAP Spikes represent uncertainty and risk. Therefore, they should be scheduled as soon as possible to eliminate or reduce that risk.

5. Don’t pair programme There is no need to pair programme when investigating spikes. But you can make it fun by splitting pairs so one investigates the technology while the other codes. Or create a bit of friendly competition to see who can discover the answer first—then demo to one another what you’d learned. Or agree to try two different approaches simultaneously.

6. Spikes should be demonstrable Ideally, the spike should be demoed to the rest of the development team. Remember, if spikes are a part of refinement, part of the goal of refinement is to create a common understanding.

7. Spikes should be disposable Spikes are short experiments to find a specific answer. Do not waste time creating production-quality code. Write code that you know will be disposed of: run it from a command-line if need-be, ignore user input, hard-code values. Do everything you can to find the answer you need as quickly and accurately as possible. Then, in the tradition of Marie Kondo, thank it and discard it.

What if you don’t get an answer?

If by the end of the spike timebox you cannot answer the specific question that was posed in the spike definition that’s fine. You will have learned something; you will have more information than you had before the spike began, even if that is knowing how not to do it. It gives the customer and/or product owner more information—maybe it doesn’t offer the value that was initially assumed and needs to be reprioritised.

My experience of spikes

In 2015, the week before Christmas, my team had some relative downtime: business as usual work had slowed down, as had project work. For a while, we’d had an idea that we could simplify and speed up the Node.js application that was generating both our digital pattern library and accompanying documentation. It had been built by a developer who had since left the University and we didn’t fully understand how the technology worked. So, we decided to run a spike to investigate whether it was possible to do it another way.

Duncan and I decided to set aside three days to work on it. We stood in front of the whiteboard and agreed on our understanding of the problem and how we thought fixing it should be possible. Then we returned to our own PCs to work on it separately. “Gentlemen, start your engines!” We read the online documentation, we created new branches in GitHub, generated a new test pattern and got to work.

There was an excited sense of competition; not least because Duncan had a degree in computer science and I didn’t. We’d try things out and share the results. We quickly hacked at the code to see if this or that approach worked. It didn’t. Time and again we tried something, it failed and we’d roll back the code. We chatted to one another. “I’m going to try this approach…”, “That last way of doing it didn’t work. But I’ve found a useful thread on Stack Overflow”. Each failure was a step in the right direction.

On day three, I tried something—a variation of an approach I’d been working on.

It worked.

I ran it again to be sure.

“I’ve done it!” I exclaimed. I’d managed to get the build time down from about 45 seconds to 15, reduced the amount of code required to define each pattern and simplified the model.

Duncan came rushing over to my desk and I walked him through it. Together we sat at my desk and pair programmed to clean up the code and make it production-ready. Then individually, we split up the workload and converted the whole pattern library to our new approach.

I have a fondness for spike solutions when they are required.

Originally published on my work internal blog.

Published by

Gareth Saunders

I’m Gareth J M Saunders, 52 years old, 6′ 4″, father of 3 boys (including twins). Enneagram type FOUR and introvert (INFP), I am a non-stipendiary priest in the Scottish Episcopal Church, I sing with the NYCGB alumni choir, play guitar, play mahjong, write, draw and laugh… Scrum master at Safeguard Global; latterly at Sky and Vision/Cegedim. Former web architect and agile project manager at the University of St Andrews and previously warden at Agnes Blackadder Hall.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.