Getting the Outcomes You Want From Technical Spikes

“Are these volleyball games or demos?” the senior director leaned over to me and asked during the 7 team demo of the day. She had just taken over this part of the organization, and I was the technical consultant tasked with making her dreams come true: working-tested product in the demo.

Yet another team had been remarkably busy in the last sprint discussing ways to potentially solve problems. The entire last 2 weeks were spent strategizing on innovative ways to implement this web-based crud app, and the team’s next sprint was scheduled to test out some of the more innovative methodologies using more “spikes.” Zero product was delivered, not even one commit was pulled into the trunk during the entire sprint. Product was not scheduled to be delivered in the next sprint.

From the director’s remarks, I took my newfound permission and started asking questions, “What spike seemed the most promising?” and I followed with “Could we take that idea and build a small slice of working tested software in the next 24 hours and reconvene?” and that is what the team did. Later that day, an email came out directing all teams to stop spiking in the backlog and instead spend time planning and writing code to prove out new methodologies in time-boxes with readouts, focusing on delivering working-tested product at each sprint demo.

But this is not just limited to the team space, a few years ago. Rich, Stephen, and I were facilitating and finalizing another great architecture debate. Two software architects were debating the merits of their proposed design patterns for the new product. It was complete with PowerPoints, blog posts, whiteboards, actual offsite training, logical arguments, hurt feelings, and glaringly absent working tested software.

Eventually, with the permission of the CTO, we metaphorically locked the architects in a hotel conference room with a laptop and forced them to build a proof of concept in a timebox fashion which resulted in a decision to retain the status quo methodology. It was debatable if working-tested software that could potentially result in a product was written in that room.

The sole outcome of a technical spike is to learn if we can accomplish building working-tested product using the proposed methodology within a time-box. It is not a research paper. It is not PowerPoint. It is an attempt to build working-tested product within some constraints. It should result in a source control commit.

Rephrased because this is incredibly important, the outcome of a Technical Spike is working tested product focused on understanding what is needed to make working-tested product or understanding why a methodology should be abandoned. These findings are then peer-reviewed by an entire team conversation discussing the merits of each. Everything else is most likely a waste.

To ensure focus on the outcome, try this structure with your team:

Pre spike:

• What problem are we trying to solve?
• How does it tie to the economic outcomes of our organization/product?
  • What work item in the backlog/roadmap can we not complete?
  • How does this tie into our software strategy/software reference architecture?
• What is the status quo?
• What is the projected value?
• What is the time-box?
• What materials/equipment do you need to support the spike?
• Are you committed to educating and uplifting the organization if the spike is the prevailing methodology?

Post Spike:

• Show us the working tested software.
  • If it doesn’t work, do you need more time or help?
  • How much more time or help?
• Given what we learned:
  • How does it tie to the economic outcomes of our organization/product?
    • What work item in the backlog can we not complete?
    • How does this tie into our software strategy/software reference architecture?
  • How does the spike compare to the status quo?
  • What is the projected value?
  • What materials/equipment did you need to support the spike?
  • Are you committed to educating and uplifting the organization if the spike is the prevailing methodology?
  • What would it take to roll this out to the organization?
• Peers, do you believe this is the way?

Depending on where your organization is in maturity, the above spike format can be used as a formal gate to control the number of spikes in progress or it can be used as a structure within a Center of Practice or Guild. Regardless, spikes should be tracked in a central wiki, to centralize learning and understand of architectural discussions.

The idea is simple. Spikes are to learn by producing working tested software, and this will keep the organization from hanging nets in the team space.