Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
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:
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:
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.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
Thoughtworks acknowledges the Traditional Owners of the land where we work and live, and their continued connection to Country. We pay our respects to Elders past and present. Aboriginal and Torres Strait Islander peoples were the world's first scientists, technologists, engineers and mathematicians. We celebrate the stories, culture and traditions of Aboriginal and Torres Strait Islander Elders of all communities who also work and live on this land.
As a company, we invite Thoughtworkers to be actively engaged in advancing reconciliation and strengthen their solidarity with the First Peoples of Australia. Since 2019, we have been working with Reconciliation Australia to formalize our commitment and take meaningful action to advance reconciliation. We invite you to review our Reconciliation Action Plan.