Sep
12
It’s interesting to me that after years of working with teams on Scrum adoption, I see some of the same patterns repeatedly. One of those is what I call “Spike Abuse.” Let’s start with what a spike is, then we can talk about how they get misused by some teams.
The Agile Dictionary defines a spike as “A story or task aimed at answering a question or gathering information, rather than at producing shippable product.” Said another way, it’s a story that results in knowledge (and sometimes other user stories), not in working software. Since our primary measure of progress in a project is working software, we should minimize the number of spikes we use. Sometimes however spikes get pressed into service in ways they shouldn’t be.
The most common case of spike abuse is using them to “artificially” increase the duration of a sprint. Teams that are used to working in waterfall-ish ways, and that aren’t really interested in changing the ways they work will sometimes use spikes as the equivalent of “analysis” activities for functionality. They will argue that they are answering a question, the question being “what’s the design for this feature.” What’s really going on however is we’re making our sprints longer without saying that’s what we are doing.
Limiting a sprint’s duration, and forcing work to be demonstrable at the end of the sprint is a forcing function, intended to both make us reduce the size of our user stories (or whatever else is in your backlog) and ultimately to force us to sequence our work differently. It’s intended to reduce the lead time from when we agree “this is the most important thing to work on next” until we can start using that thing. If we increase that lead time by using spikes as a replacement for analysis and design, then have a “regular” user story to do development and testing we defeat the purpose, and our sprint is really longer than we say it is. We should be making our user stories smaller, and including all the activities we need in that story, not creating spikes to do part of the work.
How can we spot spike abuse? One of the first signs is that spikes turn up in your backlog regularly. In my experience teams that are using spikes correctly will have only a few spikes, well less than 5% of their stories as spikes. This will of course be project-dependent, but if your teams have more than a couple of spikes in their backlog, start looking further.
I like to have acceptance criteria for spikes (or desired outcomes at least) for spikes, just like for user stories. Ask your team what comes out of the spike, and if the answer is “a design” for anything, then chances are excellent you have spike abuse going on.
Ultimately, a team that is abusing spikes needs to be confronted, and the behavior addressed. A healthy Scrum team will recognize the critique and hopefully adapt their behavior. A team that is going through the motions will be less receptive, and may require more work to correct.
Comments
Comments »
Blogroll
- Ars Technica
- Dark Reading - IT Security
- Help Net Security
- InformIT
- SANS Internet Storm Center
- Schneier on Security - Dr. Bruce Schieier’s blog
- Security Info Watch
- What to Fix - Daniel Markham, fellow consultant
- Wired Gadget Lab
- Wordpress Documentation
- WordPress Planet
- Wordpress Support Forum
No comments yet.