This was previously posted on my old blog, Spike the Poodle.
After reading my new (autographed!) copy of Esther Derby and Diana Larson’s book on Agile Retrospectives, this week I tried some of the ideas out in our team retrospective. I really recommend reading the book and trying the techniques, I’d be interested to hear about other people’s experiences with them. Ade Miller also highlighted some ideas this week, including an article from Industrial Logic.
Firstly, we had a clear goal for the retrospective rather than just continuous process improvement, which was starting to get stale. I started the retrospective by asking the team to sum up the Sprint in one word, which actually gave me a great insight (especially since I’d been away for most of the Sprint!) The team had come really close to completing all of the work they’d committed to, closer than in any previous sprints, and everybody felt that they’d nearly made it but not quite. The team seemed to like the exercise, and they’ve suggested using song titles or animals next time. I’m particularly intrigued by the song titles suggestion
We used a timeline to gather data. I drew the team’s burndown chart on the white board and asked them to record events that had happened on post-it notes and stick them against the relevant part of the chart. What worked well was asking them to think back through the Sprint about what had happened, but since the burndown chart was fairly flat it didn’t really generate a great discussion in itself. I think this activity would work particularly well with a spiky burndown graph.
I asked the team to stick red and green dots on the positive and negative events. The good thing about this activity is that you actually get some surprising results – some of the things that I thought were really bad, and might have devoted more time to discussing, didn’t actually have any sticky dots on. It really did make it clear what the significant events were, however there were a lot!
We spent quite a bit of time talking about what was causing the main issues, and eventually we agreed on two areas we wanted to address: how we manage bugs during the Sprint, including bugs that relate to the current stories as well as new bugs that don’t, and how we can do better at getting things done. We spent too long discussing the issues, but this was partly because we weren’t really sure before the retrospective what our main issues were – next time, I think we will have a clearer goal which will make the meeting more focussed. I also need to get better at timeboxing! We identified a list of solutions for managing bugs better, and then used voting to decide which ones we should use.
I asked the team to choose up to two solutions to try for the next Sprint, so that we weren’t making too many changes all at once. Interestingly, most people didn’t want to be limited to only trying two things and wanted to do them all at once. We compromised and identified three things to try over the next two weeks.
Next time, I plan to focus on what we can do to get better at getting things completed within the Sprint. This has been a key issue for us, and I’ve also spoken to people on other Scrum teams who have the same problem, so I do plan on posting updates on what we come up with! In the meantime I will also be attending Rachel Davies’ workshop on retrospectives, so hopefully our next one will go even more smoothly.