Iteration Retrospective

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

—Agile Manifesto

The Iteration Retrospective is a regular meeting in which Agile Team members discuss the results of the Iteration, review their practices, and identify ways to improve.

At the end of each iteration, Agile teams that apply ScrumXP (and many teams that use Kanban) gather for an iteration retrospective, during which 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.

Details

Agile teams use the iteration retrospective to reflect on the iteration just completed and to develop 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. In addition, 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. This is a binary measure: yes or no. Team members also collect any other metrics they agreed to analyze. This information 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. These data also serve as the context for the qualitative review that follows.

Qualitative review – First the team reviews the improvement stories they had identified in the prior retrospective. Next it analyzes the current process, with a focus on finding one or two things it 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.

As organizations move closer to implementing DevOps and a Continuous Delivery Pipeline, Agile teams will have a robust list of improvement opportunities, including but not limited to the following:

Test automation and Continuous Integration

Architectural approaches for decoupling development from deployment

Automating the deployment process

Building telemetry and recovery techniques into systems

Lean-Agile Leaders are responsible for preserving and protecting the time that teams 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.

Retrospective Formats

Several techniques have been introduced for eliciting subjective feedback on the success of the iteration (also see [1], [3], [4,], [5]):

Individual – Individually write feedback on Post-it notes 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 1 to 5, and then brainstorm how to make the next iteration become a 5.

Simple – Open a discussion and record the results under three headings.

The last is the familiar 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. Such a discussion 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, a fun practice is to allow each person to choose his or her own retrospective format when it’s that individual’s turn to lead. This not only creates shared ownership of the process but also keeps the retrospective fresh. Team members are more likely to remain engaged when formats are new and different.

Guidelines

Following are some tips for holding a successful iteration retrospective:

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 resurface 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 that 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 at 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

[1] Derby, Esther, and Diana Larson. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2006.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.