Spikes Within Sprints
6 December, 2019
It is important that individuals on your team have time allocated for growth and development in addition to Sprint work. I approach this by rarely giving developers formal training and instead allow them to spend time working on Spikes. Here, I will explain what a Spike is and how you can effectively utilize them within your team.
What is a Spike?
A Spike is an investment of time, energy, and resources towards a task dedicated to disrisking or dispelling unknowns. It may also be referred to as research although I don’t like to use this term because research is unbounded and uncertain. More so, research covers a large area and tends to be self-directed. Spikes, on the other hand, are focused on a small aspect that actually needs to be understood in order for the person to be productive. Additionally, Spikes are time-limited because they are aligned with that clear objective or related to future work.
I expect engineers to be able to declare how much they understand the work that they are doing. If they need to spend extra time to reach that level of comprehension then they can request a Spike to come up to speed. We set the objective of the Spike as well as allocated time, which could range from a couple of hours to a couple of days depending on the expected value that it could bring (which is difficult to measure). At the end of that time the person reports their findings to myself or the team and the information is then used to solve a problem or increase overall productivity.
- Spikes give people time to recognize and focus on specialized topics adjunct to the work that they do. This removes the full breadth and weight of formal training or scaling the whole domain by narrowing in on issues that they are faced with day in and day out.
- Spikes work best if there is one clear question to answer. Refrain from using ambiguous statements or a bunch of questions which will result in ambiguous or multiple answers.
- The Spike should be time-limited. At the end of the designated time the person should report their findings, even if they have not come to a conclusion. In this case, the findings may result in the assignment of another Spike.
Michael Mac-Vicar, CTO at Wildlife Studios, dissects how to set guardrails that would contain the exponential increase in cloud costs.
CTO at Wildlife Studios
Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.
VP of Engineering at Mews
David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.
David La France
VP Engineering at Synack
Brad Henrickson, CTO at Scoop, shares how by establishing the Architecture Council he advanced strategic thinking of the engineering team and overall strategic orientation of his organization.
CTO at Scoop
Brian Hough, CTO at Beam Dental, discusses how his company transitioned from Agile to a version of the Shape Up framework after many challenges they had with Agile.
CTO at Beam Dental
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.