At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
At the end of each iteration, Agile teams that apply ScrumXP (and many teams who use Kanban) gather for an iteration retrospective, where the team members discuss their practices and identify ways to improve. Timeboxed to an hour or less, each retrospective seeks to uncover what’s working well, what isn’t, and what the team can do better next time.
Each retrospective yields both quantitative and qualitative insights. The quantitative review gathers and evaluates any metrics the team is using to measure its performance. The qualitative part discusses the team practices and the specific challenges that occurred during the last iteration or two. When issues have been identified, root cause analysis is performed, potential corrective actions are discussed, and improvement Stories are entered into the Team Backlog.
The iteration retrospective is used by Agile teams to reflect on the iteration just completed and to derive new ideas to improve the process. This helps instill the concept of relentless improvement—one of the pillars of the SAFe Lean-Agile Mindset—in the individuals and the team. And it helps ensure that every iteration yields some small improvements in the team’s process.
The whole team participates in the retrospective, with the Scrum Master facilitating and applying the tools and processes for data collection and problem-solving. The team conducts the retrospective in two parts:
- Quantitative review – The team assesses whether they met the Iteration Goals and this is a binary measure: yes or no. They also collect any other metrics they agreed to analyze. This should include velocity—both the portion that is available for new development and the part devoted to maintenance. Agile teams collect and apply other Iteration Metrics for visibility and to help with process improvement. This data is also the context for the qualitative section that follows.
- Qualitative review – First the team reviews the improvement stories they had identified in the prior retrospective, and then analyzes the current process, with a focus on finding one or two things they can do better in the next iteration. Since many improvement items have a significant scope, the team should divide them into smaller improvement stories, so that they can focus on what they can improve during an iteration.
- Test automation (including Test-Driven Development and Behavior-Driven Development) and Continuous Integration
- Architectural approaches for decoupling development from deployment (see Architecture and Design Quality section of Built-In Quality)
- Automating the deployment process
- Building telemetry and recovery techniques into systems
Lean-Agile Leaders are responsible for preserving and protecting the time teams will need during each Program Increment (PI) to focus on cultivating these skills, in addition to delivering new features. The Innovation and Planning (IP) Iteration is a great time to create opportunities for teams to advance their skill levels in these new domains.
There are several popular techniques for eliciting subjective feedback on the success of the iteration (also see , , [4,], ):
- Individual – Individually write Post-Its and then find patterns as a group
- Appreciation – Note whether someone has helped you or helped the team
- Conceptual – Choose one word to describe the iteration
- Rating – Rate the iteration on a scale of one to five, and then brainstorm how to make the next one a five
- Simple – Open a discussion and record the results under three headings
The last is a conventional method, in which the Scrum Master simply puts up three sheets of paper labeled “What Went Well,” “What Didn’t,” and “Do Better Next Time,” and then facilitates an open brainstorming session. It can be conducted fairly easily, making all accomplishments and challenges visible, as illustrated in Figure 1.
Teams may choose to rotate the responsibility for facilitating retrospectives. If this is done, one of the fun practices is to allow each person to choose their retrospective format when it’s their turn to lead. This not only creates shared ownership of the process, but it also keeps the retrospective fresh. Team members are more likely to remain engaged when formats are new and different.
Below are some tips for holding a successful iteration retro:
- Keep the meeting timeboxed to an hour or less. Remember, it will come up every two weeks. The goal is to make small, continuous improvement steps.
- Pick only one or two things that can be done better next time and add them as improvement stories to the team backlog, targeted for the next iteration. The other targets for improvement can always be addressed in future iterations if they continue to surface in retrospectives.
- Make sure everyone speaks.
- The Scrum Master should spend time preparing the retrospective, as it’s a primary vehicle for improvement.
- Focus on items the team can address, not on how others can improve.
- To show progress, make sure improvement stories from the previous iteration are discussed either at the Iteration Review or the beginning of the quantitative review.
- The retrospective is a private meeting for the team and should be limited to Agile team members only (Development Team, Scrum Master, and Product Owner).
Learn More Derby, Esther and Diana Larson. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.  Fun Retrospectives. www.funretrospectives.com  TastyCupcakes.org. http://tastycupcakes.org/tag/retrospective/  Agile Retrospective Resource Wiki. http://www.retrospectivewiki.org
Last update: 2 October 2018