New Zealand based company, 3 months, examines how retrospectives act more as a preventative medicine than its counterparts.
One of the features of using Agile methods is the opportunity for continuous improvement within a project. There are a number of improvement opportunities throughout a typical iteration or sprint─over the next few weeks I’m going to walk through a few, starting this week with the Retrospective. Retrospectives are one of the many tools in Scrum and other Agile methods that are absolute must-haves for continuous improvement.
Think about the last time you built a product (or had one built for you). If you weren’t using an Agile method like Scrum, chances are that you pushed through the project in one big rush, waiting until the end to think of the things you would do differently next time. If you were lucky there may have been a chance for a review afterwards.
Enter the retrospective. Retrospectives take place frequently, at the end of every sprint (typically 2-4 weeks), and give the team a big opportunity to do things better sprint by sprint. A retrospective helps the team identify any changes or corrections needed during the project.
While I’m a fan of a good post-project review it is often equated to a post-mortem and, following this analogy through, retrospectives are closer to the idea of preventative medicine. Ultimately this isn’t so different from any other lessons learned process but for me the frequency and drive for action that comes out of a retrospective make them highly effective. As an added plus, retrospectives are also fun to facilitate (if you’re into that sort of thing) and generally make everyone feel more positive about the approaching sprint.
Running a retrospective is a pretty standard process but again is open for improvement and adaptation. My favored format is:
- What just happened? (aka “set the stage”) The team builds a brief time-line of what happened during the sprint.
- How are we feeling? Each team member draws a mood line of how they were feeling throughout the timeline, talking through their personal peaks and troughs during the sprint (I’d love to know how this technique came about!)
- Things to note! You can use whatever categories you need here, but generally Good Things, Bad Things, and Ideas work well. Some facilitators also add Bouquets─things that other team members have done during the sprint that are worthy of praise.
- Actions: The best way to get a short-list of actionable items is to use dot-voting/multi-voting to highlight the top three or four things that the team wants to address. If these items are related to the product they’re moved into the product backlog. If they are process related they generally become the project lead/Scrum Master’s (or sometimes Product Owner’s) responsibility.
- Close the retrospective: Check how the retrospective went, and confirm the next steps.
For a bigger retrospective, particularly in between project phases, I think it’s good to use a more elaborate Innovation Game to generate ideas for how things could be better next time. I like Remember the Future─it’s a game that can be used for either product brainstorming or focused towards the effectiveness of the whole team.
Retrospectives are a good habit to get into. They can also be used in non-Agile delivery as well (i.e. in Waterfall, running a retrospective after the completion of every milestone).
More on retrospectives
There are some good books (Agile Retrospectives) and many articles around the web but ultimately you need to run one, get feedback from the team and start improving. Some useful starters:
- An action planning focused method
- Another on product level retrospectives
- A useful article on improving your retrospectives—you’ll get the idea soon enough. �
To read more please visit 3months.
