7 Best Practices for Facilitating Agile Retrospectives

Facilitating a retro is a very powerful role; it’s almost akin to being a courthouse judge (and stenographer). By asking questions, recording testimony, and shaping the debate, you mold and influence your teammates’ feedback in a very vulnerable and trusting space. If the Product team sets goals (like a Legislature) and Development and Design teams implement them (like an Executive Branch), a retro is a chance to reflect, interpret, and set future direction—not unlike a Judiciary. In practice, that means it’s important to be especially honest and impartial, and to double-check that you’re doing justice to the team’s best interest and the speakers’ intent. Here’re a few patterns I’ve observed that help make the difference between a good retro and a bad one.

1. Explain and Enforce format

At the beginning of a retro, take a minute to explain what’s going on—even for a seasoned team, but especially for a team with new members. “We’re here to reflect and improve on process—this is a safe space, and we’re oriented towards exposing issues and taking action.” If the team isn’t explicitly aligned on why they’re in the room, they can’t get the job done. Speaking up is high value (it ensures the retro is properly oriented) and low-risk (it only takes a minute).

2. Write Everything Down Verbatim

A retro is about listening. Whoever takes notes ought to be respectful of the speakers voice. That means recording their thoughts as faithfully as possible, without interjecting opinion or commentary. If you do need to paraphrase for brevity, be as faithful to the original comment as possible—don’t insert your view, you’ll get your own turn—and confirm that your version does justice to the original. “You said ‘INSERT COMMENT HERE’ and I wrote ‘INSERT PARAPHRASE HERE’. Is that right? “

3. Categorize carefully

If you choose to categorize items, be very conservative about pre-judging what it is you’re talking about. Sure, you’ve spent the last 25 minutes talking about a few categories, but don’t jump to putting names on the buckets—that’s prejudice, and it shapes opinions. Group like items (“Are these two frownies related?”), branch out from there, and labels will emerge. Be careful that the buckets aren’t too broad to be useful; it can be tempting to draw connections among almost everything, but ideally you’ll be slicing things a little thinner, facilitating more focused action items.

4. Action Items Should Have Intent

Unclear Action Items are worse than useless. One trick is to ensure a verb is the first word of every Action Item. By definition, every action includes a verb, but sometimes the verb is glossed-over or shorthanded in the retro. Everyone in the room understands what’s meant, but afterwards that may no longer be the case. Make sure that Action Items remain actionable when viewed later.

5. Action Items Should Be Falsifiable

Be sure to frame Action Items in terms that can be assessed as “done” or not. “Refactor more” isn’t useful a useful task, because there’s no way to meaningfully tell whether it’s done. “Improve the User model’s Code Climate grade from an F to a D” is actionable, and lets the team take small, achievable steps towards improvement. Also: use Code Climate, Errplane, New Relic, Airbrake or other instrumentation services to help put objective measures on code quality, performance, etc.

6. Action Items Need a Single Responsible Party

Not two people. Not “team” or “all”. One person. When an action item involves the whole team, find a volunteer to be the cop and enforce compliance. If one person isn’t responsible, then no one’s responsible. Addendum: review Action Items. Print them up and put them on the team stand-up board. Cross them off as completed. Review the list at the next retro.

7. What Happens In Retro, Stays In Retro

The retro should be a safe place. Active members of the team should the be ones in the room; sometimes it’s helpful to include stakeholders that aren’t present for most of the week (but that’s a judgement call). Action Items may be displayed publicly, but it’s preferable to only share the raw notes with the people present.

These practices aren’t laws chiseled in stone; they’re hacks and ideas borne of observations of patterns and anti-patterns witnessed in many, many retros. Do you agree? Disagree? Have juicy, anonymized stories supporting or contradicting? Let us know (and share your best retro stories) in the comments.

One comment

Graham Siener says:

Great points. As a continuation of #6, I’ve found it helpful to enter retro items into the backlog as chores or stories (labeled retro). This helps enforce the assignment and tracking of action items, and it provides a quick check later in the sprint that retro items were actioned before the next retro.

Jonathan Berger is a designer, developer and technologist who has been active in the NYC technology scene since around 2005, helping to organize events like the Agile Experience Design Meetup, the Pivotal Labs Tech Talk series in NY, Startup Weekend, Barcamp, Fashioncamp, and IgniteNYC. He spends his days building software with Pivotal Labs and his nights and weekends working on Market Publique. Prior to that, he earned a Bachelors in Philosophy at Vassar College and a Masters in Media Studies at the New School(where he also spent quite a bit of time at Parson’s Design + Technology program). He has worked as a designer, developer, video editor, animator, and technology consultant for institutions as diverse as Eyebeam, MTV Networks, Yahoo!, Ogilvy, and the American Museum of Natural History.
He speaks about startups and technology at events like the Future of Web Design, O’Reilly’s Web 2.0 Expo, New York Tech Meetup, Fashion 2.0 Startup Showcase, Startup Weekend, North Brooklyn Breakfast Club, The Product Group, and others.
He makes it a point of honor to include Comic Sans in every design project.
Find him on twitter, github, flickr, etc. as @jonathanpberger.