Tips for Retrospective Facilitators

When Diana Larsen and I teach a two-day Leading Agile Retrospectives workshop, the second day is stand up facilitation practice. We create the bare bones story of an iteration, then the class works together to design a retrospective. Each participant has a chance to lead an activity. And Diana and I offer feedback and facilitation advice.

Having done this more than a few times, I've noticed that we repeat the same advice in almost every class.

My colleague Mark Kilby asked what that advice was, so here it is (at least some of it).

When you ask the group a question, give people enough time to answer. It can feel a little disconcerting to stand there in silence, but people--especially introverted people--need time to collect their thoughts before they speak.

Count to eight s-l-o-w-l-y. If no one has answered, count to eight again. If there's still no answer, move on.

Do some of the work in pairs or small groups. Not every discussion or activity needs to happen with the entire group. Doing some activities in smaller groups or pairs adds variety, makes it easier for reticent people to state their views, and limits the possibility for voluble or dominant people to own the airwaves.

Let the group do as much of the work as possible. Rather than doing all the capturing, when possible have people write their ideas on stickies (with a marker, not a regular pen) and post them. Ask one of the participants to help hang up flip charts or hand out stuff like markers, stickies, dots.

Give instructions in chunks. If you are using an activity that has multiple parts or requires movement, break up the instructions. Even if the instructions seem simple to you, people are not likely to retain them if they are hearing several steps at once and having conversations between steps.

Start by stating the purpose of the activity: For example, "We're going to do use a use a special type of diagram to help us understand which issues are causing most of our difficulties." Wait for questions.

Then give the first instruction. "Please from groups of three." Wait until people are in groups before you continue...or say "In a minute, I'm going to ask you to get into groups of three. Let me tell you what I want you to do in the small group." Give the instruction.

Once they've done than part, give them the next instruction.

Provide a key when you color code anything as part of an activity. (for example sometimes I'll do a timeline with yellow=technical issues or events, blue=team issues or events, green=organizational issues or events.

If you get lost in an activity or something happens that you don't know quite how to handle, pause and reset. No one can be perfect, so get good at recovering gracefully. It's okay to say, "This isn't going the way I thought it would. Is this useful to you?" Always have a back up activity, just in case.

Use wide chisel tip markers in dark colors for writing on flip charts or white boards. Dark blue, dark green, dark purple, green and black are easy to see. Fun colors like orange, light green, turquoise are hard to see from a distance. Red is okay for younger people, problematic for people over 40. Use those fun colors to accent, but not for text. (You can buy boxes of Mr. Sketch dark colors at www.artsuppliesonline.com.)

Write BIG, and use sentence case when writing on flip charts or white boards. It's still sort of surprising how many people stand in front of a flip chart and write letters 1/2 inch tall. Write BIG. People can read sentence case more quickly than they can read ALL CAPS. Capitals are okay for headings, as they create a visual cue.

While I'm on the subject of flip chart writing, there's something about visual field when you are writing BIG on a flip chart that makes it difficult to spell correctly. It's nothing to do with you (or me). Really. It's because your brain can't take in the entire word as it does when you write on a smaller scale. Declare a General Spelling Amnesty, or put a spell check button on your flip chart when you make a mistake--you'll probably get a laugh.

Put dying markers out of their misery. Really. Throw them away (unless they are refillable.) They are useless, worse than useless, because they make you think you are capturing something the group can see, when you aren't and they can't. Throw them away, now! (I visited a company where people held onto dead markers. When I asked why, they told me they were the only markers they had, and the secretary wouldn't order any more. So wrong, on so many levels.)

Okay, that's enough for now.

A Retrospective Report

John Wilger has posted his experience leading a release retrospective. It's a nice description of the flow of the retrospectives, and shows how activities help people get beyond superficial and habitual thinking.

In summing up, John writes:

Before we held this retrospective, I think some of the team members felt that we would not gain much from doing a full-day retrospective this time around. We had made good progress on our action items from the previous retrospective, and the general feeling was that things were going basically well. What could we possibly need to change?

People, please don’t hold retrospectives only when your team feels like there’s a problem that needs to be dealt with. If you hold retrospectives on a regular basis, whether you feel like you “need” to or not, you will uncover issues before the become problems. In our case, we managed to uncover a number of issues during our retrospective that could easily have grown into much larger problems if we didn’t bother to think about them until the effect was obvious.

Found Treasures

I was at a friends house this morning and picked up a book she had out as she worked on a course. As I flipped through the pages, it look sort of familiar, and when I came home I found it on my bookshelf.

More than 50 Ways to Build Team Consensus (R. Bruce Williams) is chock full of activities that teams can do to clarify their vision and goals, build commitment to task accomplishment, engage participation. (I have the 1996 paperback edition. Don't remember how much I paid, but it was less than the price quoted on amazon.)

I wouldn't do all of the activities (I'd skip the team song, for example); but if you work with a team and are looking for some ideas on how to get people on-the-same-page, talking, and engaged you'll find some helpful ideas.

Making Retrospectives (and Other Meetings) Work Better

I know it's not sexy to pay attention to making meetings run better. It's more fun to dig into tools and technology. But the truth is that an teams and companies waste an enormous amount of time in poorly run meetings.

But, we need to pay attention to the basic stuff, or we won't have a sound foundation to do the fun stuff. It's about disciplined execution.

There's a class of issues that seem to come up for new retrospective leaders (and new meeting facilitators in general). You can read about them (and what to do instead) here: Five Tips for Retrospective Leaders and Meeting Moderators.

Enjoy.

Improving Retrospectives

A friend forwarded this email to me:

I just wanted to share a tip that has made a world of difference for our scrum. I read through this book about 4 months ago



And have implemented some of the practices in it. This has taken our retrospectives from being a 1 hour meeting where we went around the table and said what was good and what wasn’t (and then never really changed anything) to a full 3 hour incredibly productive conversation that the whole team participates in and we actually implement the changes that we propose in! It’s been a complete 180 from a meeting that was a waste of time to something the team looks forward to doing at the end of each sprint.

So if you haven’t read this book, I really recommend you do and try out some of the things in it (even if you think they are a bit cheesy and that the engineers will never tolerate it). It’s a quick read (3 hours tops for the whole book) and will at least give you some ideas for improvement of your retrospectives.

Woohoo! This is the highest praise an author can receive. (I don't think the activities are cheesy!)

And, for your reading pleasure, two recent articles on retrospectives:

Making Retrospective Changes Stick

Eight Reasons Retrospectives Fail (And What You Can Do About Them)

Two more ways to gather data in retrospectives

If you've been holding iteration retrospectives for a while, you know that timelines get old after a while. But when team skip the data part, each person works from his own data (which other people may not know) and his own interpretations (which other people may not share). That means that the team is less likely to come up with actions that have broad support.

So here are two more fairly quick ways to gather data for an iteration retrospective.

Diana describes FRIM, an activity that looks at the frequency and impact of events, impediments and boons that affected the team during the iteration. Use this as input into analysis and to decide on experiments and changes for the next iteration.

Jean Tabaka used a sailing metaphor to gather data at the Retrospective Facilitators Gathering retrospective. She asked us to identify events, interactions, etc that put wind in our sails. Then she asked us when we were in the doldrums, becalmed or held back by tides and current. We put up the "wind in the sails" stuff behind the boat, filling the sail and the doldrums stuff in front of the boat. The metaphor helped keep us out of habitual thinking and automatic categorization. And it was kind of fun.

Agile Retrospectives review

I just came across this nice review (written by Brad Appleton) of Agile Retrospectives: Making Good Teams Great on AgileJournal.com. For me, "useful" is the highest praise for a book.

Face to Face Still Matters

There's been a discussion going on the the Retrospectives list on how to do distributed retrospectives and planning meetings. The assumption is that it's cost prohibitive to bring the group together.

People always site cost as a barrier. It does cost money to bring people together face to face. There's lodging, airfare, time not spent on billable activities... and all these are easy to count.

But what this thinking doesn't take into account are the costs of not having the team face to face for planning and retrospectives:

Less collaboration, greater misunderstandings, continuation of us/them dynamics (be they ever so subtle there's always differences in access to power, information, and resources), miscommunication, etc.

And there's lost opportunity to build relationships and trust which short-cuts many of those problems.

But all those are hard to measure and quantify, and are almost always left out of the cost equation. People look at the costs without any of the benefits.

Even when you have access to great technology for planning, retrospectives or other forms of collaboration, face to face is still superior for communication and collaboration in the moment and in building a foundation for future communication. Face to face is superior in building shared commitment and infusing a project with energy.

The Prime Directive, continued

George continues the exploration of the Prime Directive.

Appreciative Retrospectives

Diana Larsen has an article on Appreciatative Retrospectives posted on the AYE Conference site. Appreciative retrospectives build on strengths and look to create the circumstances that enabled people to be at thier best.

(Diana will be one of the guest presenters for the 2007 AYE Conference.)

Asking powerful questions

Diana Larsen responded to a question about using questions in a retrospective:

Questions should lead the group through the group thinking framework of the retrospective. For example, for a continuous improvement goal:

setting the stage: “In a word or two, how are each of you doing today?”, then outline goal and review working agreements;

gathering data: Look for facts/events, “As you think back over this iteration, what events or instances stand out? What did you see and hear that sticks in your memory?” and when the group has answered those questions, move on to looking for responses to the facts/events, “How did your energy flow over the course of the iteration? When was it high or satisfying? When were the low points?”;

generate insights: “Now that we have a full picture of what happened and how we responded, what would you recommend we keep doing the same, do more of, do less of, start doing, or stop doing altogether?” and “What are the implications of each if we do?” “Looking at our keep, more, less, start, stop lists, which actions would have the greatest impact on our work or our teamwork?” ;

decide what to do: “Considering the impact of each of the items on our list, which of them do we have the most passion/energy to take as an action or experiment during the next iteration?” “What one or two will we select to include in our iteration planning meeting?” (A recent conversation with Esther brings the last two questions to mind. We actually talk about this stuff in our spare time too. )

close the retrospective: “Who owns each action item?” “How will we know when it’s complete?” “What can we do to continue to improve our retrospectives? What should we keep doing, what should we try differently next time?”

When I want to reflect on a very short period of work--a meeting, a pairing session, a workshop day--I use questions for the entire retrospetive, which may last only a few minutes. Those few minutes can make a big difference in increasing effectiveness, improving results, and maintaining working relationships.

For more on using questions to help people think and learn together, check out The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (ICA Series)

Prioritizing with dots in a retrospective

People come up with all sorts of ideas and potential changes in retrospectives--usually more than the team can digest in one retrospective or, for changes, more than they can do in the next iteration. I often use dot voting to help the team prioritize and choose what to work on.

Usually, I give every one x number of dots (I use a highly unscientific algorithm to determine the number of dots each person receives), then ask people to vote on which they believe will make the biggest difference to the team.

Last week I tried a variation on dot voting after the team had come up with a long list of issue to analyze (it was a release retrospective, so they were looking at a few months of work).

Rather than use one color as I usually do, I used this scheme:

First round: Each person had 4 green dots to mark the issues that would make the biggest difference on the next release.

Second round: Each person had 4 orange dots to mark the issues where the people in the room had influence or control.

Third round: Each person had 4 yellow dots where to mark where he or she personally had interest and energy to work on an issue.

At the end it was clear that there were issues that would make a big difference, but no on had energy to work on them. And it was clear where people felt they could actually make a difference.

(Since this was a release retrospective, many of the issues crossed organizational boundaries and couldn't be solved within the team.)

Faced with a long list of issues, three-color dot voting worked to winnow the list down to a manageable number of items for the team to tackle.