Retros are a core element of an agile work environment and offer the possibility for a team to review the achievements and difficulties during the last sprint. A retrospective runs as follows: starting with an introduction you set the stage, then there follows sessions to gather data and generate insights. Finally, according to the topics that arose, there are action points that are agreed upon to try out in the next sprint and the retro is closed.
At Stylight we have agile coaches who empower the teams to continuously improve and help to remove upcoming obstacles. The opportunity to facilitate retros is open to everyone and is an important step towards more self-organized teams. I had the opportunity to facilitate the retros for a team at Stylight for three months and have some interesting things that I discovered during this time.
First of all, the magic rule: if you ever have the possibility to facilitate a retro on your own, don’t just start right away and jump in at the deep end–it was very helpful for me to have an experienced agile coach on my side at the first retro I did.
And, as always, every new adventure brings exciting news, but also some issues. Here are some problems I faced during my experience (and you might face too!) and the right tips to solve them in the most lean (of course) way.
- BE CLEAR AND HONEST: One thing that’s super important, always be yourself and honest with the team you facilitate. No one wants to see a puppet doing a retro, and everyone easily forgives your mistakes–and you will definitively make mistakes at the beginning. Be honest about your expectations and intentions, maybe your uncertainties about whether everything will work out well and so on. So better clarify at the beginning that you are a newbie and that some things might go wrong, nobody will be mad at you at the end.
- HOW TO CONNECT COLLECTED DATA AND FUTURE STEPS: The most difficult thing about every retro, for me, was the uncertainty about how to connect between gathering data and decide what to do. It was never easy knowing how to integrate the insights I already had from setting the stage and from the gathering data, to the actual decision about what to try the next sprint. Sometimes it also felt there was no specific topic to tackle within the next sprint directly, but nonetheless it was good that the team clarified a few things that they had in mind and that were unspoken until then. This can sometimes be a quite intimate moment for the team, so better hold back a little and let important things come to the fore.
- WHAT’S THE RIGHT DURATION?: I often had the problem that my retros were rather too short than too long. This might be unusual–so far I’d only heard about it being the other way round. But I guess as long as you offered everyone in the team the possibility to speak his or her mind, this is not a big issue. Better try to focus on the important stuff than confabulate about anything that might not be important in the end. Nevertheless, it is not easy to find the right handling for the team, whether you should let the team keep going, or whether you should be stricter when guiding them through the retro. In my opinion you should leave as much as possible to the team, but be aware that some guidance is needed, even if it is only a brief ‘thanks’ after the statements of the team members; this is how everyone knows to carry on and nobody feels lost.
What I learned: the Festival Experience example
After a few retros I felt self-confident enough to try things on my own, which means not only to follow well trodden paths, but to make up things by myself.
I love drawing, so I spent a lot of time, or should I say a lot of nights, on creating visualisations on flip charts and crafting gimmicks–I’m sure that I have to improve on efficiency there, but the team appreciated my work a lot, I guess this made things a lot easier from the beginning on. What I’d already struggled with before was that most of the retro games didn’t fit together very well, or more precisely that I missed the bigger story. So I decided at short notice to do things differently this time.
My plan was to do a retro with the umbrella topic: festival visit. I started over and I tried the stuff I already knew. First of all, I needed something to set the stage:
For me setting the stage in a festival setting could only be one thing, the outward journey. So I offered the options whether it felt more like friends picked you up at home and you had great fun on the way, or you had to wait two hours in a long queue in the rain to get your ticket. This should offer a first insight about how the sprint felt to the team in general. Next up was gathering the data.
As I always struggled with my retros being too short and having problems with the steps gathering data to final actions, I split up the gathering data to expectations before the sprint and how the sprint felt afterwards. As an example, in the first part I wanted to tackle the expectations the team had at the start of the sprint, so I asked which melodies they had in mind when being on the way to the festival. And I asked them to phrase those expectations, hopes, and things they longed for as song titles. The results were very surprising, from ‘Hakunamatata’ to ‘Highway to Hell’.
I used these insights during the retro for the final retro game. There the team imagined the last song at the concert, where the thoughts drift away and where they think about things they want to improve on. A dot voting decided about the topics that were discussed in detail last.
I was very surprised how few things are dependent on yourself, but rather depend on the team itself, the whole thing is really about being a facilitator, offering a stage where the team can act. The positive feedback of team members joining the retros keeps you going–believe me, it will be one of the best experiences of your life so far!
|By Stefan Tippelt – Business Analyst|