The Spice of Spike in the Agile World
The Spice of Spike in the Agile World
Read on to see how one developer learned to spike the punch and spice up the Agile development process with the rarely talked about technique.
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
In my early days as a Scrum Master, I noticed a new story being added overnight by my onshore counterpart. I asked., 'what is it,' and he said 'this is a Spike.'
Spike of what?
He said, 'this is different than a story, don't go by the JIRA icon.'
'Consider it like a new work in this Sprint, kinda PoC.'
But, dude, we are already struggling to meet the timeline for those in hand, would we get a story point to its credit?
'No you won't.'
I was left distraught.
The Spike character sounded much like the Kraken from one of the Pirates of Caribbean movies, who all of a sudden appeared to tell us, 'you got to deal with me first,' interrupting the Sprint journey.
Well, that was my first face-off with Spike and the time I started exploring the spice that the Spike adds to the overall flavor of Agile delivery.
XP Thing Invented by Gurus
XP guru Ward Cunningham would ask Kent Beck (another Guru known for his TDD advocacy) - 'what is the simplest thing we can program that will convince us we are on the right track?’ He was referring to a very simple program to explore potential solutions. Kent named it a 'Spike.' They first presented an example of it at the OOPLA '97 conference.
Spice Factor: Why is it named 'Spike'? - Spike was seen as a vertical probe from top to bottom for the smallest unit of work to get the crux of the problem and then develop solutions around it - much like adding a field in the database and then in UI to see if it is passing through first, and then adding more fields. So Spike is 'end to end, but very thin,' like driving a spike all the way through a log, as the Gurus indicated in their official blog.
Definition and Adoption by Bodies of Knowledge
Scrum.org and Scrum Alliance don't have any official version of Spike in their guide or curriculum. PMI-ACP doesn't have any Agile BOK altogether unlike PMBOK.
Agile business consortium (DSDM 2014 onwards) doesn't have any mention of it either. Jeff De Luca's original FDD work also doesn't refer to Spike, or something similar, anywhere.
However, Scaled Agile defines it as a 'type of exploration enabler story in SAFe, used for activities such as research, design, investigation, exploration, and prototyping.'
Spice Factor: Spike has an underlying acceptance by all BOK's - irrespective of formal acknowledgment or not; it is referred to by all BOK's in some form or another.
PMI-ACP prescribes Spike in the exam content outline.
Scrum Alliance has publications by some authors on its website highlighting the wider use of Spike.
Scrum.org asks questions about Spike in its certification exams as it is an important part of the open assessments.
DSDM 2008 version had referred to it as an architectural Spike for prototyping.
Lifeline of Spike - Timeboxing It!
From minutes to hours to the full duration of a Sprint or beyond - how long should a Spike run? There are different opinions: Mike Cohn at Mountain Goat Software suggests that a Spike should be time-boxed based on the product owner's willingness to invest in it or a team's decision to yield results from it.
Todd A. Jacobs at Code Gnome advocates that the maximum duration of the Spike should be up to the full Sprint. Andrew Fuqua at Leading Agile terms Spike as a potential risk in the backlog so it should be quickly resolved, preferably within 1- 3 days.
Spice Factor: The official blog, C2 wiki, mentions a quote by Kent Beck: 'Spikes are good when you are knowledge-limited, not time-limited.' So there is no prescribed time boxing - rather it is strictly a prerogative of teams and their PO.
Usage and Interpretation in the Real World
The situation I mentioned in the beginning - that a Spike was added by the onshore team - was to develop a reference data algorithm as the normal SQL was not responding well. After some research, the team found a piece of code which, with some customization, did the trick! A technical Spike.
The other Spike we had was to simulate the integration of existing SSO with the newly developed portal and observe how it responded to the simplest user access. It later helped us to complete the actual integration with minimal issues - a functional Spike.
There are references of infrastructural Spikes available which are raised to ensure smooth CI/CD experiences.
Spike is largely seen as a serious exercise to help stories in discovering the unknowns, mitigating the risks of failures, proving the feasibility of a solution, and arriving at estimations. Not every story could have an overhead of Spike, so Spikes are cautiously raised.
Spice Factor: A Spike solution may not be directly implemented in stories 'as is' and some Spikes, even, may not yield the desired results and are thus thrown away at the end.
Counted in Velocity or Not?
For our Spike, we didn't estimate the story points and still delivered the committed stories but then the team had to stretch to compensate for the Spike; we wished it could have been counted even if the velocity is inflated at times. We thought so for two reasons:
Considerable efforts were put into the Spike and we certainly wanted to highlight it.
Had we not stretched for the Spike and had compromised on stories, it would have negatively skewed the velocity. Stretching is not always possible and more Spikes would mean badly skewed velocity.
We were advised not to estimate spikes based on the following assumptions:
Spikes have no direct value but rather are potential solutions for stories and are meant to be thrown away as the actual deliverables are stories.
Spikes generate a sense of urgency being identified as risk items, so it's better to have these quickly resolved than to estimate and count in velocity.
Estimate or not depends primarily on the prescribed Agile delivery model and then on the team's willingness to set-it-up knowing the pros and cons.
Spice Factor: While the stories do have functionality up for demo and are counted towards velocity, the demo of spike limits mostly to indicate whether its results are accepted or not, irrespective of it being counted in velocity or not!
What appeared, initially, to be an uninvited blocker in the progress of the Sprint, was discovered to be an interesting and valuable enabler for Agile delivery.
So next time you see a set of problematic stories, Spike through it for a solution and then keep SPIKING!
Published at DZone with permission of Ajeet Singh . See the original article here.
Opinions expressed by DZone contributors are their own.