The facilitator goes around the room, pointing to each person, one by one.
“I agree with what X said”, “the Sprint was OKAY”, “The business kept changing their mind”.
Rinse and repeat.
Do these responses sound familiar? You’re probably running your Retrospectives wrong.
So what's a Retrospective anyway?
In Agile Software Development, the concept of having a ‘retrospective meeting’ can be gathered from the 12th principle of the Agile Manifesto, which is:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
More specifically, the Scrum Guide explicitly tells us to have a retrospective meeting at the end of every sprint/iteration.
It’s clear that Retrospectives let our teams be agile, but how do you retrospect at “regular intervals”?
What do I do?
To begin with, it’s important to remember the fundamental drive as to why we reflect upon our teams:
We conduct Retrospectives to ‘Continuously Improve’.
To continuously improve you need to act. Hubbard helps explains how we can do this with retrospectives in three simple steps (I’ve reworded Step 2):
1. Collect Data
So how do we get ‘data’ so that we can derive insights and ultimately determine actions to improve our teams?
Ask questions of course. Do this by setting up a retrospective meeting.
But before you ask questions, choose a facilitator to do this. The facilitator will go around the room, asking questions to each member of the team (including themselves) while documenting the subsequent answers.
Protip: “Write Everything Down Verbatim“
It’s important to note, as Rogalsky points out, that “Wording matters” and it really does.
Luckily for us, the team at Flowmotion agree and have prepared 4 great questions to ask during your Retrospectives (you don’t have to ask those exact questions, another example would be “drop, add, keep, improve“):
- What went well?
- What didn’t go so well?
- What have I learned?
- What still puzzles me?
Remember that each team member’s response should be tagged with the question (or general topic) that it applies to, so that insights can be derived after (and during) the meeting. See tagging in action, below:
2. Look for patterns
This part is a bit tricky and occurs during and after the retrospective meeting. It’s a ‘dark art’ of sorts.
During the Retrospective, put time aside to determine what the team feels is going good, what is going bad and what needs improvement. The tags you used for your team’s responses should help you do this. Then, as Creech puts it, “You want to establish patterns and figure out trends“.
You can look for patterns in the team’s responses by taking note of what is frequently brought up. Then get the team to agree on the top few. These will be used to define retrospective actions later on.
While doing this, it’s crucial to keep in mind that “retrospectives focus on the team, and not on the organization“. Don’t deviate from that.
3. Determine Actions
As you may know all too well, improving teams doesn’t just happen. Even if you find all the problems that your team is facing, you still have to act upon them.
By using the patterns you have found in the data you have collected from your team, begin to define team actions.
In my experience, I have found that there are 3 key phases in determining actions:
- Actions are agreed upon
- Actions are visible
- Place actions on a physical or electronic board
- Actions are reviewed
- Previously agreed to actions should be reviewed to measure their impact on the team
- If actions weren’t actioned, find out why during the next Retrospective
TRUST the team did their best
As you can see, there isn’t a lot to retrospectives. However, to execute them well, a lot of hard work in the right environment is required.
If your team feels they’re being judged, all the data you collect will be more-or-less useless. The Retrospective Prime Directive helps counter this by promising that:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Use this prime directive to your advantage, to make sure you can actually improve your teams.
Once you have set it, don’t go back on it . Teams are built upon trust.
What NOT to do (hint: there's a lot)
With the nature of retrospectives being so fit-for-case, bad habits can linger on for generations of iterations to come.
The retrospectivewiki.org team have come up with a great list of common retrospective problems, which can help you self diagnose if you’re doing something wrong. Here’s just a few:
- Actions not captured
- No obvious record or review of previous retrospective findings
- Biased chair
- People not speaking up
- Suffering from ‘Group Think’
- Too much focus on negatives
Doing or experiencing any of the above? Stop, stop it now.
Now do it!
It’s as easy as 1, 2, 3 – collect data, look for patterns and determine actions.
Remember that retrospectives go beyond the meeting; it’s a continuous process.
What’s stopping you from continuously improving your teams?