A New Year is upon us, and with the New Year comes new features for existing projects or perhaps new projects altogether. Many ask the question what can we do to learn how to develop the best quality software for these new features. Obviously there are lots of ways to learn: books, blogs, training classes, but moreover, agile provide a unique (and sometimes forgotten) option for learning - the “technical spike”. A “technical spike” is a story that is aimed at answering a question or gathering information. A technical spike differs from a “user story” as it focuses on learning from experimentation rather than writing software to be shipped – a spike should be demonstrable to allow a team to see and learn from its results, and just like the rest of the “user stories”, it is reviewed during the iteration demo to all team members. The spike should be captured as a story, sized and prioritized with the rest of the stories in an agile team’s backlog. The acceptance criteria for a spike should clearly document the desired learning outcome using the voice of the team: “As members of the team, we want to understand how to change the database technology supporting our application without losing any data”. From observations while coaching teams, spikes are common during the early iterations of a project but sometimes decrease in frequency after the first few iterations. It’s interesting to ask teams why this occurs – some teams reach a shared understanding within the context of their project for which there is a belief that additional spikes for learning are not necessary, while others become overwhelmed with the need to focus on user stories for which spikes are lowered in priority. In both situations, the risk of waste is increased - imagine a technical spike that results in a team learning how to reduce the complexity of all future stories – such as spike could reduce the amount of time and effort needed to complete future stories, accelerating the delivery of business value. Although more common at the beginning of a project, spikes should continue throughout a project – as if spikes are not being completed, what is the team doing to conduct experiments attempting to improve what they do? Spikes are intended to enable learning that is most relevant for a specific team or context. Rather than getting frustrated trying to blindly adopt someone else’s “best practices”, the spike allows a team to learn and explore to determine the most effective solution for their immediate need. If you haven’t done a technical spike in a while, give one a try – listen closely in your next team retrospective as they help identify many learning needs – challenge all team members to contribute to the spike, and most importantly ensure that the learning provided by the technical spike is shared and understood by all.
- Case Studies