Oct 10

The horror of team spike

Spike. Sometimes I wish the word didn’t exist. In al the teams I introduced this little word, they immediately misused it to hide their uncertainty. To avoid that this happens to your team, let me explain what a spike is. And when you know, how to avoid that it becomes your main impediment.

A spike is a venture into the unknown. When a team needs to build something but they absolutely do not know how, you can introduce a spike. They can explore how they can do something. For example, a team needs to build something with a new CMS but they have no idea how the CMS works or how it is implemented. Then they need to dedicate some time to find out how it works. When they need to read a book about it or to go to a training  a spike can take a while but I’ll come back to that. In other occasions a spike can be a small investigation into how something needs to connect with something that is outside the grasp of the team. Before they can start working on the actual software, they need to find out how the other side works. They pinpoint a small look into the future, a spike so to say.

But then where do thing go wrong? As I said with almost every team, as soon as I introduce the spike as a possibility to use for small investigation, they immediately shove everything that they think is difficult under it. Hell, we had a team that got the nickname “team spike”. This team was doing research for two to three sprints. A couple of day’s ago the term “Spike Sprint” was mentioned in a meeting and then I decided to step up and nip it in the bud. Off course it is scary for a team to venture into the unknown when a new projects starts or when new user stories emerge that they haven’t got a clue about how they are going to solve. But as soon as they start hiding behind spikes you know that it will go into the wrong direction. I have seen sprint backlogs with post-it that only had the word spike on it. Not estimated and they lasted for what it seems, ages.

So how to handle spikes. A Spike is
 an exceptional way of working when the team has the feeling they don’t have enough
 information to give the product owner expectations that are realistic. A Spike is to establish those expectations.” But a spike is also temporary and the results are intended to be thrown away.

Spikes are great for teams to figure out stuff that they don’t know how to handle and need to know so they can estimate the complexity or to just find out if something is technically possible or not.

To keep them under control agree upon that a spike can take no longer then four hours and needs to have an end result. And in my personal touch. No more then two are allowed in a sprint of 10 days (two weeks). Don’t allow teams to go and run wild with this. I often say to developers that it is impossible to program something bad. In the worst case they end up with something that is not the right solution. So either learn from that and throw away, or use and change. But do work instead of pondering for a long time in how you are going to do the work.

When a team or individual team members need more time to go on a training or read about things in order to learn, then dedicate time for it and send them on to that training. But don’t use a sprint for that. Because before you know it you might end up with the “Spike training sprint” or something. And believe me, you don’t want to go there.



Permanente koppeling naar dit artikel: http://agilethings.nl/the-horror-of-team-spike/