Don't gamble on team issues resolving themselves.

Don’t gamble on team issues resolving themselves.

Retrospectives are part of most methodologies, even though there are many different terms. For instance, most waterfall frameworks call them post implementation reviews or postmortems. And each methodology focuses on different nuances. Agile, as a macro set of frameworks, has more aggressively embraced retrospectives than waterfall or iterative frameworks.  Retrospectives in Agile reflect the adoption of the principle of kaizen (Japanese for improvement, often interpreted as continuous improvement). They should be focused on discovering what will make the team or organization deliver more value. While many retrospective techniques posit the questions “what worked well” and “what did not work,” the real reason to do any retrospective is to identify, agree on and plan for what can be done better. The exact process any team uses is a reflection of the technique the team wants to use, what works in the organization and the specific team situation. For example, the timing of retrospectives varies significantly depending on the framework and the organizational culture.  Most waterfall projects do a retrospective at the end of the project (or release), while Agile projects typically do retrospectives at the end of every sprint, at each release, at the end of the project and occasionally on an as needed basis.  In Agile, retrospectives occur when change can actually be applied to the project to impact the current delivery.

This is the basic process for a typical end-of-sprint retrospective:

  1. Set Up:  First, create a safe atmosphere (I review Norm Kerth’s Prime Directive with the team). Then ground the team by focusing on the current sprint’s results (for example review the Burn-down Chart or have the team develop an annotated sprint timeline). Time box this part of the retrospective to no more than 20 minutes for a two week sprint.
  2. Idea Generation: Encourage the team to dig in and capture the details.  For retrospectives focused on process or flow, I often use sticky notes to brainstorm, followed by mute mapping to group (affinity diagraming). For team or personnel issues, I use storytelling. For example, have subsets of the team describe a fictional scenario based on real life problems and how they would solve the problem. I have also used direct discussion. This step should be time boxed to 30 minutes for a two week sprint.
  3. Insight Development:  Once the idea generation step is completed, the team reviews the data and comes to a consensus about what it means. One method of analysis is to look for patterns and to determine if there are trends in this stage.  The goal is to recognize if there is a problem so you can start to resolve it.
  4. Identify Improvement Objective:  In many cases a team might have identified a number of ideas for improving their productivity. Focus on the top one or two big wins.  The rational for not fixing everything is first that the time need to fix the problem will come from the team’s capacity to deliver business value (there is only so much capacity that the team has at its disposal).  Secondly, if the remaining issues are really problems after the one or two most important have been dealt with then the team can decide to address them during the next iteration. FYI, this continuous incremental process improvement is one reason team productivity, aka velocity, typically increases from iteration to iteration.  After the team selects the issue (or issues) to be tackled, have them add it to the next sprint backlog so that they get addressed.  This step should be time boxed to 30 minutes for a two week sprint.
  5. Wrap-up: Spend 5 – 10 minutes reviewing the session so that the next retrospective will be even more effective.

Retrospectives are a tool that the team uses to identify what they can do better.  The basic process – making people feel safe then generating ideas and solutions so the team can decide on what they think will make the most significant improvement – puts the team in charge of how they work.  When teams are responsible for their own work, they will be more commitment to delivering what they promise. The retrospective process is focused on increasing the team’s capacity, rather than trying to generate lessons learned for the next project.

Related Entries

Retrospectives: Retrospectives versus a Classic Post-Mortem, Mindset Differences

Retrospectives: Obstacles

Retrospectives: Listing Techniques

Retrospectives: Non-listing Techniques

Retrospectives: A Social Event