We asked our Agile Coaches:
How do you run an agile retrospective?
And they answered:
Christian:
I like to try new and creative things over and over, and I try to match the specific taste of the group. After all, we facilitate retrospectives for the people involved, and not for ourselves. By trying and adapting new formats over and over we can also showcase the agile "inspect, adapt, and learn" mindset. To be a little bit more concrete, two of my all-time favorites are, first, people reflecting in pairs and sharing each other's perspectives with the group afterward and, second, public commitment where everyone answers "what will you personally contribute next week to achieve what we have discussed today?" to close the retrospective.
Marco:
There is no Retrospective twice. I like to be creative and choose a different kinds of workshop tactics. Often the classical questions “What went well? What did not go well? What should we improve?” are hidden behind other questions, workshop formats, or games. The Foundation of my Retrospectives is: Safe and friendly environment (Vegas Rule). Liberating Structure working mode, clear definition of action items, and different time frames (look back on the last Sprint, last months, last year)
Tobias:
I strife to ask different questions every time. Nothing is boring people more than the same question every two weeks. Most of all I feel that it often leads to similar answers every time.
I also strife to show up prepared. A two-hour meeting with the whole Scrum team will easily net several working days of the team's time. So while sometimes you will have to create a retrospective plan in only a few minutes, this should be the exception, not the rule.
Ronny:
In Sprint Retrospectives we try to find ways to increase effectiveness and quality. There are many formats how to run an agile retrospective and I always like to try out new things with my team. In the end, as a facilitator, my overall goal is to keep the group focussed and help them to get to a concrete result. This could be a backlog item for an upcoming sprint, an adjustment of our definition of done, or a new working agreement for us as a team. I like to call the agreements or actions “experiments”. At the beginning of each retrospective, we review our experiments and decide together if we want to continue, consider it successful or abandon it. This way we never lose track of what we decided to try out and always check if our measures had the expected impact.
Eva:
There are many different ways to conduct an agile retrospective. Thematic or open retrospectives, working with metaphors and symbols, etc.
For me, the most important thing is to create hypotheses based on my observations and experiences with the team and then, for example, check them in an event like the retrospective. Example: New team members expand the existing team. I am deeply observing what happens to the way of working, the team spirit, and team development during this onboarding period. If I have the feeling that the team is having problems working together because of the team changes, I form hypotheses that could provide a possible reason for this.
Within the retrospective, for example, I try to check these hypotheses. It is not important whether the hypothesis is correct, it is all about recognizing what could be the cause or not. Various methods, models, tools, or metaphors can help me get the team into self-reflection and think independently about possible improvements or solutions to problems.
Amir:
Retrospectives, at their core, are about asking "How did the last iteration go?", "What parts should we change?" and "How do we change it?". Those three questions are essential for a retrospective and every retro in some form or another just asking those three. Over and over again. Good, bad, mediocre - we want to improve anything that appears. Even if everything is good, we can still improve that too, can't we?
How to run a retrospective and make it interesting - not ask the same question every time - is the part that's the challenge. Changing the style, the format, raising interest, and shifting the mindset of the participants is what gets good results. Using online tools, different props, different retrospective ideas, and making the retro engaging is what makes a good retro.
In my experience, the retro should always be "fresh", to change the angle at which the situation is observed for all participants. Repeating a single test every time doesn't change the outcome necessarily, but change the test and you get a result that gives you a deeper understanding. Apply the scientific method.
As for the format or idea for a retro itself? Play with a concept, change the questions by changing the theme. Halloween retro, dog retro, food retro, Lego retro, superhero retro... Looking at a problem through a lens that's commonplace and, more importantly, the fun will make everybody more engaged in participating.
Jakob:
We do retrospectives to learn, adapt and improve. There is always something different to find out. There are many areas of potential improvement. So we change the format to add variation, to view things from new angles, and to get improvements going. Learning is an open process, so do not limit yourself when you want to learn. But when there is a big problem, an elephant in the room, address it and look for a solution.
About #AgileSeven: We ask every month our Agile Coaches and will publish on the 7th of each month their answers. Why 7? It is a magic number.