Featured in
Architecture & Design

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Operations & Infrastructure

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Featured in
Enterprise Architecture

Mini-talks: The Machine Intelligence Landscape: A Venture Capital Perspective by David Beyer. The future of global, trustless transactions on the largest graph: blockchain by Olaf Carlson-Wee. Algorithms for Anti-Money Laundering by Richard Minerich.

Agile/Scrum Retrospectives–Tips and Tricks

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.

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:

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

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.

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.

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.

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."

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.

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.