Different ways of running Retrospectives

Question

I'm about to facilitate another Retrospective with my team. I'd love to hear what different types of Retrospectives you do, to prevent falling into a routine. How do you improve such meetings to keep people engaged instead of bored? I'd appreciate especially unconventional ones.

For me some examples are:

1. Sticky notes - putting notes on the white board - every thought is a separate note.
2. Engagement/attitude chart - you draw a timeline for the whole sprint/project and you ask each person to draw his engagement/attitude line for this time period. Values should differ from smile [:); happy/fully engaged] to sad [:(; bored, not interested in continuing the project]
3. Brainstorm
4. Voting things - you put some issue on the board and ask people to add whatever comment they want: "+1", "me too", "bullshit", ...
5. Uncompleted sentences - you ask people to complete sentences:
   • I was most satisfied with ...
   • The real pain was to ...

What other techniques do you use?

Answer 1

Some of my favourites:

Six thinking hats (mindmap)

• Blue hat (big picture) - belongs to the facilitator
• Yellow hat (positive) - what's gone well? What resources do we have?
• Black hat (negative) - what needs improvement? What risks can we see?
• White hat (facts) - what do we know? What do we need to learn?
• Green hat (creative) - what changes do we want to make? What actions to take?
• Red hat (emotion) - how do we feel about that? Is this the best we can do?

Boat variant (with post-its)

• On the left: the rocky shore.
• On the right: the beach with the palm trees and a deckchair, cocktail glass optional
• Between them: a simple boat (I tend not to use sail and anchor any more)

On the left, put all the things you're leaving behind. There may be some things you're sorry you're leaving; add a sad face (or use a different color post-it). We're leaving this land for the one over there.

On the right, put all the things ahead. There may be some things you're scared of; add a sad face. This is where we're going.

If there's anything you really want to take with you, put it in the boat!

Futurespective, twice over (post-its, also works with attitude timeline)

Useful for looking ahead rather than behind. Draw a timeline for the project or the next iteration on the board. Get everyone to walk through the timeline, then look back to the past (which is actually the present). This works better for projects and longer timelines than iterations, but it's possible to do either. I've also used this for first releases.

1st time: We failed dismally! That was awful. What happened? What went wrong? (Team put red post-its up for all the things which went wrong)

2nd time: Hurrah! We succeeded. How did we manage that? How did we address the risks? (Team put yellow or green post-its up for all the things they did right)

Anchoring (any retrospective format)

There's a tendency in Retrospectives to focus on what went wrong. As well as improvements, work out what went really well and ask the team how to anchor that. If they can't, get them to imagine that next iteration, the thing that went well will disappear or be banned or taken away. How can they stop that happening?

For instance, the team had an expert sitting with them who was really helping. When they imagined him being taken away from them, they realized he was very expensive and the manager who paid for him might not know - so they went to the manager to say thank you and explain how useful the expert was.

This is also a great technique for generating a positive, blame-free culture - how few managers ever get thanked for their decisions!

Answer 2

I always liked retrospectives in Agile settings:

Give three colored sticky notes to each person in the room. Have them write

Green sticky: What went well?

Red sticky: What didn't go well?

Yellow sticky: What could we change (start doing)?

Go around the room, one person at a time, with each person walking to a central point and sticking their green note to a board while reading their note. This always led to small, obvious groups of like-notes. Then spend some time discussing what went well (this is sometimes not done - which is odd. Celebrate and reflect on success.)

Once done with the Green, repeat with the red, and so on.

Things to note:

• everyone is equal. Directors and managers get one sticky note of each color, just like everyone else. Watch the fireworks if they try to add multiple...
• The scrum master runs things. Period. No one gets to override him or her.
• It's time boxed. When time is up - it's up.

Answer 3

Hey there, Just a quick idea about the 2nd thing you mentioned "Engagement/attitude chart". You may want to check out mercuryapp.com, it'a an app by Corey Haines (one of the major figures in the Software Craftsmanship movement) and the graph you explained just now is being drawn by constant feedback of the team. The TL can then see this and judge how the project is going along. So it's not just "when we're doing an retrospective" but constant and you could then talk about the graph when doing the retrospective.

I'm using it for myself to measure "how do I feel about this project" etc currently, and it gave me some interesting insights.

Answer 4

I've been using the ORID approach lately. Essentially, this is a four step approach that funnels the team's focus from sharing observations through collaboratively committing to actions.

• Observations: I saw... He said... The work took... There was a bug about...
• Reflections: I felt... I was reminded... I was excited by... I was surprised by...
• Interpretations: I thought... I realized... I learned... I believe...
• Decisions: I will...

When teams are able to restrain their desire to jump ahead to making decisions, I've found that they are able to stimulate a lot of new perspectives across the team by sharing the observations they each found relevant. Often, this allows a more complete picture of a situation to emerge, and allows people to express their opinions and perspectives on the different possibilities more easily. Once these perspectives are out for all to share, it's much easier to identify the solution that everybody can embrace, leading to a relatively quick and effective decisioning/actioning portion. The important thing is that the process is focused around something (a sprint, a specific bug for root cause, etc) and that the team exists with a consensus and commitment on the desired actions.

I find an effective ORID can be done on a very focused aspect in about 30 minutes, with 60-90 being ideal for broader retrospectives.

For an example about how Rally uses them, check out the example under #2.

Answer 5

When I'm not using ORID, I always include the following four stages in any retrospective.

• Brainstorm: I create an area of silence and safety, and people put their thoughts, perspectives, desires, and decisions onto a board using sticky notes. Typically, this is a 10 minute period of no conversation, merely writing and reading, and the notes are distributed into a starfish (start/stop/more/less/keep) diagram.
• Cluster: Again silently, but much more animated, the team works quietly to group the brainstormed ideas into similar topics. Often, the entire team's focused on the same problem but approaches it from different perspectives ("Stop releasing buggy code" vs. "Start doing code reviews" vs. "Write more automated tests"). I advise notating the +/-//= on the card before they start getting reordered
• Prioritize: I don't feel teams can be effective in tackling everything at once, so I use something like dot-voting to get the team's decision on which 1-3 items are worth the most discussion and attention. The rest are respected, but not carried into actioning
• Actioning: The team needs to decide on specific actions and commit to carrying through with them before the next retrospective. This creates a consistent improvement cadence. Insist on real commitments, not "we'll start...". Instead, use "We will schedule 3..."

I don't know where I got this format specifically, but I know I didn't invent any single aspect of this process (the overall concoction may be mine). I wish I had better citations.

Answer 6

Check this out: http://agileretrospectivewiki.org/index.php?title=Main_Page

I use some of scenarios from up there.

Answer 7

At my Univ. we use this retrospective "process analysis" technique at the end of first and second semester for the student group-work. It's part of the PBL model. You need to create a sort of matrix.

Rows are different aspects of the project. These would differ depending on your context. E.g. we use: project planning, group collaboration, collaboration with supervisor, learning process.

Columns are the actions. These are fixed:

1. Description, What did we do and how? In order to get common understanding.
2. Reflection, Why did we do things this way? What went well and why? What went bad and why? What did we learn?
3. Evaluation (constructively, with the 'start-stop-continue' model), what will we start doing from now on? What will we stop doing? What will we continue doing?

So the first cell in the matrix should be the description of the project planning (how did we plan our project?), and so on. Hope this helps.

Answer 8

In addition to suggestions here and many excellent sites like http://plans-for-retrospectives.com, http://funretrospectives.com, consider varying techniques to allow for introverts/extroverts:

• some activities silently, some as discussion
• some activities with movement (take a stand opening or closing), some sitting still (writing)
• to open the room for creativity, ask participants to draw, collaboratively build something or walk through a familiar scenario with a different perspective or persona
• ask for both input regarding feelings and facts (both tell you information)

Also, I’ve found setting ground rules, and asking participants for feedback on these and your retro plan can result in positive additions!

Answer 9

You could try 35 technique presented by Lyssa Adkins - see http://www.coachingagileteams.com/coachingstories/category/thirty-five/ & http://www.thiagi.com/pfp/IE4H/march2008.html#Framegame It really works. I've tried in once for retrospective and it went smoothly.

More games/techniques can be found in Agile Retrospective book http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649 It's kind of retro bible ;)