By Esther Derby
Retrospectives are an integral part of Scrum. But too often, when I talk to Scrum teams, they tell me that they’ve stopped doing retrospectives. “We’ve run out of things to improve,” one ScrumMaster said. Another complained that after six sprints, they were saying the same things over and over at every retrospective.
If your retrospectives have gone stale, here are seven things you can do to inject new energy.
- Rotate leadership. Rather than always have the ScrumMaster lead the retrospective, rotate leadership among team members. Ask each team member to try one new adaptation when he or she leads the retrospective. By doing this, you’ll experiment with new activities and build the team’s group process savvy.
- Change the questions. Rather than asking the two standard questions ("What did we do well?" and "What could be improved in the next sprint?"), start by asking, “What happened during the iteration?” Even when people work in the same team room, they see things from a different perspective. Ask about surprises and challenges. Then ask about insights. When you have a list of insights, ask about possible improvements.
- Vary the process. If you’ve been leading group discussions, try using structured activities to help the team think together. Reconstruct the timeline of the project to help the team see patterns. Create a histogram that shows how satisfied team members are with the process they used and the product they created during the last sprint. Try using a fishbone diagram to explore root causes. Use dot voting to select improvements for the next sprint.
- Include different perspectives. For the retrospective after a release, include people from the extended project community—people who aren’t part of the team, but who play a critical part in deploying and supporting the software. Focus on understanding and improving the interface between the Scrum team and other parts of the organization.
- Change the focus. If you’ve been concentrating on improving how the team works the Scrum process itself, switch the focus to engineering practices or teamwork. If you’ve been focusing on a narrow goal (“How can we improve the build process?”), try a broad goal for the next retrospective.
- Try appreciative inquiry. Instead of looking at where to improve, look at what’s working well and how you can build on that. Use short, pair interviews to explore questions such as, “When were you at your best on our last sprint?" "Who else was involved?" and "What conditions were present?” After the interviews, put the pairs together in groups of four or six (two pairs or three pairs together) to find common themes.
- Analyze recurrent themes. If your team is bringing up the same issues at each retrospective, examine the list of issues. If nothing changes as the result of your team’s retrospectives, analyze the factors behind inaction. Are the issues related to organizational policies, systems, and structures? You may not be able to change organizational factors right away, but you can use your influence, and the team can change its response. Are the improvements the team chooses included in the next sprint plan? Change plans that are kept separate from daily work fall by the wayside.
Retrospectives are the key mechanism for examining and improving methods and teamwork. If they aren’t working for you, inspect and adapt!
