Retrospectives and feedback loops are at the heart of any successful Agile/Scrum implementation. They’re the tool we use to help teams improve. Yet in two day introduction to Agile classes they often get glossed over. Lacking time trainers (including this one) often race through the topic outlining only one simple type of retrospectives. The problem is a single approach to retrospectives make them boring and over time people lose interest in participating.
Brian Lawrence, gives a quiet retrospective format that works well for a large group or people who don’t have experience working together before. He get provides the team with a supply of 3x5 index cards or sticky notes, perhaps even different colors for the different categories. He gives the group 20 minutes to fill out cards for what went well and another 20 minutes for things that need improvements. Then the facilitator places the cards on the wall, grouping them by topic. The team take the remaining time to decide on actionable items.
Jimmy Bosse, suggests that retrospectives are so important that no matter what happens they’re always required. He explains that retrospectives give the team the power to change and improve, without them problems and bugs become a game of CYA, with lots of finger pointing. Instead of a focus on how to improve the situation.
Yves Hanoulle, replied saying:
For me saying “NEVER stop retrospectives” is wrong.
Never and always are not agile words. Never use themI agree when a team would want to stop this I would like them to do a root cause analysis to see what is behind that request.
Doug Shimp, was asked the question: Should notes from the retrospective be posted publicly. He replies that rather than posting the notes team goals and learning's are the things to share. Even then he urges caution pointing out that some improvements taken out of context can turn into an HR issue.
Jason Little, set about creating a retrospective room for an occasion when one coach can’t be everywhere. He included:
- Nice big room with lots of open area.
- An area with information: “on the value of retrospectives, a sample meeting format and a sample checklist of things to do before getting started”
- A basket with a “Retrospective toolkit” containing the supplies of an Agile Coach: Stickies, Markers and handouts describing various techniques.
Jason’s sample agenda:
- Decide on a focal point
- State agenda and do appreciations
- Brainstorm what went well, what didn’t go well in context of the focal point
- Brainstorm stop/start doing things
- Create action plan
- Re-usable area for well/not-well stickies
The Agile Retrospective Wiki has a number of activities that aren’t well known including:
- 6 Thinking Hats Retrospective
- Pillars Of Agile Spiderweb Retrospective
- Appreciative Retrospective
- Top 5
- Plan of Action
- Start, Stop, Continue, More of, Less of Wheel
- Each One Meets All
- The Complexity Retrospective
- Force Field Analysis
- Pomodoro Retrospective
- Retrospective Surgery
- Questions Retrospective
Christopher Avery has written about the subtle benefits of Retrospectives:
- The Retrospective is a chance for the team to act like a team, hearing every voice, integrating their perspective and reaching consensus on how to move forward in the next iteration.
- “Closure: it’s difficult to start something new when something else remains mentally or emotionally unclosed”
This reporter has written a basic primer on running good retrospectives, I put the emphasis on the positive things that happen in the previous sprint/iteration (Appreciations and calling out what worked well) before focusing on the things that could get better. This way we elevate the mood of the team so we have to discuss difficult issues it will occur in an environment where people have a very positive mood. In addition I believe that its key to create small SMART goals as action items for the next iteration and post them in the team area. Without this the improvements will be lost and team members will lose interest in retrospectives as nothing improves.
Over at the ScrumDesk blog they talk about using the Speed Boat Innovation Game:
The principle of the game is to draw a boat with couple of anchors and engines. The boat should be named to represent a focus area (especially if you are going to examine large group of problems).
Ask team members to write what is slowing down the boat (one idea per card) and to pin the card to anchor. Let team members to write ideas what can speed up the boat and pin cards to an engine. After that you can apply grouping, sorting and/or voting the same way as you know in retrospective in agile/scrum.
We created couple of boats during our session. People presented a lot of ideas without any hassles and what more, they freely promoted possible/expected solutions that were immediately changed into action items for directors.
Finally Matthew Bussa provided some tips and tricks:
- 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.
Previously on InfoQ: Key Elements of a Successful Agile Retrospective: Preparation and Participation and Retrospective of Retrospectives.
