Simple Circles and soup

A Better Retrospective

Inspect and Adapt (or die)

Doing an end-of-project retrospective, is an important part of the Scrum Inspect and Adopt doctrine. Learn from your mistakes or you are doomed to repeat them and all that. So when I was planning the retrospective of an especially difficult project, I decided that something different was called for. Where was so much we could learn.

Same old, same old

The normal - be it company, project or sprint - retrospective at Reload! A/S goes a little something like this:

  1. Somebody draws three columns on the meeting room whiteboard with 
    1. Positive
    2. Negative
    3. Suggestions
  2. Anybody with something to say, says it and the “driver” writes it in Pos or Neg
  3. Sometimes we find the photo of the whiteboard from the previous session and compare.
  4. When everybody is done, problems will lead to suggestions
  5. Suggestions are sometimes assigned to somebody
  6. Photo is takes of the whiteboard an put in google drive/yammer

This works quite well. It’s simple and effective. Except..

  • Stuff doesn’t always get done,
  • Sometimes we forget to publish the photo.
  • Focus is on the present, not the past (stuff is forgotten)
  • Not everybody participates. To easy to just sit back and watch.

Go Tasty

The old way is quite embedded in the company culture, and this is pretty much what people think of when they hear the word Retrospective. I really, really wanted to do something more. There was so much to learn from this project.

I really wanted to use some of the games from TastyCupcakes.org, most of the games are focused on not just getting a specific result, but also learning the users a bit about scrum and often also getting them of their feet.

I wanted to start of the session with something that would trigger peoples memories. It had been five months since the project started and much had happened. Much forgotten. Unfortunately I couldn’t find a fitting game at TastyCupcakes, so I decided to create my own.

Moodgraph

MoodGraphYou can read more about it at TastyCupcakes, but the short version is:

  1. Draw a timeline on the whiteboard (horizontal axis)
  2. Vertical axis goes from sad :( to happy :)
  3. Everybody gets up, one at a time, and draws a mood line
  4. Make comments, add new milestones as needed
  5. Discuss

This worked quite well – people participated more then I had expected and their reasons for “going sad/happy” over time was enlightning. Listening to other participants tell, what they remembered, obviously triggered more memories in everybody.

Circles and Soup

Now with our memories refreshed, I wanted something linke the positive/negative part of the old way, but different. The Circles and Soup game from TastyCupcakes, seemed like just the thing. I also hoped that it could help visualise, that a good part of the things that had gone wrong, in this projects was – to some degree – beyond our control.

I simplified the game a bit and draw this on the whiteboard:

Simple Circles and soup

Everybody got post-it notes and pens and was told to create post-its with issues relavant to the project. Positive and negative. The Moodgraph was still on the whiteboard for reference. I expected everybody to write two, maybe three notes, but the average turned out to be seven!

Now everybody turns placing post-it’s on the board, explaining what the note ment to them and why they placed it where. Was it something we had direct control over (inner circle) or something that was a given and totally outside the teams control? As more notes was placed, duplicates where identified and stacked.

circle and soup blurred

The inner circle turned out to be a bit to small – I must remember to make it bigger next time.

When everybody was done, I talked a bit about the issues that where outside our control. Where they really outside our control, and should we accept projects in the future, where we had no control over these things?

Suggestions

We then picked some of the post-it’s from the inner circle and started attacting them in solution mode. Brainstorming with notes on the whiteboard. If they where directly under our control, we should be able to do better another time. Many of the issues where facets of the same problem and where stacked besides the suggested solutions.

We decided no to go through all the issues/notes from the Circles and Soup game – this would simple take to much time. Most people had said that they wanted and had other things to do. A few spin of projects where created – adjusting the Jira workflow being the biggest – for later.

I went though the reminding post-its and wrote them all down in a wiki document, adding any information/notes that had come up doing the Circles and Soup game.

Retrospective^2

When we where done I asked people for their opinion on the retrospective it self, and everybody agreed that the moodgraph had been good at refreshing everybodies memories and that the Circles and Soup game had been a good alternative to the normal positive/negative/suggestions way. Using post-its and getting up to the whiteboard activates and thinking about the added dimensions of team influence forces a bit more reflection.

2 thoughts on “A Better Retrospective

  1. Henrik Korsgaard (@heenrik)

    Hi Thomas, nice reading. I have a question and two comments. First the question. I often find it hard to generalise anything but the obvious when doing a project evaluation, and even more in teams, because it often comes down to roles and individual learnings. So, when you sum it up in your wiki or talk about what is outside your control, how do involve these experiences in the next project? Do you use cases as reference or do you all revisit the wiki together (as part of meetings)?

    Now my comments:

    I often find that it does require to change the method, as a new approach, game or meeting-form, When you do something new it tends to get people more involved, and subsequently activate the reflection on the project. This ‘shaking things up’ is maybe more a meta-method, but it tend to work if the meetings become to stale and repetitive. The downside is to be able to ‘compare’ learnings across methods (can team-members understand the different screenshots in the wiki etc.).

    From my work studying creative process and trying to interview people on creative leaps, I have found methods similar to Moodgraph a good conversation starter. I conducted individual interviews with team members (groups of students), where they first drew a timeline over the project, plotted in the significant events (insights, sprints, design changes etc.) and then drew the fever-curve (Moodgraph) on top of it. I did not find anything surprising, but later the students have told, that the interviews was a valuable tool for individual reflection… But I still haven’t found a good way to make the insights explicit and carried over into projects (besides the obvious e.g. keeping deadline) – and I can see from the students work, that they too struggle with carrying the previous experiences into new projects. That always seem to be the hard part, especially in teams. Any suggestions?

    Reply
  2. TC Post author

    Hi Henrik,

    Thanks. Well, some people would build a huge checklist of things to remember “the next time”, but the thing is that every project is special and the rough parts are always something new. I don’t really believe in this. I take it as a collective learning experience. I do know that the next time, something similar comes up, I’, going to take the drag factors a lot more serious, we have a few technical adjustments and we are currently working on getting a lot more behaviour driven…

    Reply

Leave a Reply