Spikes

Rory Hanratty
Kainos
Published in
4 min readApr 24, 2017

As I mentioned in my estimation article, when dealing with uncertainty one approach is to play a Spike to get clarity.

In this article I’ll go into a bit more detail and offer an approach you may find useful.

As an aside, don’t worry about the origin of the phrase, it’s a subject of speculation, but it’s mostly attributed to Kent Beck.

What is a Spike?

Simply, it is work you do to learn something. An investigation to turn the unknown into something a bit more known.

You could go on ahead and put on your +10 boots of future seeing, or get out your tech divining rod and just go ahead and implement stuff.

You might get lucky and pull it off.

You might not. Like that time I tried to build a shelf out of reclaimed wood from a bed frame.

Oh, and masonry nails.

I mean, I assumed that the components of wood, nails and a hammer would fit the bill, and really how hard could it be to build some shelves? Lots hard when you’ve not tested any of your assumptions I can tell you.

When to play a spike

Anywhere it looks like you are going to expend significant effort, or if you really don’t know enough about it, this is where a Spike can help. I’ll outline some cases below.

(OH SNAP! Dragons!! Boat references indicate size.)

Using a new Architectural approach? Spike.

Thinking about using lambda? Sure, the online documentation looks good, someone did a crazy proof of concept to generate dystopian banking futures (code here). This may not however fit your context.

Deciding which framework to use for a new service? Spike.

Meteor.js vs Express.js they are totally different frameworks, but you have some user needs, some awesome product ideas, which one actually fits your use case?

Introducing a third party component? Spike.

Documentation for a product sounds good, have you tried deploying it though? Is it easy to upgrade? Can the other components integrate with it easily?

Facing off against a horde of vampires in a weird town in the middle of nowhere? Spike.

Sorry. Ignore that one.

Preparing for the spike

So hopefully you have an idea of what a Spike is and when you might play one. The next thing to do is prepare properly. Don’t just pluck a question from the air and go to work for [generic long period of time].

You need to agree up front with your team what it is you are hoping to achieve. Here’s a useful format I’ve used in the past to guide things.

What

A description of the work you intend to do, an outline of the scope, also include things you wont be doing.

Why

The reason this work is being undertaken. What is the value of doing this. This is very important.

Questions

What significant questions need to be answered by this spike.

Outcome

Very clear statement on what you want to achieve by the end of the spike. It may simply be an answer to the questions, it may be a statement that further investigation is needed, or perhaps a yes/no on whether something is possible.

Let’s do this!

Preparation done, questions ready, outcome clear, add it as a story to the backlog, prioritise it, and once it reaches the top, time to do some work…

Start off with a proper kickoff for the work, get everyone interested involved in the discussion, run through the what, why, questions and make sure everyone understands the outcome.

Having proper representation from Product and Tech is essential, both parties need to understand the value of the work.

Regularly check in on progress and set a time limit, a couple of days is sensible.

Try your best to summarise the work as you go, detailing what you have tried, what the result was, and how it goes towards answering the question. This is a useful discipline to get into, as it can act as a clear explanation to future versions of yourself as to why you made a decision.

Lastly, feel free to abandon a Spike at the earliest opportunity if it is apparent it is totally impossible to achieve the outcome you wanted.

Finishing a Spike

Once you are done, transfer your summary somewhere you can publish it.

I recommend an Open Design Proposal, or Architectural Decision Record.

That’s it. Now you know a little bit more, you can proceed on firmer ground.

An Example

So what does good look like? Here’s an example of one of the Spikes one of our teams did…

https://hackmd.io/s/HyWJoUsRe

--

--

Rory Hanratty
Kainos
Editor for

Belfast. Architect, developer, electronic music maker, husband to an awesome wife, father to 3 crazy children. Previosuly @gdsteam and now @KainosSoftware.