Category: All Posts

Retrospectives serve a purpose: In the long run, we want to improve and that means trying out things. If all that ever happens is talking and nothing ever changes due to retros, then why do them? Teams quickly learn to hate retros if they don’t result in change.

So, how do you get change due to retrospectives? Let me tell you about the team with the best follow-through I’ve ever had the pleasure of working with: Each retro they added all action items and rule changes to a big sheet of flipchart paper. Each item had a “revisit”-date attached to – the date when the team thought they’d be able to judge the effect (usually 2, 4 or 6 weeks). At the beginning of each retro we would go down the list of all open items that had reached the revisit date and inspect them. Did the team do it? Did it work as intended? If yes, rule changes were made permanent and actions crossed off. If not, the items were consciously dropped or changed.

They had continuous improvement down to an art. It was a joy to facilitate their retros. They devoted a huge chunk of time to this process – 20-30 minutes out of 60. That sounds like a lot (it is!) but it worked very well for them. By the time they had analyzed the list, they usually had covered a lot of the things that bugged them anyway.

I’ve never again seen such consistent follow-up. That’s why I suggest at least a bare bones “Phase 0” to replicate this success: Bring the list of last retro’s agreements and ask what happened with them – for about 5 minutes.

This accomplishes several things:

• It lets the team know that someone cares about what happens. (Whenever I remember to, I’ll also ask during the iteration – genuinely curious, not annoyingly!)
• The team and I can spot problems with follow-through early

With a mature team, I’ll do this every once in a while. If I think there’s a problematic pattern, I’ll do it more often. I try my damnedest not to be accusing, but if the team consistently does very little of what they agreed to do, that’s points to a problem. Phase 0 helps us find this out so that we can work on the lack of follow-through.

Other peole have developed similar concepts (at least Marc Löffler and Judith Andresen). But for most it’s the “New Phase 2”, in between “Set the Stage” and “Gather Data” (from the 5 phases of a retrospective). They feel it’s important to have “Set the Stage” as the very first phase so that participants “arrive”. And I’ve come around to their way of thinking. So scratch “Phase 0”, long live “New Phase 2”!

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

(Don’t know what a retrospective is? Start here!)

[En español: La mejor retrospectiva para principiantes]

Are you new to facilitating retrospectives? Then you’re probably wondering how to best get started. For what it’s worth, here’s my “Given that I know nothing about you or the team’s situation here’s my best shot at a multi-purpose, easy to facilitate retrospective plan”:

Positive & True
Why: Create a positive vibe and give everyone an opportunity to speak.
How: Think of a question that is tailored to get a response that is positive, true and about their own experiences, e.g.

• What have you done really well in the last iteration?
• What is something that makes you really happy?
• What nice thing did you do for someone else last iteration?

Ask your neighbor the question. Then your neighbor asks their neighbor on the other side the same question and so on until everyone has answered and asked.

This will give everyone a boost and lead to a better retro.

Learning Matrix combined with Lean Coffee
Why: Learning Matrix is a great multi-purpose method that has “appreciation for others” built-in. I use it to gather topics and then use Lean Coffee to structure and time box the conversations about these topics. I rely on Lean Coffee a lot!
How: Show a flip chart with 4 quadrants labeled ‘:)’, ‘:(‘, ‘Idea!’, and ‘Appreciation’. Hand out sticky notes.

• Let team members silently write their ideas for all the quadrants onto sticky notes – 1 thought per note.
• Go around the team and let everyone put up their stickies on the flipchart. The person also  describes their topic in 1 or 2 sentences. Cluster stickies that are about the same topic.
• Hand out 3 dots for people to vote on the most important issues, i.e. the ones they’d like to discuss. They can distribute the dots any way they like, i.e. they can put them all on one topic  or five different ones and everything in between.
• Order the stickies according to votes.
• Say how much time you set aside for this phase and then explain the rules:
  We’ll start with the topic of highest interest. We’ll set a timer for 10 minutes. When the timer beeps, everyone gives a quick thumbs up or down. Majority of thumbs up: The topic gets another 5 minutes. Majority of thumbs down: Start the next topic with 10 minutes on the clock.
• Stop when the allotted time is over.

Worked Well, Do Differently
Why: Keep track of suggested action items
How: In preparation for the retrospective head 2 flip charts with ‘Worked well’ and ‘Do differently next time’ respectively. Write down suggestions for actions that people mention during Lean Coffee. State clearly that these are only suggestions for now. The team will vote on these later.

When all Lean Coffee time is talked up, ask if there are any more suggestions for actions. If so, let them write in silence for a few minutes – 1 idea per sticky note. Let everyone read out their notes and post them to the appropriate category. Lead a short discussion on what the top 20% beneficial ideas are. Vote on which action items to try by distributing dots or X’s with a marker, e.g. 3 dots for each person to distribute. The top 2 or 3 become your action items.

AHA
Why: Demonstrate the usefulness of retrospectives by asking for lessons learned
How: Throw a ball (e.g. koosh ball) around the team to uncover learning experiences. Give out a question at the beginning that people answer when they catch the ball, such as:

• One thing I learned in this retrospective

Depending on the question it might uncover events that are bugging people. If any alarm bells go off, dig deeper.

[This plan in Retromat.]

---

You need at least 1 hour of time. In many situations the above plan will result in a nice, effective retrospective for you and your team.

If you use Miro as a digital whiteboard, I’ve prepared a Miroboard here that you can copy.

Facilitate a few retros to gain experience and when you run out of ideas, Retromat is always there to help. But please don’t use the first random plan you get! Adapt it to your and your team’s needs. If you’d like some ready-made plans to get started, I wrote “Plans for Retrospectives” for this exact purpose.

To get a better understanding of retrospectives in general, read Agile Retrospectives. (If you prefer reading in German, check out Erfolgreiche Retrospektiven.)

If you’re new to facilitation in general, not just for retros, check out this 1-pager on ways to vote.

[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