Practice : Design and Tech Spikes

Purpose and Strategic Importance

Design and Tech Spikes reduce delivery risk and improve decision-making by providing timeboxed, focused exploration of complex or uncertain technical challenges. By investigating unknowns early, teams can validate feasibility, uncover constraints, and make informed decisions without prematurely committing to risky builds.

Without spikes, teams often proceed with incomplete information, increasing the likelihood of rework, delays, and costly architectural missteps that slow delivery and undermine system quality.

Description of the Practice

  • Spikes are short, timeboxed tasks focused on exploring technical approaches, evaluating design options, or reducing uncertainty.
  • They may include prototyping, proof-of-concepts, research, or technical feasibility assessments.
  • Outcomes inform backlog refinement, system design, and delivery planning.
  • Spikes produce learning and recommendations, not production-ready code.

How to Practise It (Playbook)

1. Getting Started

  • Identify areas of technical uncertainty or architectural risk within the backlog.
  • Define clear, specific goals for each spike (e.g. validate performance approach, assess integration options).
  • Timebox spikes to limit effort and encourage focused exploration.
  • Share findings and recommendations with the team.

2. Scaling and Maturing

  • Integrate spikes into planning and refinement workflows as standard practice.
  • Use spikes to reduce risk before large technical changes or new system designs.
  • Document outcomes to support future decision-making and learning.
  • Align spikes with architectural forums and technical governance processes.

3. Team Behaviours to Encourage

  • Treat spikes as structured learning, not unbounded research.
  • Focus on reducing uncertainty, not delivering features during spikes.
  • Collaborate across teams to share knowledge and insights.
  • Use spike outcomes to improve confidence, reduce risk, and accelerate delivery.

4. Watch Out For…

  • Spikes without clear goals or time limits leading to wasted effort.
  • Teams skipping spikes and rushing into risky technical changes.
  • Spike outcomes not shared, limiting learning or decision impact.
  • Spikes producing production code without adequate validation.

5. Signals of Success

  • Technical risks and uncertainties are identified and explored early.
  • Teams make informed architectural and design decisions.
  • Delivery flows more predictably due to reduced technical rework.
  • Spike outcomes contribute to continuous learning and system improvement.