Identifying and Grouping Issues for a Reverse Retrospective
In my earlier post, I described how teams might have many known and recurring issues that are not addressed through a regular retrospective. A Reverse Retrospective begins with issues captured on cards and placed on a wall by the facilitator. The participants then generate as many solutions for each issue as possible.
The advantage of this process is that all known issues are addressed, not just the few that receive the most votes in a standard retrospective.
The question then is how to identify and group the issues.
Reverse retrospectives are useful in a project rescue situation, or when there are delivery concerns being raised by the client, delivery principal or the team. Issues can typically be identified through client and team interviews, and looking at previous retrospective walls.
Sometimes grouping the issues is relatively easy – common themes will emerge, such as:
- Communication
- Lack of Urgency
- Lack of Visibility
Alternatively, logical groupings may be around customer departments, service lines, or project streams. If there are no apparent common themes, refer to the Congruence Model from “Winning through Innovation by Tushman and O’Rielly (Winning Through Innovation), which suggests four groups which will suit most projects:
- Structure (is the team organized in the best way?)
- Process (are we doing the work in the right way?)
- People (do we have the right team members?)
- Culture (is the team’s culture helping ensure success?)
Whatever themes are used, they will provide some structure for the Reverse Retrospective, and may prompt identification of additional issues.
In the following diagram, the themes are on green cards, issues on blue cards and solutions on stickies.
The team then allocates actions, responsibilities and deadlines for each issue. Often the actions are going to be in addition to the team’s usual workload, and so this should be considered when agreeing deadlines.
Whether maintaining these actions on a wall or shared document, it is good practice to provide an overview of the process and working rules for the team. For example:
Actions should be reviewed at least weekly, and action items struck out as they are completed. It is also good practice to strikethrough dates that are moved out, as it may help identify blocked actions. For example:
Reverse Retrospectives are not intended to replace the usual end of iteration ritual. However, in a situation where a team is weighed down by recurring issues throughout a project, it may provide an opportunity to refocus and have agreed actions for all known issues.
