A retro recipe

I call this retro the "Post It Note and Vote" retro

Time needed: 1 hour

For: Small teams and best used as an end of iteration retro.

Props:

  • 4 Sheets of butchers paper,
  • lots of post-it notes,
  • List of retro actions from the last retro if available
  • Sharpies (or similar marker pens for writing on the post-it's so people can read them)
  • White board markers (so you don't accidentally use the sharpies on the white board)
  • Index cards (for writing actions on)
  • A watch to time the retro
  • Print out of the "Prime Directive "

Timing:

  • Intro: 5 minutes
  • Set up: 5 minutes
  • Post it phase: 10 minutes
  • Discussion 10 minutes (includes grouping)
  • Voting: 5 minutes
  • Final discussion: 30 minutes - includes agreed actions
  • Wrap up: 5 minutes

Intro

Thank everyone for attending the retro and read out the Prime Directive, making sure everyone hears and understands the principles.

Review any retro actions from last sprint and briefly discuss whether they were carried out, and to what result. This is not the time to go into too much detail, if discussion threatens to break out, tell them to make it a topic for the current retro.

Ask an icebreaker question: It is important at the beginning of a retro to give everyone an opportunity to speak, it will free up conversation later. Examples of the kind of icebreaker questions can be:

"If last sprint was a colour, tell us what colour it was and a short sentence explaining why?" Make sure you ask and receive a response from everyone in the room.

[Optional] Room temperature:
At this point, depending on the teams feedback or make up, you may want to test the temperature in the room regards whether people are feeling free to speak. There are various approaches to doing this, heres one from:http://www.retrospectives.com/pages/Anatomy.html
"Since there were managers in the room, I wondered out loud if it would be safe to say what needed to be said. To find out, I had the group use secret ballots to show how safe they felt. Two people indicated that they did not feel very safe at this point in the session."
You'll need to decide how you want to manage the information you get back, whether to proceed or take another approach.

Set up

Explain the format of the retro as per below:

Format of retro:

Basically, we will be hand out post it notes to all team members. Ask them to record short notes on the 3 headings: "What worked well, What didnt work so well, What puzzled me" When they have finished recording this information, place the post it notes under the three headings, gather like notes together and than vote on which group of notes to discuss further. We will than decide on actions as an outcome of these discussions.

Optional - Set Max actions:

Ask the team to set a limit on the number of actions that they will commit to out of the retro. I have found that typically a good number of changes / improvements to commit to for a 2 week sprint is around 5. Anymore than that and you may not complete them all. This leads to a devaluing of the retro process as people lose faith in the likelihood of change being followed through.

Set up continued:

Place 4 pieces of butchers paper up around the room. and write the titles on top of each one [You could of course do this earlier, but it helps to do this in front of the team, as you can than describe the section headings as you do it]:

1) What worked well [Things that worked well within the sprint, from the trivial (blah blah bought donuts) to the important (We reached our sprint goal)]

2) What didn't work so well [Events within the sprint that may have impacted our ability to deliver, negative or distracted us]

3) What puzzled me [Technology decisions that I didnt quite understand, why was so and so asked to do something et, generally more important at the beginning of release cycles, but a useful data gathering exercise non the less]

4) What to do differently. [This is where you write the actions from the discussions, not to be used in the earlier team data gathering exercises]

Data gathering [Post it] phase

Hand out post it notes and pens to everyone.

Ask the attendees to put any observations of the sprint onto the post-it notes, these observations should be able to be grouped under one of the three categories. When they have written a number of post-it notes up, ask them to stand up and stick them under the appropiate marked butchers paper. As the group come up to place post-it notes under the headings, ask them to group their post it with others that are basically the same if possible.

Variation: Ask people to ensure that if they place items in the "what didn't" column, that they place at least 1 item in the "what Worked" column. It is easy to focus on "negatives" and this allows good things to be outed. We want to make sure that things that worked are noted, discussed and we continue to do them, or in fact improve upon them. You will be surprised by the things people mark as successes.

Allow all the attendees to place their notes on the butchers paper, ensuring you keep an eye on the time. Ensure everyone has placed at least one note up on the butchers paper. Once this phase is over, thank everyone and than move to discussion of the notes. Go through each post it in turn, grouping items together where possible with the permission of the note authors.
On each note, ask the author to briefly explain thier note, only enough so others understand the high level detail. (This also serves to get everyone involved and people feel that at least their input was heard). Ask the group this question: "Do you now understand enough about this note to potentially vote for it?" Discourage too much discussion, with a firm but fair: "Sorry, we will discuss this note further if the votes/team agree that this is a priority" This helps keep the time in this section down.

Voting:

Once this step has been completed and aall notes have been discussed and grouped,a ssign a number of votes per person. The number of votes you should assign each person is important, as you want their to be clear favourites and a good pattern formed. A format I follow is:

5 people in retro - 5 votes each

10 people in retro - 3 votes each

Voting rules: Explain that we will discuss the highest priority item(s) decided by number of votes.
[Variation 1] Each person can vote only X times (as per previous) but can stack their votes on one post -it, or spread it across multiple. If they feel particularly storngly about something they may want to vote it up.
[Variation 2] Each person can only vote for one item once, this ensures a more even spread of votes across the issues, but may mean there is a lot to discuss.

Encourage everyone to come up as a group, this may help ensure that team members voting last have less opportunity to 'swing' discussion.

Final Discussion and Actions:

Tally up the votes and than starting with the highest number, facilitate discussion based around the theme of the notes. Ask the note writers to elaborate and look for actions the 'team' agree to and write these down on the "What to do differently" column. Allow discussion to flow, but try to limit each voted area discussion to below 5 minutes. Move on the next voted area until the time is used up. Ensure each agreed action is assigned an owner ("Team" is allowed). Set a time limit for completion of the action (or a date), try to ensure they are actions that will be carried out within the next sprint.

If the team set a Max Actions limit at the beginning, either, stop recording actions when they reach that limit or group actions/ remove some to continue. Otherwise, keep collecting actions for the alloted time and ask the team if they are happy to commit to this list. If no, trim some, if yes move to next stage.

Wrap up:

Thank everyone for attending, and record the actions the team commited to in an agreed area (either stick up the butchers paper, or a personal favourite, write them down on index cards for the team to play on their sprint board.) The main thing to remember is that getting these actions visible is important. Tidy up the room and get out of there!

Comments

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Software and Elephants - you won't believe how thin an elephant can get!

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.