At LCA we have been implementing the Scrum development methodology in increments. We have slowly been embracing certain practices of the methodology over time and tweaking it where we see fit. Over the past 2 years this has seen us introduce many of the key practices such as continuous testing and integration, time boxed iterations as well as retrospectives. We have still been tweaking our approach to retrospectives, trying to determine the best way to carry them out.
Retrospective stages
Retrospectives tend to have the following stages, setting the stage, gathering data, developing insights, deciding what to do and closing the retrospective. For those who would like to find out more I would strongly recommend the book Agile Retrospectives : Making good teams great as a great guide on how to conduct a retrospectives and the different exercises one can employ for the different stages. We have been trying different exercises for the “gathering data” stage.
Gathering data for retrospectives
A technique we use to gather data for the retrospective is simply getting people to reflect on the events of the sprint and to write events that were enjoyable, frustrating and puzzling as well as ideas they would like to see happen more, less or the same in individual index cards. These are then pasted up on a board and serve as a starting point for the next stage of the retrospective (developng insights).
The upside of this technique:
- Since people write things down, it is easier to get participation as opposed to people needing to speak up. This levels the playing field between the vocal and less vocal people in the group.
- There is a focus on suggestions and ideas early. Although this seems to be jumping the gun as we are still in the data gathering phase of the retrospective, sometimes the ideas serve as an indirect way of highlighting issues or events that were problematic in a manner that does not put anyone in the spot. Secondly having some ideas up already on the board facilitated the “developing insights” portion of the retrospective. I find it a bit more natural to merge the data gathering and developing insights portions
The primary downside of this technique however is that there is no real co-relation between whats going up on the board and when it happened in the iteration. The sense of “when did this event happen and what else was going on at this point” is hard to be determined.
Timelining the sprint
Specifically to deal with the limitation of not being able to track an event against a stage in the timeline we had tried in the last retrospective the timeline exercise instead. An excellent description on how this exercise is carried out is available at thekua.com .
The upside of doing this exercise was
- It forced the team to pull out events and the days in the sprint they happened. Many of the team members ended up needing to look at their closed tickets for their sprint to jog their memory. We did end up with a timeline that had events corresponding to dates.
- This more involved process also probably uncovered more events then the other data gathering exercise.
The downside seemed to be that we ended up with ”event” only data, no ideas or suggestions. Hence we had a brainstorming session for the “developing insights” stage where I tried to get team members to voice out ideas, to tackle some of the challenges the timeline exercise unveiled. That turned out to be a mistake as the team did not respond to the idea of vocalizing ideas. This of course had nothing to do with the timeline exercise itself, but having just spent 30 mins writing events down, I thought it a bit much to spend another 20 minutes writing ideas down and resorted to a vocal method. Bad idea.
Secondly because there was this implicit need to tie the ideas back to the timeline events, there was some constraint in ideas being voiced out. In the end, after much cajoling, many of the ideas put up on the board had little to do with the events in the timeline.
Lastly the mood graph that we drew below the timeline, although interesting, did not seem to provide much value. I was hoping that it would unveil to team members mood states among one another that they didn’t expect, however that did not seem to be the case. The data seemed too blur to really derive anything solid.
Summary
All in all, the timeline exercise is probably more suited for teams that have members from different departments that don’t meet as much and have longer periods between retrospectives. We try to keep our sprints between 2 – 2.5 weeks (10-12 working days) and hence a simpler exercise would probably suffice. Secondly maybe the team was already too use to the old way of doing things that this new form didn’t feel as natural. Having said that, many of the team members seemed to appreciate that the retrospective exercises was varied, that by itself was valuable.