Technical spike — what and when to do

Technical spike is the investigation to drive out risk and uncertainty. It comes from Extreme Programming (XP) and is a great way for the team to:

1. Reduce the risk of a technical problem
2. Increase the reliability of a user story’s estimate
3. Allow the architecture to emerge instead of BDUF

There are already a lot of good articles on the why, what-is and how-to on technical spike. So instead of rehashing what’s out there, I would like to share some thoughts on the when and how to do a better technical spike.

When to do technical spike

• Your team is having trouble estimating stories effectively. There are many wildly different opinions on the size of user stories. Consider a spike and rely on expert opinion instead of consensus based estimation like Planning Poker
• The story point estimate is unrealistically high, to sandbag FUD — fear, doubt and uncertainty. Use technical spike to dispel FUD, then estimate.
• Feedback from retrospectives to explore better ways of handling accidental complexity. During sprint planning, allocate time to reduce tech debt

What not to do

• Avoid learning in silo. Instead, pair up with someone and spike on different approaches to solve the same problem. E.g. NHibernate vs. Entity Framework for ORM. Each will research and code independently, and compare their notes during the daily post standup
• Avoid offering only one solution due to confirmation bias. Instead, explore at least two solutions and preferably three.

If you develop one solution for a problem, it’s a trap. Two possible solutions is a dilemma — which one do I choose? Once I have three solutions, I often have more insight into the entire problem, and I can generate more choices. I might not need more than three choices — Johanna Rothman

• Avoid sharing without recommending. You demonstrate your spike, present your analysis but make no recommendation to the team because you fear empowerment. Instead, be bold and recommend the best solution. In the land of the blind, the one eyed man 😉 is king 👑 — be bold.
• Avoid comparing products instead of the product ecosystems. The best tool is useless without the right people. Instead, include the human capital aspect in the evaluation. Google Trends, LinkedIn and Meetup are your best friends to investigate the adoption trend and the size of talent pool for each product in your region.
• Avoid investigating without sharing. After the technical spike, you do not share your investigation with the team, regardless of the decision to/not use NHibernate. Instead, make the best use of technical spike to hone your technical presentation skills. Share your findings during the daily post standup and/or demonstrate your spike at the end of sprint.

A person can have the greatest idea in the world but if that person can’t convince enough other people, it doesn’t matter — Steve Jobs

If you enjoyed this piece, you might like to know how technical spike helps in agile architecture.

Hope this helps. Cheers! 😊