BT

Agile/Scrum Retrospectives–Tips and Tricks

by Mark Levison on Dec 16, 2010 |

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 them ;-)

I 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:

  1. Decide on a focal point
  2. State agenda and do appreciations
  3. Brainstorm what went well, what didn’t go well in context of the focal point
  4. Brainstorm stop/start doing things
  5. Create action plan
  6. Re-usable area for well/not-well stickies

The Agile Retrospective Wiki has a number of activities that aren’t well known including:

Christopher Avery has written about the subtle benefits of Retrospectives:

  1. 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.
  2. “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.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

More Retrospective Activities by Diana Larsen

Mark,

I like the way you've synthesized a variety of perspectives in this article. One size certainly doesn't fit all, in retrospectives as well as life.

To add to the resources you've listed, I also post new retrospective activities on the FutureWorks blog to supplement the ones in our book, Agile Retrospectives: Making Good Teams Great!. I categorize them under "retrospectives."

Happy Retrospecting, everyone!
Diana

Boring retrospectives by Nick Oostvogels

Me and Laurens Bonnema have a session about how to keep your retrospectives interesting and creative. You can find the slides at slideshare. There's a fun part about retrospectives anti-patterns in there as well.

Great topic!
Nick

flexible framework for retrospectives by Esther Derby

Hi, Mark -

Nice!

I put up an outline of the framework Diana and I use on slideshare www.slideshare.net/estherderby/agile-retrospect....


Esther

Re: More Retrospective Activities by Mark Levison

Thanks Diana - I wonder how I missed your blog in my attempt to catalog the world.

Cheers
Mark Levison

Re: Boring retrospectives by Mark Levison

Thanks for the comment Nick, I continue to be surprised by the range of interesting retrospective ideas.

Cheers
Mark Levison

Tailor retros to the team's needs by Dave Nicolette

IMHO one of the most challenging things about putting the retrospective to work is keeping the sessions relevant to the team's needs. I'm working now with a team in a technical capacity while a colleague, Cindy Bloomer, is in the ScrumMaster role. She crafts each retrospective to the team's needs. We've used several of the techniques listed in the article from the Wiki when the team "needed" to develop in the area of team dynamics or "human factors." On other occasions, the retros have been technicall-focused, dealing with architectural issues, coding standards, and so forth. There's no single "best" way to handle a retro; it depends on what the team needs at the moment and their level of experience/comfort with the idea of retrospectives. It's one of the hardest aspects of this style of work.

REtrospective - A Learling by tushar jain

In my view retrospective, is a learning process and with each team it should adapt without compromising basic thought. I have keyed in my thoughts at blog.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT