How We Used a Week of Spikes to Map Out a Feature

For those uninitiated to agile software development, “a spike solution is a very simple program to explore potential solutions” to a particularly challenging problem. This term and definition comes from XP Explained by Kent Beck, and it is still as relevant today as it ever was.

Spikes are incredibly useful for quickly iterating over many approaches before deciding on the plan of attack. I’ve spiked features out in the past, but never spent more than a day before getting started on the feature.

Recently, on a client project, we had a sprint where we didn’t have any pressing stories to deliver. So rather than digging deep into the backlog, the team decided to spend some time working on spikes for a sizable feature that we were about to start. I want to share my experience with this extended spike and a few things I learned from it.

The Problem

Although the problem we faced is quite interesting, I won’t go into detail. Instead, I’ll outline the general approach we took.

Set goals

• What we did: We took some time to outline our goals at the beginning of the sprint. This ensured that we were all on the same page throughout.
• What you can do: Try this out! Rather than just blindly charging into sprint work, as one tends to do, decide what you want to get out of it.

Create tasks

• What we did: We had a big goal, but we split it up into several smaller tasks, e.g. research X topic; get Y working in Z scenario. That meant when we finished with one task, we were able to move on to the next one quickly.
• What you can do: Take this in stride. Usually, a spike is for a smaller set of work, so this might not be necessary. If you do have a lot of work ahead of you, it could help to break things up into smaller tasks.

Don’t Reinvent the Wheel

• What we did: Although none of us knew the answer to the problem at the beginning, or exactly how we would solve it, we were all able to work together to figure things out. Our combined knowledge was much greater than our individual knowledge. Each of us was able to fill a hole in the collective “developer toolbox” that we shared.
• What you can do: Don’t be afraid to ask people questions when approaching challenging problems. Make sure that your developer toolbox is full, particularly with libraries and command-line utilities, as these tools can help you quickly get solutions in place without writing all of the code yourself.

Pair Program

• What we did: Pragmatic pairing. While we like to pair at Atomic, we also realize that some things aren’t suited for it. One example that comes to mind is reading documentation. We had to do a good amount of research and reading, but nobody likes to read at somebody else’s pace. Some tasks seemed like a good thing to pair on, but ended up not working well. Others initially looked like an individual could tackle them, but ended up taking a pair to figure out a solution.
• What you can do: If you don’t practice pair programming at work, I would encourage you to give it a try, especially when working on difficult problems. If you do pair though, be on the lookout for activities that don’t lend themselves to this approach.

Document Your Findings

• What we did: During the sprint, we took time to document our findings while things were fresh in our mind. In our case, this spike was for work several months out, so it was absolutely necessary to make sure that there was a permanent place for things that we learned.
• What you can do: Spikes tend to happen right before feature work starts, so documentation isn’t always necessary, but it certainly doesn’t hurt. Even writing a text document on your computer is better than nothing, but committing to a repo or adding to a wiki is preferable. Who knows, you might want to find an API, library, or code snippet at some point in the future, and it’s frustrating when you have to solve the same problem twice.

The Outcome

In less than a week of work, we were able to “de-risk” the majority of the upcoming work. We even had time to explore some other options to solve the problem. We felt confident creating and pointing stories in the backlog, as well as giving rough time estimates of the work required.

Next time you come across a challenging problem, consider if you should spike it out first, rather than diving headfirst into the problem. If you decide to go down the road of a spike, take some time to define goals, and decide if you need to shrink each task so you can be as efficient as possible.