Somehow, sometime, the concept of a spike got introduced into agile practice and language. The general idea is this; we need to make a product change but aren’t quite sure what direction to take or how to find that direction in the first place. A spike is the black flag we raise to say we need time to work on something that isn’t _obviously_ productive. The end result should be information and a general idea of what we need to do next, not code and software in production.
The rules are simple, the implementation is not. What I usually see, is spikes that result in a day of reading API documentation. So, the question then, is when is it a good idea to spike something out and when might we be better served by digging into the work and learning from that experience?
My most recent encounter with the spike question was an authorization refactor. The product I was working on was using an antiquated form of authentication and authorization that stores files on the local computer, and relies on a separate server for managing user accounts. We had settled on a new library and authorization/authentication workflow, but hadn’t broken down the individual tasks we needed to get there.
A couple of people were arguing that we should do a day long spike. The result of that would be a developer reading through the chosen auth API, and stubbing out JIRA tickets for the work we would need to do to get from current user management to new user management. Another group (well, a developer and me) were lobbying for another approach. We wanted to start with the most obvious piece of work, getting a user to log in to the product with the new auth service, and work on that. The result of our idea would be users logging in with the new service, working knowledge of the new auth API, and more fully formed ideas about where we need to go for the next couple of changes at least.
Ultimately a manager chose to go with the spike. We read the API, created a bunch of very sparse cards that will have to be filled out later with implementation details and probably some sort of acceptance criteria. But, there was no functional changes.
I think spikes are good for open ended questions. For example, if we had 3 or 4 potential auth libraries to review and hadn’t settled on one yet, it would make sense to spend a day or two doing some exploration. The result of that would be settling on a library and knowing the path forward. Outside of that, I feel like spikes are a lot like estimation. They are an excuse to spend time researching and requirements gathering to help managers feel more comfortable with uncertainty.
There is uncertainty in every software project. We can take a small piece of work, learn from that, and figure out how to move forward based on real experience. Or, we can try to imagine what the work might look like, plan it out sometime in the future, realize that our plans are bad once we get into it, and then move forward based on real experience. Both paths have similar outcomes, one takes a little less time.