How Spiking Got Me Thinking
The other day, one of my teams was talking about “spiking” in some work in the current sprint backlog, and a relatively new member asked me about what we meant by the term. I explained that we were using it as a delineation between a) work that, due to emergencies, a product owner might be forced to trade in–pushing other work out, and b) work that the team would accept as additional to the sprint backlog without removing work.
As the words were leaving my mouth, something felt wrong. That got me to thinking about how far from XP I’ve drifted with that term–“Spike.” I remember when I first learned the term–in a workshop with Doug DeCarlo, and I thought how smart it seemed; as I understood it a spike of work was additional work that the team would engage in to try and come up with a solution to an existing problem in the sprint–i.e. additional work–usually technical–that helps us solve a problem. That kind of “let’s look at this from another angle” thinking is one of XPs cool contributions to development. I thought it was one of the most interesting and clever things I had heard of, and it reminded me of something carpenters do on a regular basis.
In carpentry, the analog would be the preparation for building a roof and realizing you need to build a template or jig to both speed up your work and to prove out some assumptions about how the truss might need to be put together. It’s extra work that will not be part of the building when it’s finished, but it helped you work smarter, not harder. All self-built woodworking jigs, for that matter, fit this analogy.
But here I am, about five years after learning the term, Spike, and I’m realizing that I’ve slowly but surely drifted away from the original spirit of the term, and now I’m bastardizing it pretty thoroughly. To make matters worse, I’m coaching others to understand that that my modified definition is the correct use of the term–and doing it with an authoritative tone.
What in the heck happened? Call it ScrumMaster reality drift–the slow, incremental change in meaningand practices due to the milieu in which one finds oneself coaching agile. Yikes! That sounds like the first step on the way to “Scrum-but.” (i.e. “We’re doing scrum, but. . . . “)
I’ll ask this–What should we call this action–the act of the team pulling work in to the sprint backlog as emergency work and without removing other work (because they feel they can absorb it)?
In the team’s defence, this is not a regular occurrence, and it is not taken lightly. It hurts, and the product owners and Business BAs know it and feel it. When pulling the work in, the team addresses the risks, and often identifies ways to mitigate that risk. Our Business BAs are good about identifying work that could be pulled out if we find ourselves up against the wall near the end of the sprint.
|Scrum team vs emergencies|
In short, I feel the teams are handling these emergencies well and upholding Agile values in the process.
Maybe we should call them EXACTLY what they are–“deliverable spikes” or “hotfix spikes.” That distinguishes them from “Coding spikes” or “solution spikes.”
Yeah–that’ll be my recommendation–names long enough to be accurate but short enough to not wear the listener out. I’ll let the teams talk through this one. I’m really looking forward to the next round of retrospectives.
Side bar on terminology.
Here’s my thinking: All too often in software development . . . well heck, in any discipline,. . . it seems like we try to shorten expressions to the detriment of clarity. It’s one of my biggest peeves (no, it’s not even a “pet.” I hate it that much.) “Spike” isn’t one of those terms, but reiterating the intent with something like “Solution Spike” helps maintain the durability of the expression’s meaning. Why don’t we do that more? Be clear.
If we were to create a scale of obfuscation, with brevity on the right and verbosity on the left, the TLA (three letter acronym) is on the extreme right of that scale–often confusing people or being just plain asinine–I’m looking at you Scaled Agile Framework. On the extreme left is business jargon, legalese,and every French literary critic prior to 1994 (I haven’t read any since then–they may still be at it).
The motivations behind developing “Tribal languages” is well studied. Linguists, cultural anthropologists, sociologists and MBAs revel in it, and one of the reasons that is often given is a sort of self-preservation. People make their work sound more obscure, so they’ll feel smarter, more special, more secure in their
jobs. What bugs me so much about that thinking is that it seems to condone the behavior. “It’s just the way we are.” Well, if we know we are doing something wrong, why in the heck don’t we fix it? Surely we can find something somewhere in between. We’re software development. Let’s create a solution spike and come up with a better way to communicate..