The 5 most asked questions about retrospectives

The 5 most asked questions about retrospectives

Guest blog by Marc Löffler.

During the last few years, a lot of people approached me with questions about agile retrospectives. Interestingly, some of the questions are asked over and over again. So I’d like to use this chance to answer the most asked questions about this topic.

Where to get ideas/activities for retrospectives?

There are many places nowadays, to get ideas for retrospectives. If I search for some ideas how to facilitate my next retrospective, I love to use the so-called “Retromat.” It is a website which randomly generates a plan for your next retrospective. If you don’t like one of the proposals, you can easily skip browsing through the catalog to find your best fit.

Another place to look online is the “Retrospective Wiki.” The list of activities is not that big, but there are some nice gems, you can use.

If you prefer to read a book, I can recommend the following:

• Fifty Quick Ideas to Improve Your Retrospective
• Retrospective Handbook by Pat Kua
• Getting Value Out of Retrospectives

And if you wait another few months, you can also download an English version of my German book, which contains some activities, but also helps you to create your own ;)

Should the Product Owner attend the retrospective?

Asking this question is already a sign, that there is something wrong in your context. It implies that there are silos within a team, that don’t belong there. The Product Owner should definitely be part of the team and not some external role. In the best teams I worked with, the PO is sitting with the team, in the same room and yes, even at the same time. That should be the normal case and not an exception. To make things clear: The Product Owner is just another role WITHIN the team, so why would you exclude a team member from your retrospective? If you think about excluding the PO, this should certainly be a topic in your next retrospective.

How to facilitate retrospectives in distributed teams?

I want to make one thing clear right from the beginning: nothing beats a collocated team. As soon as only a fraction of a team sits even in a different room in the same building, the productivity drops. The same applies to all meetings of the team, e.g. the agile retrospective. Nevertheless, distributed teams are becoming more and more of a norm. As there are no ways to avoid distributed retrospectives, the following tips may help to cope with them:

• Try to do at least one collocated retrospective every quarter of a year.
• Be prepared. Nothing is worse than setting up the whole video conferencing, while it has been already started.
• Have a facilitator in each location (for each team) and have a short preparation meeting with them.
• Use an online whiteboard, like Web Whiteboard or the whiteboard function in Skype for Business which is available in more and more corporations. Here you can find a list of additional tools. Or use a fully featured online tools like Retrium to facilitate your retrospective.
• Have clear rules for who is talking when and don’t forget about the people on the phone/Skype/Google Hangout.

These are basic rules. If you adhere to them, you are already right on track.

Should I use retrospectives in Kanban?

The first step in any Kanban implementation is “Visualize YOUR workflow”? Kanban is not a process on its own. It starts with what you already have and keeps on improving from there. If you had a Scrum process before you started with Kanban, your process looks like Scrum, at least in the beginning. If you enjoyed doing retrospectives and were able to establish a nice continuous improvement process, why would you kick this practice out? It is correct, that there is no rule in Kanban, that you have to do a retrospective in certain intervals, but there is also no rule that tells you to avoid it. So the simple answer is: Yes, why not. And if you find out, that you don’t need it anymore, this is fine, too.

Nobody cares about the retrospective’s results. What can I do?

There are numerous reasons for this behavior. But most of the time this happens, because the team does not believe, that any of the actions will have a lasting effect on the organization. Their experience showed them that there is no real purpose in retrospectives anymore and that’s why they are a waste of time.

This problem mostly occurs, when there is no real follow-up on the decided actions of the last retrospectives. If you are lucky, you are working in a team that at least checks, if the last actions were implemented. But nearly nobody checks if the actions had the expected effect. For me, every action at the end of a retrospective is nothing more than an experiment.

Nobody knows if the execution of the experiment will bring the desired effect; your hypothesis. That’s why every good experiment should also have a clear, testable hypothesis that you can check at the beginning of the next retrospective. Only if you check if your experiment was successful, it makes sense to move on. If your experiment failed, you should start a new one, until your hypothesis came true. That way, you ensure, that your retrospectives are purposeful. And if they are purposeful again, people will start to care again.

In case you are interested in Agile Retrospectives I am at the moment preparing an AGILE RETROSPECTIVES PROGRAM. This is a complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator.

Picture Credits To:

Andrew Steele