All About Retrospectives

[There’s a German version of this text.]

A retrospective is an opportunity to learn and improve. It is time set aside – outside of day-to-day routine – to reflect on past events and behaviors. In its simplest form you answer 3 questions:

• What worked well?
• What didn’t work well?
• What are we going to try to do differently?

In none-agile environments retrospectives are sometimes done after a project is finished as a “post mortem” to derive “lessons learned”. Those tend to be long meetings.

In constrast, in agile environments, a retrospective is short and done often (e.g. 90 minutes at the end of a 2-week sprint). Thus the project is still in progress and you can address issues jeopardizing the project’s success in time, hopefully keeping it on track.

In Scrum, retrospectives belong to the cast of regular sprint meetings. In Kanban there’s a variety of ways to “schedule” retrospectives. In Lean A3’s can serve the same purpose.

Who takes part?

“The team” whoever that includes in your context. In Scrum it’s usually the whole Scrum team with dev team, PO and SM. If you have a specific topic that includes / affects people from outside the team invite them to work on a joint solution.

What does a retrospective look like?

In its simplest form, a bunch of people

• meet
• talk about stuff and
• agree on some actions (that will hopefully improve the situation).

Usually retrospectives are a little more sophisticated than that. Most follow the 5 phases suggested in “Agile Retrospectives“:

1. Set the stage
   Set the goal; Give people time to “arrive” and get into the right mood
2. Gather data
   Help everyone remember; Create a shared pool of information (everybody sees the world differently)
3. Generate insight
   Why did things happen the way they did?; Identify patterns; See the big picture
4. Decide what to do
   Pick a few issues to work on and create concrete action plans of how you’ll address them
5. Close the retrospective
   Clarify follow-up; Appreciations; Clear end; How could the retrospectives improve?

You can support each phase with activities to spark ideas and interaction. Look at the Retr-O-Mat to see examples for such activities.

What is a retrospective NOT:

• A blame game – Retrospectives are not about ass coverage and assigning blame. In fact, some facilitators start their retrospectives by reading out the “Retrospective Prime Directive“:
  

  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.

  Concentrate on what you will do in the future.

• Just another meeting in which talk is cheap but no change follows – If the retrospectives don’t produce concrete actions or if no one carries them out afterwards, retrospectives are a waste of time.

If you like the idea of retrospectives, Retromat can help you plan them and this 1-pager helps you teach others about retrospectives. Looking for ideas for your first retrospective? Try this plan.

PS: Did you know there's a Retromat eBook Bundle? Ready-made retrospective plans for beginners and all activities from Retromat for experienced facilitators. Check out the Retromat books

When you first learn about retrospectives you might wonder why you would do them. In Scrum, they are even Scrum. But why? What is so great about agile retrospectives? What purpose do they serve?

If I had to answer in one word, I’d pick: “Change”

The point of a retrospective is to enable change. Improvement. It’s reserved time to look at how we are working together as a team and tweak that. Retrospectives deal with the mushy, human side of work and how to collaborate better. In my opinion, retrospectives enable that in 3 major ways:

• Allow time for (self-)reflection
  During the daily grind it’s incredibly hard to sit down and ponder your ways of working. Reserved time helps.
• Create shared understanding in the team
  Everybody sees the world a little bit different. In retrospectives we can find out how our team mates perceive and interpret events
• Agree to try new things: action items (or updates to the working agreement)
  Retrospectives give room to think through several improvement ideas and pick one that all team members commit too

If done well, the retrospective itself is a pretty powerful meeting. Sometimes the increased understanding between team members – knowing what makes the others ‘tick’ – is already a great leap forward and builds trust.

Most of the time though, you will want to end with concrete action items i.e. experiments. Small things that the team will do to see if it helps with one of their problems.

During any given retrospective you don’t know if an action item will be an improvement. You have to try it out. If it turns out to be an improvement you keep it and build on it. If it’s not, you stop doing it and try something else if the original problem still needs solving.

Warning: Implementing action items takes time. If you do retrospectives but nobody ever has time to follow up on the action items people will quickly grow disillusioned. They will stop doing retros because, frankly, there’s no point if nothing ever changes as an effect of the retros. (BTW, Scrum recognizes that and prescribes that the most important action item from the retro is automatically part of the next Sprint Backlog.)

To recap, the benefits of retrospectives are: time to reflect, creating shared understanding and agreeing on action items. All of which hopefully lead to long term improvements in how the team works together. Doing retros frequently will often allow you to catch and address problems while they’re small and still manageable 🙂

And that’s why I think retrospectives are very valuable. Do the benefits sound good to you? If so, you might be interested in what a retrospective is now.

PS: Did you know there's a Retromat eBook Bundle? Ready-made retrospective plans for beginners and all activities from Retromat for experienced facilitators. Check out the Retromat books