Scrum Retrospectives: Inspect and Adapt
So far we’ve been religious in performing retrospectives (although we misplaced our notes from the first one … not good). In my perspective, retrospectives are one of the most critical and highest-value aspects of becoming agile. The frequent review of how the team is doing, along with the discipline to incorporate changes quickly into your processes, should almost guarantee continuous improvement (and if it doesn’t you’ll know quickly). Retrospectives have given me confidence when we’re been faced with challenges in the process, or when the success we were hoping for wasn’t there. I know that we’ll have the chance to take a step back, inspect and adapt in the very near future.
Task-Based
Out of my CSM course I got the idea of only capturing deltas or changes. This avoids getting into complaint mode. You can’t say “people didn’t test their code well enough”. Instead you have to come up with a specific action item like, “make sure your code passes all the tests before passing it on to QA.” Where we can, we capture these tasks in new stories or incorporate them into existing stories.
Sticky Notes
My team has become a big fan of sticky notes. We use software to manage our projects, but we put up with the double effort of also maintaining a task board — the team likes the large visual. We also use sticky notes for our retrospectives. Everyone takes a few minutes to write down things that when well. I then gather them, read them out loud, and classify them. I do them same with changes or lessons learned.
The key value I see in doing this is that is stops more vocal team members from dominating the conversation, or influencing what other people might say. It also allows you to weight issues — if everyone mentions changes they want to see around the sprint planning process, for example, you can get a good idea that that’s a bigger issue for the team than if only one person mentions it. By classifying both the plus and changes, it also allows you to identify trends.
Check on Past Retrospectives
We start each retrospective by reviewing the changes or decisions we captured as issues previous sessions. This allows the team to (hopefully) see progress as we close issues that were previously identified.
Time-Boxed … not quite
We don’t actually do this, although I’d like to. So far our retrospectives have all approached (or surpassed) two hours. My hope is that as we get better with things, that time will be cut down. I’m a big fan of strict time-boxing, but I can’t bring myself to do it in the case retrospectives.
Retrospecting the Retrospective
We’ve definitely made progress in our retrospectives. While we never had to actually capture the change “don’t lose your retrospective notes” we’ve progressed from there (it’s always nice to start the bar so low) and I expect we will continue to.
