#RevTWIL: Spike Tickets

At Revelry, we believe in sharing and learning from one another (beliefs that are rooted in our Core Values). Among the many things we do to encourage internal knowledge exchange is to have a different team member present at each week’s Engineering Meeting. These presentations don’t have to be lengthy, formal, or complicated; in fact, many are brief, but also powerful in that they teach our Revelers something new, inspire conversation, and encourage collaboration.

In the spirit of sharing, we share our This Week I Learned presentations (aka RevTWILs”) here. We hope you find them helpful.

THIS WEEK: In a recent Engineering Meeting, our team discussed spike tickets, spurred in part by the fact that our software experts see them as essential, while some of our partners are skeptical of their value.

Spike vs Research

Spike: The purpose of a spike is to unlock a particular piece of work you know you want to do by rooting out the unknowns and documenting / estimating implementation issues. A spike is usually time-boxed, meaning the investigation is over when the time-box expires. This helps manage time and prevents endless digging without results. 

Research: Research is more open-ended and divergent than a spike. Research can be broad and focus on almost anything, for example, the collection of information on competing products. 

Why Spikes Are Necessary

Spikes prevent a task from stretching on and on, and can make it easier for stakeholders (partners) to understand progress, because they assure a written record of hurdles faced, lessons learned, and reasoning behind design / architecture decisions. 

How Can Spikes Go Wrong?

Our team shared lots of horror stories about spikes that didn’t go well, and we noticed a few patterns:

• Things can get unpleasant if the goals of the spike aren’t well-defined. The person working on it feels a bit adrift, and stakeholders can’t figure out what they’re up to or why. Sometimes a lack of clear goals leads to a blurring of the line between the spike and subsequent implementation, which can make it seem to observers like the spike didn’t do anything but slow things down.
• A spike can also lead to trouble if the team fails to define the amount of time it’s willing to spend to achieve the spike’s outcomes. As long as some timeline is defined, it gives the team a chance to regroup and make a plan, even if the spike’s objectives aren’t yet 100% met.
• If the goals of the spike are too lofty, the engineer can become overwhelmed by the pressure, and the lack of tangible progress can be frustrating for everybody. As with any kind of work, batching too much together also wastes valuable opportunities for feedback and course corrections around technical details, product planning, and priorities.

What Makes a Good Spike?

The keys to a good spike are to avoid the things that can go wrong. In essence, it’s about defining the scope and setting expectations about the investment involved:

• A strict time-box: It might be a day, a week, or a sprint. If it feels like it needs more time, think hard about breaking it up.
• A clear outcome:
  • An answer to a specific question or (small) set of questions
  • An architecture decision or recommendation (RFC / ADR)
  • One or more implementation issues with a specific AC
• A paper trail: The engineer working on the spike is going to learn a lot of things that will be valuable to the team as a whole. They have an obligation to share that knowledge so as not to become a silo of one.

Best Practices for Working a Spike

• If a spike is not well defined, the first order of business is to get clarity on time allocation, budget, and deliverables.
• Always produce the spike outcome before starting on the implementation.
  • It’s okay if you have to write some code to feel confident in your understanding of something, but you want to write as little as possible and be laser-focused on rooting out uncertainty. It’s throwaway code.
  • If we ship the implementation right out of the gate, it re-enforces the idea that spikes are unnecessary and short-circuits the planning and prioritization that may need to happen in light of the spike’s findings.
• Remember: We don’t have an inherent affection for spikes themselves. We’re merely trying to unblock the path to a particular piece of value for the partner, so focus efforts on that goal.

---

research RevTWIL spike