Spikes are a type of exploration Enabler Story. Defined initially in Extreme Programming (XP), they represent activities such as research, design, investigation, exploration, and prototyping. Their purpose is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate. Spikes involve creating a small program, research activity, or test that demonstrates some aspect of new functionality.

― © Scaled Agile, Inc.

There is no prescriptive process per se for spike activity, compared to development activity, due to the fact that we are obviously dealing with the unknown or at least the not that much marked trail. This said, we can sequence activity into stages and agree upon some best practices for each of them.

We assume that we leverage GitHub ecosystem which seems to be a proper default nowadays.

Identifying

This stage is highly recommended to be fulfilled prior to the spike to effectively start, and not as the first task or user story of said spike.

Spiking is inherently a time limited activity as idea is not to engage into endless prototyping. Prior to engage, it is important to define:

• the scope
• logistics (resources & time)
• the expected outcomes
• the stakeholders
• the review process

First and foremost, you need a dedicated and collaborative workspace to exercise, discuss and make decisions regarding the topic. We advocate to create a dedicated GitHub repository to operate:

• providing meaningful name & description.
• leveraging topics, especially spike one to ease repository exploration
• ensuring every stakeholders have full access (we recommend either maintain or admin roles)

Repository will act during spike lifetime as the only source of truth, meaning one should at least find:

• README.md introducing spike context and goal, and specifying limitations if any
• C4 model related to said spike to materialize issue and layer
• Clear rules on how to contribute to this initiative in CONTRIBUTING.md, especially specifying uncommon ways of doing, or strong requirements.
• One dedicated discussion per expected outcome. Feel free to use labels for better segmentation. Discussion thread will be used to track exchanges and decision making.

Prototyping

Now that we have a dedicated workspace properly setup, we can engage. Some tips and tricks:

• Apply the best practices you are used to, sticking to limitations that may have been defined in CONTRIBUTING.md.
• Spike is inherently software development. You can loosen some rules, but you are not allowed to throw them all away.
• Scope and stage your developement.
• Introduce third-party framework or external code base only if they speed up and clarify topic, and ensure you keep them apart.
• Tidy up workspace.
• Apply coding best practices, rules and software design pattern.
• Consider using unit tests for the spike exploration rather than executable demonstrator.

Most of the time, spike involves 3 pieces:

• the unknown stuff this spike is all about
• the world you come from, with its own rules and context
• the bridge you will have to craft to team up both

The one you have to start with is obviously the unknown. Take time to understand the theory behind the new pattern, framework or paradigm you want to use. Then, take time for hands-on and exercise it. Once done, describe the gap between what you discover and the world you came from. And write down ways you can bridge both of them. Eventually, give a try and make decision regarding the best way to move forward.

This part is very important as it is not the way we are used to. Imagine a case where we have a legacy application that only uses file-based storage. We now want to evolve towards a database storage. Most of the developers will likely start spiking by introducing a storage interface, likely falling into header interface anti-pattern, then migrating current code base into specific implementation, probably provisioning a database placeholder implementation, and so on. Such investment for useless outcome… Good way of processing such a requirement is to ensure we are comfortable with database paradigm first, then analysing what it implies to introduce it in our context. Not the other way around.

Discussing

It is important to discuss with peers and take actions on a regular basis. Keep in mind that when you explore new areas, failures and successes are equally important and must be tracked accordingly. Take time to daily write down your discoveries, experiences and outcomes instead of waiting last day to do so. And share them. Often. You have no time neither getting lost nor going the wrong way. Remember spike comes from Agile realm. So, basically, iterate. Even faster you are used to. Spikes is more likely to be a few days effort than a couple of weeks sprint. Feel free to use issue thread and PR mechanism to stage your contributions.

Formalizing

Spike validation involve its own set of artifacts (documentation, ADR, snippets, … ). Keep in mind this is crucial to help team sizing the industrialization phase. Think about the best way to communicate outcomes to external people who weren’t involve, e.g.,:

• If you introduce new paradigms, provide snippets to streamline integration and unit tests to show case usage
• If you switch from old ways to new ones, consider having some markdown diff snippets or different branches one can easily compare
• Do not underestimate popularisation phase and leverage diagramming to smooth entry point

As stated before, failures and successes are equally important. Sometimes you will neither deliver code nor on the shelf solution. In that case do not consider spike as useless. Time spent and aggregated experience improve your knowledge. And this feedback is extremely valuable. Take time to properly shape this content. Failures deserve same exposure than successes, sometimes even more. Some spikes are more about knowledge discovery rather than code delivery.

Broadcasting

Now that you have shaped spike artifacts, it is time to agree upon how they will be communicated more broadly. This includes determining who will communicate, to whom, how, and when. Spikes may imply the need to refine or complete the backlog, train teams, or acquire new resources. Whatever the broadcasting stage consists of, make sure that someone among the stakeholders takes ownership of the follow-up.