Wednesday, October 13, 2010

Agile Retrospective Example

We have a one week iteration that starts on Wednesday.  Every Wednesday morning we do our retrospective and our planning meeting back to back.  This is the agenda that we use for our retrospectives and will hopefully serve as an idea generator for yours.

The Scrum Master is responsible for making everyone feel safe and organizing and facilitating the meeting.  Safety and preparation are key and will result in a smoother retrospective. 

In your retrospective, make sure everyone feels they are in a safe environment.  Without safety, members have a tendency to not speak up.  One way to foster a safe environment is by having everyone sit in a chair in a circle with no tables.  This represents no barriers between you and your teammates.  If individuals not on your team are attending your retrospective and do not contribute to a safe environment, ask them to not attend but that you’ll review the retrospective with them later.  This allows communication between those individuals but also allows topics to be discussed openly.

Before the meeting begins, have post it notes handed out, extra pens available, and any other needed material ready for the taking in addition to the circles in "The Soup" drawn on a whiteboard (more explanation to come).  The more prep work that is done at the beginning, the smoother the meeting will go.

At a high level, here's the agenda for our retrospectives:

1.  Set the stage
2.  Gather Data
3.  Generate Insights (The Soup)
4,  Decide What To Do (Action Items)
5.  Close the Retrospective (Thanks)

Set the Stage

Welcome the team to the retrospective and go over the agenda items.  During this stage, we also review the swim lane board to make sure it is accurate.  You'll undoubtedly have someone say, "Oh, that's done", so a quick look at the board is useful. 

Gather Data

First, we want to gather data on how the iteration went.  We want to get each team member's feel from both a technical and process aspect on how the iteration went.  What problems arose, how can we address them, and, most importantly, what are measurable action items can we do to improve the situation?  We do two activities: the Happy/Sad, and the Good/Confusing/Painful activity as described below:

Happy/Sad Activity
Purpose:  Get a general feel on the team's morale of the iteration.  We do this first so that this represents one's own personal feelings on how the iteration went and does not allow other team members to influence your decision.
Material:  Whiteboard, pen
Time:  5 - 10 minutes
Process:  The Scrum Master will ask the team "Were you happy or sad with how this iteration went?" then each member will respond and the score will be tallied.  A team member should not defend their answer, the reason(s) should be revealed in the second activity.
Good/Confusing/Painful Activity 
Purpose:  Gathering data on went well versus what didn’t and what was confusing
Materials:  Whiteboard, 3 different colored post it notes, Pens
Time:  30-45 minutes

Pass out a few pieces of each post it note color and a pen to each member of the team.  For 3 minutes (use a timer), have the team write down memorable events during the iteration with the following criteria:
Green Color -> Item that went well for this iteration
Blue Color -> Item that was confusing
Red Color -> Item that was painful or didn't go well

At the end of the 3 minutes, collect all of the post it notes and organize them into categories on a whiteboard.  The number of categories will vary depending but keep the number of categories no greater than 5 categories.  Once the post it notes are categorized, have each team member vote twice on which categories they would like to discuss.  They can vote twice on the same category or split them.  Once the votes are tallied, discuss the top 2 categories.  Place a 10-15 minute time box for each category for team members to discuss, more in depth, cards they put on the wall, and how to improve the situation.  Don't feel as if you have to draw it out to the maximum time, if a category's discussion has ended, go onto the next category.  If you have time left over from discussion, ask the team if they want to discuss the third most popular category.  Make sure a time box of the remaining time you have left is for the last category as to respect the time.

Generate Insights

Take the cards from the discussed categories and use them for The Soup Experiment.  This will give the team different perspective on the cards written.  It will help clarify whose responsible for what.  If there are a lot of "painful" cards in team control, then this clarifies items that the team needs to work on.  At this point, come up with action items (assign them to an individual, if you assign it to the team, they'll never get done!) as to how the team can improve the situation, or experiments that the team can try for an iteration to try and improve the situation. 

Close the Retrospective

Thank the team for their time and move onto the planning meeting.

Tips/Tricks from my experience:

  • Don't be overwhelmed!  The first few retrospectives will take longer but will become shorter over time.
  • Let this be an avenue where team members can voice their concerns and solutions but refrain from talking exclusively on the negative items.  Talk about what went well and how to maintain that!
  • Action Items:  these are important and will reflect on how effective retrospectives become.  Come up with measurable action items, assign them to a person, and, most importantly, follow up with the status at the next retrospective.  If items are under the team's control, do everything possible to complete those action items sooner rather than later.
  • Limit your action items to between 3 - 5 items, take the highest priority items.  It's easier to remember 3 - 5 items versus 20 plus they are more likely to get done.
  • Switch up your retrospective activities!  This will keep the meetings fresh and not get people into a rut.  Check out the book "Agile Retrospectives Making Good Teams Great"
  • Remember to time box activities as much as possible to respect team member's time.