TL;DR: The Reverse Retrospective
Are you—as a scrum master or agile coach—experiencing more communication kerfuffles with “your” team? Is its speed of improvement stalling? Are you under the impression that the team is slipping back into old habits and patterns? Maybe, it is time to run a reverse retrospective where you share your observations with the team.
Learn how to run a reverse retrospective to realign with your scrum team.
Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.
Reverse Retrospective: Framing the Problem—Groundhog Day
As a scrum master or agile coach, you may ask yourself sometimes why it takes your team so long to change direction even with issues under control of the team. This might be a simple technique such as ‘put the Jira task number in red into the upper right corner of its index card, so we have a chance to read it from a distance.’ Or it could be the understanding of fundamental agile practices. For example, that insufficient product backlog refinements will likely cause spill-overs at the end of a sprint, thus endangering meeting the sprint goal.
Such moments of falling behind or not living up to the potential are particularly unfortunate when they repeat themselves. Nothing is more frustrating than a team managing to pin down problems during retrospectives and deciding to take action only to not deliver on those action items. Or, initially changing the situation for the better just to fall back into old patterns after a while slowly. It is groundhog day, the agile edition.
Cannot see the subscription form?
Please click here
Self-Organizing Scrum Teams
One of the problems from a coaching perspective is that self-organizing teams do not form when the scrum master is instructing team members regularly what to do and how to do things, probably even enforcing those “suggestions” at a later stage.
Self-organization means that the team takes care of its affairs as autonomy without accountability equals anarchy. (It is what Patty McCord—formerly Netflix—refers to as treating everyone “like fully formed adults.”)
One way out of this dilemma might be a retrospective exercise that aims at realigning the scrum team with the scrum master or agile coach—the reverse retrospective.
How to Run a Reverse Retrospective
A reverse retrospective combines several techniques from the scrum master toolbox:
- The scrum master creates stickies with issues
- The circles of influence-model by Diana Larsen allows the clustering of issues by team authority
- There is a dot-voting step to identify issues where the scrum team and the scrum master align and—more importantly—do not align
- There is a lean coffee-style discussion based on the dot voting results.
The desired outcome of the reverse retrospective is to confirm that team and coach have the same perspective on the team situation. If the retrospective reveals, that is not the case the ensuing discussion shall overcome these differences and realign the scrum team with the scrum master.
Preparing the Reverse Retrospective as the Scrum Master
The most important part of preparing the reverse retrospective as the scrum master is the identification of the issues you want to address. I start doing so in parallel with the daily work anyway by collecting lists of observations—a kind of problem backlog. I also revisit the protocols of past retrospectives and check the action items the team agreed on tackling.
I usually end up with 10 to 40 issues of various levels of severity during this step depending on the fluency of the scrum team. Some might be mission-critical while others are merely nice-to-have. Next, I rank the issues: to what extent are these impeding the team from reaching its goal, and what can the team do about them? (This ranking allows me to focus the reverse retrospective on the top 10-15 issues at hand. Otherwise, the team might get lost in the noise.)
I also like to label the issues. A simple model will do, and my model covers:
Then I transfer these issues to stickies or index cards. (I use cards of a single color.)
The room or space of the retrospective needs to be prepared with a matrix based on circles of influence-model by Diana Larsen. (See above.) I find it difficult to run the reverse retrospective on a single flipchart paper with the original circle design. A smooth wall, a large whiteboard or a window is much better suited for that purpose. Also, you need to ensure that the team has enough room in front of the wall for the dot-voting.
I also use a matrix design instead of original concentric circles as a matrix makes the exercise less complicated to follow visually: there is less overlap of stickies, it is easier to dot-vote and more straightforward to come up with action items.
The Kick-off of the Reverse Retrospective
I kick off the reverse retrospective by introducing the team to each issue explaining my thoughts or observations behind it. This should take no more than 45 to 60 seconds per point, so the introduction phase fits into a 10-minutes time-box.
During this introduction, I also place the issues into one of the three categories:
- Team controls
- Team influences
- “The Soup.”
(If you are not familiar with the terms, please check Diana Larsen’s original post.)
The following dot-voting by the team members is done with two differently colored dots: one color signals agreement on the issue at hand. The other color signals disagreement and the need for discussion. (Choose contrasting colors for this purpose. For example, red and green dots will not work if someone among the team members is red-green color blind.) The team members assign dots by relevance from their perspective.
You will end up with issues where the alignment between scrum team and scrum master is apparent. Other questions might be controversial among team members which an approximately equal number of dots of both colors. The most interesting issues are those where the team and the scrum master are not aligned.
Ranking Issues for Discussion
My preferred ranking of issues for the following discussion is as follows:
- Issues without alignment
- Controversial issues. (Roughly an equal number of both dots.)
- Issues with a high level of alignment.
The purpose of the discussion is solving issues. In the case of misalignments, this might be as simple as fixing a communication kerfuffle. In other cases, the solution might require creating a task or action-item. According to Diana Larsen, there are three categories for that:
- Direct action. (The team controls the issue.)
- Recommending action. (The team influences the issue.)
- Respond as a team accordingly. (The team has no authority over the issue.)
This categorization helps particularly to plan the next steps of improvement when the most pressing issues are of a systemic nature. Those have proven in the past to be of a more frustrating quality.
No matter the outcome, though, the reverse retrospective will likely improve the future collaboration of both scrum team as well as scrum master.
Conclusion — Reverse Retrospective
Running a reverse retrospective is a helpful feedback loop between scrum team and scrum master or agile coach to assure alignment between them on the issues that impede the team’s progress.
Consider running a reverse retrospective whenever the speed of improvement seems to slow down, communication kerfuffles become more frequent, or systemic issues hold back the team.
How do you assure alignment between the scrum master and the scrum team beyond the usual routines and ceremonies? Please share with us in the comments.
✋ Do Not Miss Out: Join the 6,500-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.