Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.
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 your share your observations with the team.
Learn how to run a reverse retrospective to realign with your scrum team.
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.
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 the chief talent officer at 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:
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:
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.
Agile Transition – A Hands-on Guide from the Trenches
The Agile Transition – A Hands-on Guide from the Trenches ebook is a 212-page collection of articles I have been writing since October 2015. They detail the necessary steps to transition an existing product delivery organization of over 40 people strong to agile practices.