Why Agile Spikes Are a Good Thing
Reading time: 3 minute(s) - 600 words
In the perfect world, website project planning covers every element. The reality is different.
An agile spike is where you need to write some thinking code to figure something out.
It’s where you don’t know how to code something - but you have an idea.
So, you code it, try it and fix it when it breaks. Then, you get a solution.
The problem is: there’s the expectation that the associated user story will be assessed and estimated like all the others.
The truth is: not every user story is that simple. A time-boxed investigation is needed to see what is possible.
All that experimentation causes a bump in the project timeline. A necessary bump. And the bump is what some people refer to as an agile spike.
In a digital agency environment work comes in either as a project or as a bug fix/feature request.
New projects will result in the creation of a written functional specification. There will have been many meetings with the client too, of course.
In the end the question will come around to how long the project will take. The main features will happen in sprints or other units of work - usually with accuracy. The problem comes when time estimates need code first, to figure out how something might work.
This scenario is Agile spike territory. The idea is: you write the simplest code you can to achieve certain functionality. It helps to confirm that you are on the track when coding a solution.
It might be necessary to code several versions to figure out what’s best. That work creates a spike in the timeline of the project. But it usually results in a more elegant solution for issue in hand.
I’ve seen this happen for feature requests in legacy projects too. You might not have the developers around who created the code in the first place. So the current development team is blind to both the project and what adding the new feature will be like.
Development time will first cover getting the project up and running. Then, developers will write code to try out a solution. That process is likely to repeat until a working solution appears.
The key thing here is: the user story needs as much information as possible. That way, you can plan timings with confidence.
Where you need to try some stuff first, that’s a spike. It’s not about producing a shippable product at that point. And that’s the thing, you have to learn to accept the spike.
Because if you fight it, you’ll end up needing more time to fix the issue anyway.
The problem in the agency environment is worse. That’s because the spike is likely to be chargeable time. Except you are creating chargeable time for coding that is experimental.
Developers need to develop a working solution. And whether that’s done in an hour or five hours will depend on the complexity of the issue.
There’s the bottom line: spikes are necessary and not a bad thing. It gives developers chance to figure something out that might cause issues. And the deeper into the project you get, the more expensive that ends up being.
Learn to love your spikes.