Spikes - Discovering Worlds

It is common that developers are always facing new challenges, many of them are small or affordable and someone has already solved a similar problem in the team or in the Internet. Other times they are facing completely new developments and they have no idea of to deal with these.

The risk can be very large and the time to implement the new requirement could take some days or even years. After coding the requirement, if they can, developers have to test how the entire system is working and whether the expectations are met. Nothing seems clear and is hard to see land in the sea. It is necessary to do something more before to estimate the difficulty and time to implement the requirement.

Spikes

Spikes are an invention of the software methodology Extreme Programming (XP), Spike is to develop an implementation of something related to a potential requirement. Why is it necessary to make a Spike before a requirement?

Spikes are useful when the requirement is to make an architectural change, proof a new technology, add a big feature or change a current implementation and check if that is possible, it is also useful to knows better the time it will take the development, how the implementation is affected, and check if the functionalities will have the expected behavior. Definitely, the requirement is very immature and needs some work to become a requirement with approach achievable.

Moreover, they are used for research, design, prototyped, or increase the knowledge and reduce the risk of a technical scope. Also, a Spike can be estimated.

Spikes emerging

All requirements have to build risk functionality, this unknown information can be discovered while the requirement is being constructed, in a team conversation, using the criteria of the developer, discussing, collaborating, negotiating, etc. The team determines to do a Spike when the risk is high or they really need to know more about a requirement that may be very big. Using Spikes the team will get the information with convincing data, then team members can see and take better decisions.

When the team or the Product Owner determines that they have to make a Spike, this can be estimated and prioritized as other requirements. The greatest value of a Spike is the information obtained, not the code developed.

How to aboard a Spike

The recommendation is to implement a spike with a small program. It is important to research and read, but even more important write code to experiment, not only theory. The complexity should be ignore, just have to focus on getting something working, no matter if the code is not reusable because this is an experiment. Document and display the results to colleagues is essential. Avoid the production code when it is possible, if not, only go ahead and do not commit anything.

In a Spike, developers can not go deeply in the beginning because these Spikes are not well defined. Who is researching on that mist can be lost in the sea of information or trying to do many things at once. Also it is important to have in mind that Spikes don't deliver value to the user directly, hence they must be used with precaution.

Finally, Spikes can be useful sometimes, but the most of the requirements do not need to use this kind of development. It is important to take a while to decide whether is needed a Spike and this time to think may be critical in many cases for the project's future.