I think Spikes are a very interesting topic to talk about. I have seen a lot of teams struggling with the concept, and potentially abusing the term. I want to write about Spikes, in order to try to clarify their meaning and give some examples of how spikes can be useful and how they may potentially be abused.
What is a spike?
What is a spike?
A spike is a time-boxed technical investigation / research undertaken by a single developer or the team in order to solve a specific problem. Spikes usually don't produce working output.
Spikes usually produce example code that is used to build the working output.
Etymology:
On The Agile Dictionary, there is a comment (3rd from the top when I'm writing this) :
Paul says:
My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.
I don't know how true this is, but I definitely like the analogy here.
Paul says:
My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.
I don't know how true this is, but I definitely like the analogy here.
Example use of a spike:
I recently built an app, which helps users prepare for DMV test. The app is pulls some data from my data source on the web, parses it and shows it to the user. When I started working on the app, I didn't know how to talk to a web data source from an Android app. I was stuck and needed a technical investigation -- a spike.
I used this spike to try to pull data from a test website. I didn't necessarily need the official app website for the spike, I could use any test data. My aim was to find an implementation that accepted a URL as input; and spit out the text from that URL. I decided to have a long time box, because my app update was intended for this activity. I couldn't proceed with any real development without this investigation.
When I was done with the spike, I didn't have a solution that I could simply copy-paste into the code for my app. Instead, I had an example which I could work off of.
Example abuse of a spike:
I used this spike to try to pull data from a test website. I didn't necessarily need the official app website for the spike, I could use any test data. My aim was to find an implementation that accepted a URL as input; and spit out the text from that URL. I decided to have a long time box, because my app update was intended for this activity. I couldn't proceed with any real development without this investigation.
When I was done with the spike, I didn't have a solution that I could simply copy-paste into the code for my app. Instead, I had an example which I could work off of.
Example abuse of a spike:
I can think about 2 specific examples where spikes are abused:
1. Spikes for accurate estimation: Spikes allow developers to familiarize themselves with the code. This can lead to more accurate estimation. If all your spikes are driven by a need to have accurate estimates, you need to question whether that is really needed.
If your team runs into issues where they aren't comfortable putting a number on a user story without first going through and knowing the design, I'd like to point you to my article on Story Estimation. I have mentioned a few things there which might be useful to you.
2. Spikes for requirement clarification: I have seen teams using spikes for clarifying the requirement(s). In this semantic change of 'Spike', a developer needs to put on a Product Owner hat to figure out the details of the "what?" and not the "how?". If your team is engaging in spikes because stories aren't clear, I'd encourage holding your Product Owner responsible for providing a reasonably clear stories, and a decent minimum viable feature set for the release.
1. Spikes for accurate estimation: Spikes allow developers to familiarize themselves with the code. This can lead to more accurate estimation. If all your spikes are driven by a need to have accurate estimates, you need to question whether that is really needed.
If your team runs into issues where they aren't comfortable putting a number on a user story without first going through and knowing the design, I'd like to point you to my article on Story Estimation. I have mentioned a few things there which might be useful to you.
2. Spikes for requirement clarification: I have seen teams using spikes for clarifying the requirement(s). In this semantic change of 'Spike', a developer needs to put on a Product Owner hat to figure out the details of the "what?" and not the "how?". If your team is engaging in spikes because stories aren't clear, I'd encourage holding your Product Owner responsible for providing a reasonably clear stories, and a decent minimum viable feature set for the release.
In conclusion, I'd encourage teams to:
1. Stick to the definition of the spike I mention here.
2. Take on Spikes only when they are necessary, not before that. You don't want spend time on a spike for a story that never sees light of the day.
3. Set a time-box for the spike.
At best, spikes are excellent tools for producing working solutions quickly. At worst, spikes can convert your Agile process into Waterfall.
1. Stick to the definition of the spike I mention here.
2. Take on Spikes only when they are necessary, not before that. You don't want spend time on a spike for a story that never sees light of the day.
3. Set a time-box for the spike.
At best, spikes are excellent tools for producing working solutions quickly. At worst, spikes can convert your Agile process into Waterfall.
| Rate this post! |
☆
|
☆
|
☆
|
☆
|
☆
|
No comments:
Post a Comment