Retro Ideas
Prime Directive
Regardless of what we discover, we understand
and truly believe that everyone did the best job
they could, given what they knew at the time,
their skills and abilities, the resources available,
and the situation at hand
In Project Retrospectives, Norm Kerth
Effective Retrospective Actions
We typically promote action that affects a small beneficial change now over waiting and planning for an action that may affect a big change some time in the future. They are not exclusive and you should certainly consider doing the big changes as well as the numerous little changes. the reason that small (and often) changes are promoted is that they may or may not have the desired benefit.
When facilitating actions in a retrospective respect the Zorro Circle (I mostly just made this up):
The first circle is the area under the team's control. These are actions that can be done by the team and will be the most effective.
The second, bigger circle, is the area outside of the team's control, but still within their sphere of influence. This will be areas that typically impact the team directly, but over which the team has no control. These actions will need to be done by someone outside of the team, but the team can potentially exert some influence in making these actions happen. These are less desirable than first-circle actions, but can still be very effective. The scrum master's influence with the wider organisation may be able to extend the reach of this second circle.
The third circle is everything else. Things that may be interesting to the team but over which they have no real influence. Taking an action on one of these items should be the lowest on your priority list as they stand the lowest chance of being successful.
Once an action has been agreed on, assign team member(s), and set the deadline. The deadline may well default to "before the next retro". Other actions will have more specific timescales.
Importantly, review the actions. Doing this at the start of the following retro can bring everyone to focus on what they wanted to achieve and spark discussion about what went well and what didn't. Those actions that didn't get done.. see if they still have value and if the team want to pursue them.
Participation
Different people will engage in different ways and in different things. Think about who’s in the retro. Is it just the Dev Team, or is the PO also there… or the Dev/Engineering Lead or another manager? Sometimes you’ll need to cut the attendance of the retro to just the dev team until you’ve proved it as a safe space. Other people can then possibly be added (like the PO) depending on how healthy their relationship is with the team. Let the team lead you in terms of who to invite.
Some people love trying new retro formats and are excited by that, others like to sit back and let others speak.
For a retro to work, the team need to trust the SM. The SM needs to have the respect of the Team, or at least they can see that the SM is trying to help the team and not just themselves. One of the biggest ways to get someone’s participation is to demonstrate that you are both listening to and hearing what they say. It’s why I include the actions in the retro notes… a confirmation back to the team that I heard their pain points and heard what changes they wanted to try.
Sometimes the only way you’ll get someone’s engagement in a retro is to try different formats until you find one that works. Not every retro will work for everyone in the team, so find one (or more) that does. If there isn’t one, then alternate between formats that between them get everyone engaged.
Don’t be shy to ask for feedback from the Team on a new retro format (just remember to ask them before the retro starts to give feedback at the end). Also don’t be shy to go to someone who you failed to engage and have a private conversation about it… be sure to really listen to what they say and think about it.