Everyday Retrospective

From Agile Retrospective Resource Wiki
Revision as of 13:26, 25 February 2013 by Robbowley (talk | contribs) (Created page with "__NOTOC__ While the retrospectives listed on this site are very useful I often find that they are individual activities rather than a whole retrospective plan. As such I'm put...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

While the retrospectives listed on this site are very useful I often find that they are individual activities rather than a whole retrospective plan. As such I'm putting up on here my most simple, fallback plan that I wheel out when I don't have time to prepare anything else. This is also good for when there are new team members or if I can't attend and a non-expert Scrum Master has to facilitate the retrospective.

Agenda

Assume starting at 14:00 14:00 - Retrospective Start - 2 Word Check-in 14:10 - Happiness Histogram 14:30 - Good / Bad / Change 15:00 - Dot Voting 15:15 - Identify Goals and Actions 15:45 - Retrospective Close 16:00 - End

My timings are based on a group of about 7 - 9 people who are fairly well versed in what we're trying to do and looking back on a two week sprint. I think all of the activities are described elsewhere on this website but for convenience here is the way we do it:

Preparation

If time allows then draw up the agenda on a flip-chart and ensure it is visible. Also bring the burndown chart and Sprint calendar into the room along with the story cards. Best practice for retrospectives says that having a large conference table int he middle of the group is a big no no but often I find this is unavoidable and doesn't seem to be a huge barrier if it cannot be moved. Obviously if you have access to a room without a large obstacle in the middle then choose that location. Make sure you have got some sticky dots for the voting, if not then the team can vote by placing marker-pen dots but only if you trust them not to vote the wrong number of times!

Start & 2 Word Check-in

Ask each member of the team to describe the sprint in two words. With a new team this usually results in a discussion of whether one word is enough or if three words are acceptable. It doesn't really matter but I do usually ask them to try and make it two words. I normally ask people to grab a big pen and write their words on the agenda sheet or on a white board. This means they have to stand up and move around. If we have remote team members e.g. on Skype, then they well us or IM their words and we write them up also.

Happiness Histogram

After asking everyone to review the burndown chart and sprint calendar and to remember what happened during the sprint I draw up some axes showing time on the horizontal and happiness on the vertical with neutral in the middle and happy above / sad below the horizontal axis. I put notes on the x axis for significant events e.g. planning, sprint review, and backlog reviews, important meetings, environment failures, branch merges etc. Then everyone draws a line representing how they felt throughout the sprint. If things have gone very badly and there is a senior stakeholder in the room it may be neccessary to ask them to leave while the team anonymously draw their lines. Alternatively we are now fairly relaxed and people tend to provide a running comentary while they draw the line. Whatever works for you.

Good / Bad / Change

I think this is also known as Tripple Nickels but since we're based in the UK and don't know what a Nickel is I don't like the name and rarely use it. I put up headings on a board or piece of wall like:

  • Good / Bad / Ugly
  • What went well / What went badly / What to change
  • Happy / Sad / Worrying

I change the titles if we do this on consecutive weeks, as long as they are somethign like that then it is fine. Now the team write up their thoughs on post-it notes or any small sticky bits of paper and put them on the board. If there is a time constraint on the retrospective then here is the place to save time by asking people only to write one note for each column or limit them to a total of 5 notes or something. Anythign that makes them internally prioritise. If time is not a problem then let them post away until all ideas have come out.

Next read aloud all the post-its to the team and group them into clumps where there are duplicates. Let the discussion that arises flow and add any more notes that are thought of that were missed earlier.

Dot Voting

When all the ideas are up and de-duped then distribute the sticky dots and let everyone vote. A good number of dots if five but it doesn't really matter. Make sure they know they can vote any way they like e.g. five separate things or all five on their most important one.

Identify Goals and Actions

Again depending on how much time is available, or maybe depending on how much your teams workign practices need to change, decide how many topics you have time to cover and slect those with the most dot votes. We usually aim for three. Ask the team to identify a 'Long Term Goal' and a 'Short Term Action' for each topic. e.g. for a topic of 'Too many broken builds' you might have:

  • Long Term Goal - Build is never broken
  • Short Term Action - We will write a Code Commit Checklist and everyone will follow it before commiting their code

e.g. for a topic of 'Communication with remote team members' you might have:

  • Long Term Goal - Teams are able to operate as though co-located
  • Short Term Action - We will set-up a wiki to store centrally our information about the user stories

Retrospective Close

To bring things to a close just ask the team how useful they think the retrospective has been and how it could be better next time.