Facilitator's Notes - The Retrospective Retrospective

This Agile Decision Game, The Retrospective Retrospective, takes its name as being self-referential in that eventually a good team will want to take a closer look at the ways they seek to improve. And, while consistency and reliability can be useful for effectively facilitating team events, it can also become pretty common for things to start to feel repetitive and stale. This is more about facilitation skills, having a sense of where your team is at that day/week/month, and planning how you’re going to intentionally engage with them.?

This Agile Decision Game was based on an actual situation, with a few elements added in to complicate things a bit more for participants to consider. The Scrum Master in this case also threw out their plans for that particular retrospective in favor of hearing out the team and letting things play out in a more free flowing conversation.

Its always important for the team to be able to speak up and be heard by the Scrum Master, even more so when they’re talking uncovering their own better ways of working. The tricky thing here is that the decision point with this scenario leaves off toward the end of that event. Imagine yourself as the facilitator and you’ve just been thrown a large curve ball. Your plans, your routine, your flow, your expectations–all of that has been thrown off. How do you adapt? How do you make sure that this particular team event was still valuable and useful?

First, the Scrum Master in this scenario thanked the team genuinely and expressed their appreciation for the feedback. They also offered some insight to why they would often opt for routine, predictable formats but also agreed that after so long together it was becoming stale. They took up an action item for themselves to come up with ways to mix things up but also keep some of the more tried and true methods.

Second, they also attempted a question to see if there was anything particular about the recent sprint that the team wanted to discuss or share. Since it was tacked on at the end of the other discussion and time was running short, that question didn’t really seem to land with the group and didn’t get much response.

Before the next Retrospective, the Scrum Master took the time to explore different activities for the team to explore. They broke out the timing blocks into different amounts for facilitating to see how things might fit together. They added in a better ice breaker conversation at the top of the Retrospective to help the team engage better and reframe their mindsets going into the event. Expanding their repertoire with more activities also allowed them to give the team an option at the start to choose their own activity, which helped tremendously.

This scenario can play out over 30 minutes with a group. For early rounds of discussion, avoid engaging with participants who are generally more comfortable leading and facilitating so that others aren’t influenced by others’ responses.

Pose some challenging questions based on any of the intentionally omitted information outlined below:

• This scenario left out the last team member’s opinion. How could participants try to elicit a response from that individual? Does everyone on the team need to speak up?
• Pick a common retrospective format to call out as the format that’s becoming stale. If you want to be bold, maybe use one that this group is possibly too familiar with using.
• The one Developer’s comment about shortening the Retrospective event duration might be a potential landmine for some. Emphasize that with participants to explore their thinking about streamlining efficiency as opposed to giving the team the time and space to do their best thinking.
• Is the Retrospective the only team event that has become dull and repetitive? When and how do they ask that? A valuable continuous improvement topic… but also time is running short during this meeting time, so is that too big of a discussion for now? Does avoiding that do the team a disservice?

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.