One of the challenges in our agile process at OpenDNS is creating time for spiking. If you are not familiar with the concept of a ‘spike’ it’s essentially time allotted for research, design, prototyping, and exploration. Scaled Agile Framework has a good article here on spikes if your are looking for more details.
Our challenge around spikes was that the engineering teams often found it difficult to balance the amount of scheduled work with the desire to work on spike-related projects – a problem not unique to our organization. With that we decided to create Friday Spikes.
At OpenDNS we have a great culture of transparency and openness. One example of this is that each and every Friday after a catered lunch all employees take part in a Townhall. This is an all-hands meeting where we do a week-in-review, go over great successes, our roadmap, company news, and other company wide items of interest. The Townhall typically ends at 1:00pm and the spikes begin immediately after.
Organizing the Spike
Leading up to Friday, the engineers are all encouraged to enter their spike ideas into our Trello Board. This is a great tool for keeping track of small projects and items. Essentially, we have ideas that get confirmed as spikes for that Friday and all of the engineering teams meet up and review the boards. The rules are pretty simple, we ask that nobody works alone and we strongly encourage people join teams that they regularly do not work with.
Once spikes are communicated people meet up at a designated area. Some meet in a conference room if a whiteboard is needed while others meet in a comfortable open space. Once assembled, the teams commence their spikes.
Communication and Output
At 4:30pm all of the engineers get together to review spike-related progress, roadblocks, and overall status. This can include a demo, code samples, or a review of a whiteboard/idea, among others. This serves as a wrap-up meeting for the spikes and allows others to learn about and comment on what was done.
Here is an example of some of the spikes we have done:
Note: we had to blur out some of them for obvious reasons.
What We Learned
Running Friday Spikes has been a valuable learning process and is proving to be a valuable component of our agile process. We have learned that having the cards ready beforehand really helps the team prepare for which spikes they will work on. We have also learned that engineers love the cross-team collaboration and often will join more than one spike team on a Friday. In fact, we’ve frequently heard engineers exclaim “Wow, I want to abandon my spike and work on this other great idea!”
To date we have had some excellent spikes that have been very useful in learning estimates, sharing ideas, and even shipping code. As a result, we plan on continuing the spikes for many Fridays to come!