How to Use Retrospectives for Process Improvement

Retrospectives Process Overview

After each release/iteration, the Scrum Master/Team Leader should hold a retrospective which can also be called an intraspective. The aim of the retrospective is to improve methods and teamwork by reviewing the past iteration/release. There are 3 core questions that should be answered in every retrospective:

  1. What is going well
  2. What areas could be improved
  3. What should be we be doing differently

Generally, a retrospective is time-boxed to 2 hours and is based on brainstorming solutions and commit to a solution and discuss again, if success adds to the process. Retrospectives can be highly effective as they happen during development process providing immediate feedback on how the process is performing. If used correctly retrospectives can result in:

  • Improved productivity
  • Improved capability
  • Improved quality
  • Improved capacity

Esther Derby and Diana Larsen defined a 5 step process for holding retrospectives.

Step 1: Set the Stage

Setting the stage is all about setting the tone of the meeting and getting the team on board. Retrospectives work best when there is a lot of engagement and genuine feedback from the team. It is recommended to get people talking early by introducing themselves and their role but if the team members don’t change very often this might be seen as overkill. Next, the Scrum Master/Team Leader sets an agenda and rules for the meeting. To increase comfort level of team members to participate in the meeting the team can play the following games

Check In: Round robin where people give 2 sentences on what they want to get out of retro

Focus On/Off: Get people give their opinion on each pair of words ie. Conversation vs Argument, Understanding vs Defending

ESVP: The team anonymously identify their attitude towards retrospectives as one of the following:

  • Explorers: eager to discover new ideas
  • Shoppers: look for useful info and happy go home with 1 idea
  • Vacationers: not interested in retro but happy to be away from work
  • Prisoners: feel like being forced to attend

The total scores are kept and the individual votes disposed of. Then the team is asked how they feel about the results.

Working Agreements: small groups and create agreements, create master list

Step 2: Gather the Data

Next step is gathering feedback from team members on what happened during iteration. The goal is to determine a common vision of the iteration. The team leader can use the following team based facilitation techniques to get more interaction between team members:

  1. Timeline: The team creates a timeline of the iteration highlighting any milestones, issues occurred during the iteration.
  2. Triple Nickles: 5 groups are given 5 minutes on 5 ideas 5 times
  3. Colour Coded Dots: Team uses sticky dots to show emotions where emotions ran high/low during the iteration.
  4. Mad, Sad, Glad: Team uses coloured cards to describe emotional reactions during iteration
  5. Locate Strengths: Team discusses what went well during the iteration.
  6. Satisfaction Histogram: Team uses a histogram to demonstrate satisfaction for particular parts of the iteration.
  7. Team Radar: Team assesses performance against previous process improvement goals
  8. Like to Like: Team recalls experiences during iteration and compares reactions to events.

Step 3: Generate the Insights

Once the data on the iteration has been gathered it needs to be evaluated.  The data can be evaluated using the following brainstorming techniques:

  1. Five Why: The team works in pairs where they look at an issue and try find a solution by asking “Why?” numerous times to any reason for the issue helping determine the root cause.
  2. Fishbone Diagram Analysis: Also called Ishikawa diagram it is a technique used to identify root cause demonstrated in the diagram to the left. The team draws out the diagram, each branch is one area and then within that branch are possible reasons for that branch. The diagram should have all possible causes and which area the issue came from.
  3. Prioritise with Dots: Team uses dots to vote on what they feel is important to them.
  4. Identify Themes: The team identifies recurring patterns in the data gathered.

Step 4: Decide What To Do

After the data has been evaluated and the team have the insights into the issues they must decide how to rectify them. The technique called “circle of questions” can be used to give individuals opportunities to provide solutions where a person picks an issue and the next person proposes a solution. It is very important that any goals created to rectify an issue are SMART goals (Specific, Measurable, Attainable, Relevant & Timely). This will help ensure the goals are achievable within the next iteration and can be reviewed after. To sort the issues the team can use an action wheel where each item is categorised simply by choosing Keep/Drop/Add or Start/More/Less.

Step 5: Close the Retrospective

The final stage of the retrospective is formally closing it. There 4 tasks identified to close the retrospective is:

  1. Plus/Delta: What they want to do more of and want to change
  2. Helped, Hindered, Hypothesis: Feedback on retrospective itself giving everyone an opportunity to give their feedback.
  3. Return on invested Time: Team grade meeting 1-5
  4. Appreciations: The team members express appreciation to each other.

Esther Derby & Diana Larsen Going Through 5 Stages

>> For more information check out this PDF extract of Esther & Dianna book 

Pre-Mortem (Rule Setting, Failure Analysis)

The premortem is a facilitated team exercise that aims to identify the possible failures on a project before they happen. This helps the team to think long-term and visualise future change’s they might experience. The Product Owner needs to approve any mitigation or avoidance actions before they can be added to the backlog. The steps to conducting a post-mortem meeting are below.

>> For more info on premortem by Fun Retrospectives 

Imagine the Failure

  • The team brainstorms possible issues that could arise.
  • The facilitator can suggest scenarios.

Generate Reasons for the Failure

  • The team members work independently to create a list of possible reasons for each failure.
  • Example reasons would be funding removed, stakeholders not answering questioning.

Consolidate the list

  • Each person reads out one item from their list in turns and writes on the whiteboard, which prevents long monologues and encourages engagement.
  • The team works together to prioritise the list based on their opinions.

Revisit the plan

  • The Product Owner is provided with the list and has to approve the recommended actions. The Product Owner will only add what they feel is the top priority.
  • Approved actions are turned into user stories and added to backlog

This article is part of the our 100 Agile Tools & Techniques epic article based off the PMI list of recommended techniques and tools in their PMI-ACP certification syllabus. 

Leave a comment