Welcome back! It's time to look at the second phase of the agile scrum retrospective meeting -- the Gather Data step.
In the previous lesson, you learned about the retrospective recipe and the first part of the meeting (called Set the stage). You remember the other steps we talked about?
Here are the meeting steps, just in case:
- First, there is Set the Stage where you introduce the meeting and get everyone into the groove.
- Next up is the Gather Data step (which is what this page is about).
- Then, it's the Generate Insights step. Here the team uses the data they found to connect the dots, see patterns and connections.
- In the fourth part, it's time for Actions. Based on the insights, the team should come up with a bunch of actions... these are ideas and solutions (root causes) they should work on in the next sprint
- And finally, you Wrap Up the meeting: Summarize and thank everyone for their time.
The point now is for the team to look back at what happened since last time, with the goal of collecting as much data as possible. Everyone has their own view of this, so the group needs to get input from each and everyone, so they can create a complete picture of what happened.
In short, it's all about looking back at what has happened since last time you held the retrospective.
How much time should you spend here? I suggest maybe twenty minutes (for a one-hour meeting that is).
This Is What You Should do
Start with a meeting activity that helps the group through this part.
Now hold on a sec there, Martin! What's that... what's this activity thing you're talking about?
Well, an activity is just a time-boxed thing that helps your team to focus on the task at hand. There are lots of activities you can pick and choose from.
(I have a non-free course which teaches you everything there is to know about running awesome retrospectives. It also includes guides and step-by-step instructions to my personal favorite retrospective activities that I know works. Read more about the course here ----->)
But, Martin, what's wrong with just having a good old table discussion. That's what we always do? Well, sure, you could just let the teams loose in a free-for-all discussion....
BUUUUT the problem with
Most teams -- especially in the early stages -- can't handle free discussions very well. It tends to turn into pointless debates. Not very useful.
I'm not gonna go into the details about the reasons why that is. Maybe in a later post. So for now, just trust me on this: your team needs guidance and facilitation. Again, to learn more about these topics, you should join the complete course. It's cheap, it's good and it's worth your time. In fact, if you're a Scrum master (or something akin to it) you owe it to yourself and your team to learn this stuff.
For now, I'm gonna give you one example of an activity you can use in the gather data step: It's called Timeline and it goes like this:
Draw a timeline on the whiteboard and let the team mark events and feelings on that timeline. What this does is that it helps the group connect events to specific dates.
Again, this is just one activity, as I said. There are lots more you can (and should!) choose from.
- Draw a line on the whiteboard. Mark the far left of the line with the starting date of the period. In the far right of the line, write down the ending date of the period.
- Ask your participants to write down events that happened during their
work period (sprint). They do that on sticky notes which they then put up on the timeline.
- Ask the group to check the timeline so they see what others have put up. This may give some new ideas for new notes.
- After some time, ask the team to stop if they aren’t finished already.
- To debrief this activity, walk through the timeline and summarise what they
put upand askfollow up questions if you can see patterns emerging.
When the team fills out the timeline, they should be looking for events such as meetings, releases, policy changes, team changes or whatever they come up with. They should also look for metrics. For instance, numbers, such as number fixed bugs, tasks completed, team velocity,
Remember that facts and feelings complement each other, so you should look for both. It’s no good to have great metrics while everyone is having bad feelings about the work in general!
As for feelings, you may want to avoid using the F-word: feelings. Especially if they’re developers, if you know what I mean… So instead of asking the group for feelings, use questions like:
What did you enjoy most about your work?
When did you rather not go to work at all?
If you want to, you can also use this activity to focus on feelings.... like this:
Introduce a vertical axis (y-axis) on the timeline. This indicates moods. So if they think something was particularly fun, they should put the sticky note higher up — and put bad things lower down.
I have also used this activity with completely new teams during the forming stage (see the course to learn more info about team stages). Like this: I asked each individual to summarise the last 10 years of their professional life (or as much as they wanted at least…) by drawing a curve where they highlight events that meant something to them. Higher up means "I felt great here", lower down means "this part sucked".
This is really good stuff for getting people to know each other a little bit better!
Once they are finished with this activity, the whiteboard should be full of interesting data to work with in the next step of your meeting (Generate Insights).
That’s all for the Gather Data step. In the next part (here!) you'll learn how to make sense of all this!