Stop Doing So Many Spikes - Mike Cohn

One of the more common mistakes I see teams make is relying too much on spikes. A spike is an activity a team performs to get smarter about something. With a spike, a team isn’t trying to immediately deliver a new capability; instead, they are building the knowledge that will allow them to deliver the new capability later.
Spikes are a great tool, and I’d expect every team to use them...but not on everything they work on.
The best use of a spike is to reduce excess uncertainty. This could be uncertainty about how a feature should work or about how it will be built.
A team may opt, for example, to spike the user interface for a particular feature. Or it may use a spike to determine if a technical approach is feasible or will perform at the required level.
Each of these can be a good use of a spike. The problem comes when a team wants to use a spike on everything. Spikes should be used only in cases of extreme or excessive amounts of uncertainty. Spikes should not be used to reduce the typical, garden-variety uncertainty that exists in all work.
Further, spikes should not be used to eliminate uncertainty. Teams need to be comfortable bringing work into their sprints or iterations with open issues remaining.
Is your team reluctant to allow work into a sprint with any remaining uncertainty? That’s sometimes the result of team members feeling excessive pressure to estimate perfectly, to always achieve the sprint goal, or to always deliver everything that they brought into a sprint.
If that is happening, a Scrum Master or coach needs to work with outside stakeholders or whomever is creating these unrealistic expectations. Sometimes it’s even the team members putting this pressure on themselves.
But what’s the problem with frequent spikes anyway? It’s that overuse of spikes extends your time to value. This is especially true when the spike is done in one iteration and the rest of the work in a subsequent iteration.
Overuse of spikes also reduces the extent to which teams overlap work. This can increase the burden on testers.
For example, consider the case of a programmer who uses a spike to reduce the uncertainty of a backlog item. If that item is brought into the next sprint, the programmer’s work has been made simpler by the spike, but the tester’s has not.
If your testers are struggling to keep current with the programmers, consider whether the team is doing too many spikes. It’s a good question to ask yourself even when the testers don’t seem overburdened, if you want to succeed with agile.

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/