Last updated on | Agile Retrospectives General

Are You Aware Of The 5 Most Asked Questions About Agile Retros?

by Mark Loeffler
agile retros


During the last few years, a lot of people approached me with questions about Agile Retros. 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.


There are many places nowadays, to get ideas for Agile Retrospectives. If I search for some ideas how to facilitate my next Agile Retrospective, I love to use the so-called “Retromat.” In this blog, you can find other ideas right here.

It is a website which randomly generates a plan for your next Agile Retrospective.  If you don’t like one of the proposals, you can easily skip browsing through the catalogue 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 lovely gems, you can use.

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


A complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator

Subscribe Me


Asking this question is already a sign, that there is something wrong in your context. It implies that there are silos within a team, which don’t belong there. The Product Owner should 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 standard 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 Agile Retrospective?

If you think about excluding the PO, this should certainly be a topic in your next Agile Retrospective.


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 group, e.g. the Agile Retrospective. Nevertheless, distributed teams are becoming more and more of a norm.

As there are no ways to avoid distributed Agile Retrospectives, the following tips may help to cope with them:

  • Try to do at least one collocated Agile 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. Luis published a blog post: “21 Mandatory Tools For Distributed Agile Retrospectives“, there you can find a list of additional tools. Or use fully featured online tools like Retrium to facilitate your Agile Retrospective.
  • Have clear rules for who is talking when and don’t forget about the people on the phone/Skype/Google Hangout.

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


The first step in any Kanban implementation is “Visualise 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 Agile Retrospectives and were able to establish an excellent 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.


There are numerous reasons for this behaviour. 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 organisation. 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 Agile Retrospectives. If you are lucky, you are working in a team that at least checks, if the previous actions were implemented. But nearly nobody checks if the actions had the expected effect. For me, every action at the end of an Agile 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 Agile 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 Agile Retrospectives are purposeful. And if they are purposeful again, people will start to care again.


We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery.

Take The Test

If you liked this article, feel free to visit my company Products and Services pages.

We provide Team CoachingAgile Training, and Agile ConsultingOKR TrainingOKR ConsultingInnovation Training and Innovation Consulting.

With my team, I built 5 main products: High Performing TeamsScrum Team CoachScrum Master MentoringOrganisational Mastery and the External Business Accelerator.

Rate this post:
Mark Loeffler

About Mark Loeffler

Marc Loeffler is a keynote speaker, author, and agile coach. Before getting in touch with agile methods and principles in 2006, he was working as a traditional project manager for companies like the Volkswagen AG or the Siemens AG. His passion is to help teams implementing agile frameworks like Scrum and XP and to transform our world of work. Marc has a passion for helping teams that are struggling with agile transitions and overcoming dysfunctional behaviour. He loves to generate new insights by approaching common problems from the other side and trying to make deliberately havoc of the process.


Share your point of view

  1. I just like the valuable info you provide on your articles.
    I’ll bookmark your blog and check once more here regularly.
    I’m reasonably sure I’ll learn a lot of new stuff proper right here!
    Good luck for the next!