#2782

The purpose of spiking

A conversation I happened to overhear yesterday got me thinking about spiking. What are spikes really for? As usual Mary and Tom Poppendieck have something enlightening to say on the matter.

“Regular prototype milestones make concurrent product development possible because they provide a focal point around which cross-functional communication can and must occur. Prototypes also provide early feedback on design problems and customer preferences.” – Poppendieck

A lot of the time when we think about spikes we think about them simply in terms of a feasibility study or building a prototype. In fact it’s really a learning experience not a building one. You build the code to learn potential design choices and show it to customers to learn from them.

If you view spiking as learning then you start to think about other things you might want to spike on. Maybe I should do spikes around testability to establish how my proposed design can be tested?

Given all of the above there are some “smells” associated with spiking:

• Only one or two people are involved in the spike – This does not make it a vehicle for cross-functional communication.
• Developer only spike – Cross-functional communication will be simpler if the whole team is involved and has an opportunity to learn.
• Deciding while learning – The spike is a learning activity not a decision making one. Decisions should be made after the spike not during it.
• Spike code moves into production – This is a side effect of deciding while learning. Throw all your spike code away, don’t end up shipping your “science project” prototype to customers.

I’m still reading Mary and Tom Poppendieck’s book, Lean Software Development: An Agile Toolkit, and am more impressed the more I read.

Currently listening to:
Black Grape – It’s Great When You’re Straight…Yeah