A retrospective is a meeting held at the end of a project to review what happened and learn lessons that can be applied immediately to future projects. This document outlines the structure of a retrospective, which involves setting the stage, gathering information from the team about what went well and challenges faced, identifying insights, defining actions for improvement, and closing the meeting. The goal of this particular retrospective is to find ways to strengthen teamwork.
2. What is a retrospective?
A ritual held at the end of a project to review
the events and learn from the experience
n agile
throughout
and benefit from those lessons immediately
3. Hopes Concernsand
I hope to…I hope to…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I’m concerned
that…
I hope to…I hope to…
I hope to…I hope to…
I hope to…I hope to…
I hope to…I hope to…
(for this session)
8. Answer The Questions
1. What are we particularly good at doing in our team?
2. What are we particularly not good at doing in our team?
3. What are the main unsolved impediments at this point?
4. What are the biggest successes since the last
retrospective?
Let’s reflect on what it is that you are all here to do, and what concerns you may have. Let’s see if we can match these hopes or addresses these concerns throughout this workshop
Ok, time to move on.
Let’s look at the structure of a retrospective. How do we start, what do we do and when do we end?
First we set the stage and then we gather information after which we try to gain insights. Then we define actions and close the retrospective.
Looks a lot like any other meeting, right? There are some important differences that are necessary to make it a success.
It’s important to start slowly, by setting the stage.
Not only the first time a team is holding a retrospective is it important to restate the goals of this meeting.
Like every other meeting, it is held for a special reason, we want to look at our process as a team and use the brainpower of the group to improve ourselves in the future. We try to improve the way we work together, the things we use, the things we make, the interactions we have with the rest of the organization, improve quality, boost productivity, …
Make sure that everyone is reminded that the retrospective is a meeting in which everybody is free to share his views, without judgment or ridicule. Corporate hierarchies do not exist, every issue must be addressable.
It helps to create a set of rules together that need to be respected during the retrospective. It is an intense meeting, in which we need full attention and commitment. For instance by agreeing to shut down our phones we can avoid unpleasant interruptions.
You can repeat these rules briefly at the start of every retrospective to make sure they’re not forgotten.
Sometimes it may be necessary to review these rules and update them.
If that’s clear and everyone agrees, try to get everyone relaxed and open them up to speak. You can use the check-in exercise we did in the beginning of this session where everyone just answered a random question. It breaks the ice and affirms that everyone’s participation is welcome and appreciated. It also opens up shy team members. If you’ve spoken once, you are more likely to speak again.
Another thing to do at the start is to explain the structure of the meeting. Explain the agenda and timing so people have something to hold on to. Structure helps to keep the meeting going, so that it doesn’t wonder off into thin air.
If you’re working with a new team, people might not know each other very well and are not aware of each other’s different views and backgrounds. That’s why it is a good idea to do some exercises in the first retrospectives to create a mutual understanding.
The exercise two truths and a lie can trigger a group to get to know each other better which makes it easier to understand each other and overcome their differences.
As a last thing before jumping into the retrospective, you can try to build up the energy level by using data or artifacts that show the results of previous improvement actions. It’s very energizing to see that your effort made a difference and is acknowledged.
You already notice by the length of this slide that starting a retrospective takes some preparation and customization.
Although an iteration of a couple weeks might not seem a lot of time, people often have very different perspectives on this period.
Gathering data helps to create a shared picture of what happened. Not only for those who weren’t present during a part of the iteration, for everybody.
We can do this by gathering facts, what happened at what time? Look for data, events, features we worked on, issues we ran into.
A common method is to draw a timeline and create post-its for all these things which we place on the corresponding moment on the timeline.
The visual aspect is very important and acts as a guide during the rest of the retrospective. You can even try to capture the emotions that were experienced with each event on the timeline. For instance by giving them color codes. Green as happy, pink as sad, yellow as neutral.
Before we can start by searching for actions for improvement, we need to identify the problems areas with the highest priority.
In most cases, certainly at the start of a project, teams don’t have a problem with creating a list of improvement candidates.
The list can get very long, so we need to commit to a set which is doable in a next iteration.
Things like dot voting are a democratic way to prioritize your list and agree to subset.
Then we need to get to the bottom of these improvement candidates. It’s easy to jump onto the first idea that is thrown into the group.
The problem is that this often isn’t the best. Instead, we try to use the power of the group to come up with several ideas.
Combined with root cause analysis or other exercises to get to the origin of the issue, a group can work out the best possible solution to an issue.
The work is not finished. Solutions might be on the table, but you will find that they are often not very concrete.
In the end we need tangible actions. Actions to which we can assign owners and that can be planned into the next iteration.
If we would skip this step, you will notice that things remain untouched and the issue would be brought up again in the next retrospective.
The same way a team commits to a sprint backlog, we need to be able to commit to the action points that are distilled in a retrospective.
Now what do we do with action points that aren’t hands-on, but are more like agreements, for instance: “try the pomodoro technique for the next iteration”. I found it very usefull to already agree on how and when we are going to evaluate this agreement.
This will often lead to concrete actions for the next iteration.
Like any other meeting, we need to close the retrospective properly.
We can go over the results one more time, just to make sure they’re all sticking in our brain.
Then recap on the practical stuff: Who will capture the artifacts of the retrospective, who will make sure our action points get into the next planning meeting, etc.
Why not do a retrospective on the retrospective, this way we can also improve that part of our process.
And finally, end with a positive note and appreciation for the hard work.