In this post I share what happens before I facilitate an agile retrospective.

Most team I joined approach retrospectives as something that has to be done once a week in 1 hour and you don’t need any preparation.

In my experience that’s when retrospectives yield more basic results and in the worst cases become counterproductive.

Before a retrospective–any meeting in my opinion–you must prepare.

Granted you can’t come up with a plan that’s perfect. You work in a complex adaptive system so be ready for the unexpected. But you can take care of some due diligence and I’ll explain my approach in this post.

The first question is what’s your role? Are you an external facilitator? A team member? A lead developer, product manager scrum master? If you feel like you’re overstepping your role by following this advice maybe treat it like an experiment. See how it goes. For the longest time I was a developer when I designed and facilitated my team retrospectives.

We’re all biased but if you’re a scrum master or a team member probably even more. Be aware of that and maybe ask for a co-facilitator or co-designer external to the team.

Is there a retrospective purpose?

With teams of 6/10 I like to run short 1:1s or watercooler convos about what’s on the team member’s minds. If I see a pattern I propose that as the retrospective theme before the retrospective. Always check with the group before making that call final and designing the structure.

Tip I learned the hard way: When you focus your retrospective on a theme you must have a way for the little low hanging fruit to be tackled. I like to do that in short 10/15m daily retrospectives. Those are action item focused. The themed retrospective is focused on reflection.

The theme might be coming from the person “leading” the team, or if you’re an external facilitator from the stakeholder that brought you in. If you have time try to check in with the team anyways.

That theme should hint at the purpose. You can do this investigation inside a retrospective that has purpose of “improving what we did this iteration” but you’d spend time doing that sifting instead of reflecting. It’s very contextual sometime you might want the group to do that but in my experience I prefer to prepare a theme before. And if the group has a topic or a theme emerging different than what was planned I go with it. It’s their meeting. If the majority of the room expresses desire to explore other direction. This is where you–the facilitator–need to get out of the group’s way. If you’re a product manager, scrum master, tech lead that’s gonna be very hard to let go of your bias and your agenda.

Next is the retrospective design.

The retrospective design

This is so that you don’t pick a random format on retromat print it and walk in the retrospective.

Here’s a few questions that I like to ask once the theme is defined:

• Who’s gonna be there?
• Why are we taking their time?
• What do we want to get out of this?
• How are we getting there?

The last question is where I design the retrospective with activities that fit the group and the context. This is the plan and no plan survives contact with the enemy. So don’t be married to it. That’s where the complexity of this facilitation job is. And why I love it.

Examples

Void of context they might not give a lot of insights but these are examples of retrospectives design I helped other folks with. Those sessions would take anything from 15 minutes to 30/40 minutes. Groups size were between 6 to 20.

Conclusion

Have I sparked some intrest in dedicating some time finding a theme and designing your next retrospective? Are you already doing it? How much time do you dedicate to it? Who helps you? Leave a comment or a tweet.