Focused sessions cut down on risk and clear up product timelines when there are open-ended questions.
Time sucks loom with every blink of your cursor. A big new feature with unclear parameters. A sticky technical question that stops your progress.
Big open-ended questions steal your focus. Technology hiccups you once tolerated feel like banging your head against a wall as ship deadlines approach.
Technical or design frustrations tend to invite ad hoc solutions. Problems to be solved in or around your work. But by failing to devote dedicated time to solving nonbinary problems, you’re missing out an opportunity to make critical discoveries, share knowledge, and cut down on future risks.
You need to do a spike, what engineer Kent Beck – author of the Extreme Programming book series – called a “very simple program to explore potential solutions.”
Spikes, which came into vogue during the rise of agile software development (Beck was an original signer of the Agile Manifesto), are still valuable tools two decades later for answering ambiguous or lingering questions.
Read on for insights into the types of spikes, how to effectively structure these “simple programs,” and communicate what you learn to your team.
What is a spike?
A spike is a way to set aside time for a developer to try and find possible answers to open-ended questions. If you have multiple options for solving a technical challenge or aren’t certain if a given solution will give you the results you want, a spike might be just what the doctor ordered.
In Microsoft’s Code With Engineering Playbook, they categorize two main types of spikes: technical and functional.
Technical spikes are for when your team believes there are a number of answers to an engineering problem or are unfamiliar with technology that might be the answer to that problem. With a tech spike, you might assess the load impact of a particular function or whether to build or buy software.
A functional spike dives into the process around solutions. It’s a deeper look into the steps you need to take, the potential risks, and how implementation could get complicated for your team and the end user.
You may often do a spike before or at the beginning of a sprint. A spike has four distinct parts:
You know the problem. And it’s meaty.
You don’t know the solution.
You investigate to try and find the best approach.
You report back what you find.
A successful spike often doesn’t end with an implemented solution. The outcome is a deep understanding of the problem and, if available, a recommended approach to solve it. Sometimes a spike unveils a deeper challenge that requires a further spike.
In explaining the idea he coined, Beck suggested this was an opportunity for “driving a spike through the entire design.” It’s a way to poke holes in your design theory. Others, in turn, have extended that idea to suggest that a spike is a deep – but narrow – dive (akin to an actual metal spike driven into wood) into a topic.
In an effort to back away from such a direct metaphor, Beck suggested “architectural prototype,” as another name for this process of exploration. He saw a spike (in the same fashion as an engineering feasibility spike) as a means to put some parameters in place that might help your team move forward or narrow the scope of pursuit.
“Most spikes are not good enough to keep, so expect to throw it away,” said Beck. “The goal is reducing the risk of a technical problem or increasing the reliability of a user story’s estimate.”
3 Steps for Structuring an Effective Spike
The start of a spike might feel like the expanse of outer space. A moment of exploration and of possibility. But just as you wouldn’t step out of a space shuttle without a tether, you need anchors before you do a spike. Spikes are valuable for what they reveal; but they lose utility without clear constraints in place.
1. Define what you’re looking to answer.
Treat spikes as science experiments. Begin with a clear hypothesis.
“Build the spike to only address the problem under examination and ignore all other concerns,” explained Beck.
While it’s important to define why you’re doing the spike, you don’t need all the answers before you start the process. In a forum discussion on Scrum.org about sizing spikes, Daniel Wilhite, a manager of software engineering at health insurer Bright Health, stressed the importance of not being paralyzed by choice.
“A spike’s purpose is to learn more about something in order for it to become ready for a sprint,” wrote Wilhite. “But you should always be willing to move forward on things with a bit of uncertainty because you will never know everything before you start.”
2. Time box your spike to stay on task.
While a spike affords you the freedom of time to try and address an ambiguous problem, you need to decide the amount of time and resources you’re going to commit before you dive into the unknown. For Andrew Fuqua, the SVP of Products at ConnectALL (a value stream management company), a time box – a predetermined amount of time – eliminated one of the main variables that could derail your exploration.
“Setting a small time-box limit is another way to encourage clarity,” wrote Fuqua. “I like to set explicit policy for them…no vague spikes with vague results.”
The structure of a time box follows the same parameters as productivity techniques like the Pomodoro Method (30-minute blocks divided into delineated moments of work and rest). It sets expectations for how a spike fits into workflow and when you’ll reconnect as a team to determine next steps.
3. Take notes to document what you discover.
With every spike, you’ll find interesting and unexpected pathways that aren’t on task. It’s easy to get carried away with details that don’t matter. But if you don’t document what you discover, you’ll find it’s harder to come back later and remember all of the details.
Notes let you stash those ideas without getting derailed. Hold your focus and build a written record in real-time. Don’t get bogged down by organization. Instead, look to capture your ideas quickly to keep moving forward and make sure you’re staying on the path to answer the question that launched a spike.
Tell the story of your spike through a presentation.
After a spike, you know a lot that your team doesn’t know. And now, it’s up to you to decide how to summarize your discovery.
If you’re briefly sharing what you’ve learned in a stand-up meeting or Slack, hone in on the key point and the big steps that led you to your finding. Use bullet points or organize your ideas in a similar fashion to draw a clear line through what you’ve uncovered.
Some spikes will require a more thorough discussion. But how do you distill 48 hours of research into a 20-minute presentation?
Take a page from Google software engineer Addy Osmani, who recently shared clear tips for how to communicate effectively as a technical lead on LeadDev.
“Shorter messages are more likely to be interpreted in their entirety,” said Osmani. “Don’t stray from the core point of the message.”
You’re telling a story and your team needs to be able to follow alongside. Pick the most important point of discovery (what Osmani calls the core point) and then take your team on the path.
Briefly restate the problem you examined. This is why you did the spike. Set the expectations for what you’re going to cover in your presentation to keep your team focused on the task at hand. This also helps you maintain focus, similar to the start of your spike.
Explain how you arrived at your conclusion(s). Let everybody into your moment of discovery first. Show how a given piece of software or feature can address the problem. Then, go back to the beginning and be specific in outlining the potential benefits or reasons you’ve landed on a given pursuit. Don’t get hung up on branches of inquiry that didn’t yield fruit. That’s why you took notes for an appendix (see below).
Offer an idea of what might come next. Frame the next steps as a recommendation, leaving time and space for your team to pick up the thread of what you’ve started. With a clear grasp of how long a project may realistically take, your project manager can work with you on planning and establishing timelines.
Use your notes as the foundation for a written appendix.
There’s always more to the story than what you can share in a presentation. That’s why a written appendix ensures a spike has utility beyond the moment of exploration.
“Having full results detailed somewhere will help the team trust the results,” explained Microsoft’s Code With Engineering Playbook. “Data can be interpreted lots of different ways, and it may be necessary to go back to the original data for a new interpretation.”
We’re all wired differently. While some of us may want the story around a solution, others want to be able to come to their own conclusion with a thorough look at the source material.
Once the spike is completed, the creation of an appendix gives you the opportunity to reconsider and organize those spontaneous thoughts. A written record also serves as a handy reference in the likely event that you want to revisit an idea.
Spikes rarely offer a singular path forward, instead giving you valuable insight into the unknown. They’re an efficient way to pursue open-ended questions, share knowledge, and shine light on potential solutions.
Make time for spikes to save your team time in the long run.
Check out Stashpad
Thanks for reading this post! It comes to you from the good people at Stashpad :)
Stashpad is the note-taking app designed for your working memory. It's made for devs, by devs. It comes with features for technical notes, like markdown support, customizable key bindings, and syntax highlighting.
Get your thoughts out, organize them effortlessly, and return to them when you're ready.
Top comments (0)