Etiqueta: spike solution

When teams want to build new features in a software, what do they do?

Well, some teams I know, they plan. They build a big plan. BIG means at least 50 pages of non-structured text and diagrams that don’t say nothing about the real problem. And they do meetings!
After two months, they have a document baseline. And now, they can start design phase.

That’s no good!

We are living a time where delivery is not even important. Delivering new and valued features is a must.
We need to move faster. We need to understand risks.

We need to find as soon as possible if we are moving in a wrong direction.

So… we can choose the way we move!

There’s a technique / practice in eXtreme Programming called Spike Solution.

Spike solutions are used to understand a problem. They are used to help teams in estimation. You do spikes to know if something is huge, or if it’s a problem easy to solve.

Bottom line: You do spike solutions to learn faster about something.

So, if you are planning to do a new feature for your software, you have to do spikes. Together with spiking, do drawings to understand connections, to figure out more about user needs, do paper prototyping! Also minimize risks and understand non functional requirements.

How much time do you have for a spike? I would say no more than 4 cycles of pomodoros, or songdoros if you like the technique. By a cycle I mean four 25min focus +5min resting cycle and an extra 30min cycle after that. If we transform that in time, that’s no more than 10 hours of research. That’s actually 8 hours based on pomodoros + 2 hours resting giving space to your brain to mix current learning with what you already know.

Give it a try and help your team to find results faster. Don’t forget to document your findings and transform your spike at least in knowledge. At best in the beginning of a new feature! Enjoy!