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:
[shortcake_call2action title="AGILE RETROSPECTIVES PROGRAM" description="A complete self-study program where you will learn anything that you need to become a great Agile Retrospectives facilitator" button_text="Subscribe Me" button_link="https://products.scrummastergrowth.com/agile-retrospectives-program-waiting-list-closed"/]
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:
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.
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="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." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=Agile Retros" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.