The True Meaning of an Agile Spike
It may seem like I have been quiet lately, but in truth I have been doing quite a lot. It’s just the the “quite a lot” has not been directly contributing to my chapter word counts. Have you ever started something, thinking you had everything you needed to get going, but found out you didn’t? The best example I can think of is airport shopping. You pack your bags, you head to the airport, and while your boarding pass is still warm in your hands you have discovered items you need for your holiday. It’s not like they are things you have forgotten, like a toothbrush. These are items you suddenly realised you needed. Whether you really need them or not is a separate discussion that I’m sure my husband would be more than happy to contribute to. An Agile project can easily find itself “airport shopping”, because the project starts with just enough information to get started. As a result, it’s pretty normal to have to take some time to research something further, perhaps even prototype something, or to gain confidence in an approach. This is known as an Agile Spike. Having used this to a limited extent in my projects, I thought I understood it. It was not until I got halfway through Know your Risks, that I truly embraced the term Agile Spike. In fact, I think I was most of the way through it before I realised I was doing it.
Why use an Agile Spike?
An Agile Spike is a great strategy to employ if you need to take some time to do work that is not related directly to a user story or requirement. The work does not have clear acceptance criteria, or contribute to the team’s velocity, but is work that needs to be done. Its purpose could be:
- to reduce the risk of a particular approach chosen
- gain knowledge to increase certainty of approach chosen
- better understand an aspect of the approach or specific requirement
- to increase reliability of an initial estimate or plan
Great – time to relax?
I wish! In fact, I would argue you work harder during a spike, as you are so keen to get back on track. Obviously, because they do not contribute directly to the benefits, spikes should be used as little as possible. And once recognised, be included in the backlog so they can be tracked and measured. Before embarking on an Agile Spike, it needs to be planned and estimated for like any other story. It is recommended as a separate iteration as opposed to included within an existing iteration.
So my Agile Spike started when I was half way through writing Know your Risks. I found myself going down rabbit holes and realising I needed a bit more information to fully write the chapter. I also started to question the approach for the book. Was it right? Was I presenting the information and stories in a way that made sense? My problem was that I didn’t realise I was doing a spike until it was almost done.
Recognising the need for an Agile Spike may be as simple as noticing that the actual velocity is very different from planned – perhaps the estimates need to be revisited. It may be that the team are asking questions and realising the information needed to answer them is not close to hand. It may even be the team and stakeholders starting to doubt the approach. Anything like this must be addressed sooner rather than later, or what might have been a small, niggling thing will grow into an all-out infection.
I read that the term Agile Spike comes from Extreme Programming (XP) and the original metaphor was that of a rock climber – when the rock climber hammers in a spike, they are not actually climbing, but are doing something critical to the climb being successful. It got me thinking about other areas of life where we could apply this concept. In this world of constant “busy-ness”, we don’t often take time to ensure we are on the right track, with the right resources, doing the most important thing. And although taking time out could cause a delay, imagine the ultimate cost of not doing it?
