Technical Spike

What

A time-boxed investigation, a small experiment to research an answer to a problem and get some concrete data instead of speculation.
Comes from analogy with rock climbing when a climber stops to insert a spike into the rock. It isn’t something that propels them further in climbing but it reduces risks, provides safety, and confidence for future climbing.
In the end of spike you throw away the code and use the knowledge.

When

• To research into something (e.g. Should we use this tool? - learn and try)
• Expand knowledge: Scope/research on some work that the team doesn’t fully understand before they begin working on it (e.g. what is DOM manipulation)
• Before starting on a technical activity (should we add this feature? e.g. hamburger menu: worth it) - whether feasible for the project/or should it be a stretch goal & how long it would take to complete it etc
• Before starting on a large amount of work or large user story - (how should allocate our time?) allocating time breaking it into smaller problems / how best to approach it

Why

• dispel FUD — fear, doubt and uncertainty. If all team research and understand the concept – all on the same page
• Mitigate risks (e.g. using a tool that turns out to be terrible.)
• More efficient way of working (is it worth spending adding this feature? Even if answer is NO - saved time and hassle) / Focus not on the complexity - what is a reasonable time to invest in - and when time runs out,fine that 'we dont know yet' or 'no shouldn't do this' (rather black hole) - Successful if we can make a decision based on the conclusions. (if run out of time - if document, then can still go back to it)
• Gives structure to your day - breaks it up (between sprints) - everyone is on the same page/review that we are on the right track / some sort of retrospective

How

• Create a small program or test that demonstrates the answer to a problem.
• Work from a practical point of view.
• Only address the problem under examination.
• Pair up with someone - spike on different approaches.
• Explore at least two solutions.
• Time-bound - If you weren’t able to answer the question before time runs out, still report the results to the team and decide what to do next.

Give an example of how a spike could have helped with last week's projects.

• (Agreed amount of time (can be few hours to a few days long etc and shorter than a sprint))
• (the objective of a Spike might be to successfully reach a decision on a course of action.)

"Flex vs Grid.css?"

• Different members had different ways to position elements, flex and grid.css.
• The members did not know the other method i.e grid.css member didn't understand flex, and flex members didn't understand grid.css.
• In our case, we just voted on which one to use. This meant moving forward with one member not comfortable with flex.
• Having a technical spike would of allowed everyone to research the other way to see which they thought would work best for the project
• Would allow all members to understand both methods.
• Technical spike could of been 30 minutes - 1 hour