Most Agile developers have worked in both real Agile environments and in the more traditional set-ups dressed up in Agile ceremonies.  You know the ones — where people are just stepping through the Agile motions, with “standups” in which no one stands up; and “retrospectives” where there is no honest reflection and improvement.

These fake retros bother me the most.  All week, you’ll hear people griping privately about problems with the development process, but when it comes time for the retrospective you hear a bunch of gratuitous back-patting. “Great job, everyone!”

There’s nothing wrong with giving credit where credit is due. Recognizing what went well builds a supportive team dynamic and encourages people to follow successful design patterns.

But talking about what went wrong is even more important, and that’s the part where everyone clams up. You can sense what they’re thinking: “I just told my coworkers how great they were, and now I’m supposed to throw them under the bus?” It can even get worse with blended teams, when critiquing a behavior from another team or organization feels political.

“What went well”: the Trojan Horse of retros
I recently participated in a retro where this problem came to a head. The client Scrum Master was conducting the retro via a Word doc. To add an observation, you either needed to email it ahead of time or raise it verbally during the meeting.

As you can imagine, the “what went well” category received a ton of contributions. The “what could be improved” category was suspiciously light. Getting team members to vocalize their critiques was hard enough. Asking them to put it in writing proved an insurmountable barrier.

That experience convinced me, once and for all, that retros need to be made safe for real conversations. Here’s how I do it.

Retroboard: A tool combining the three keys for productive retros
In my experience, there are three keys to holding productive Agile retros:

  • Anonymity, so people aren’t afraid to submit honest feedback;
  • Access anytime and anywhere, so that team members can capture suggestions as they come up;
  • Ownership, so ideas for improvement actually drive progress.

I built a simple tool I call a “Retroboard” for my teams to capture these elements, and we spin one up for every retro meeting. Imagine a web-based Kanban board with three columns: “What Went Well,” “What Could Be Improved” and “Action Items.” Team members can make anonymous entries in any column at any point in the development cycle. They can also upvote entries, letting teams zero in on major issues. As a rule, every item in the improvement column requires a corresponding action Item with a single owner.

The Retroboard was such a game-changer, I’ve now implemented it for every project I manage. People still compliment each other, which is nice. But now, “improvement” and “action items” take up the bulk of the discussion.

There’s nothing magical about the tool itself: you could set up something similar using your own wiki. What makes it work are the anonymous, real-time and action-oriented elements that give retros the structure they always needed.

The power of unbiased critiques
You want every member of the team to be able to raise their concerns, but coming up with a comprehensive list off the cuff could cause your retros to drag on for hours.

Personal dynamics can also affect how comfortable people feel sharing their concerns. That’s a serious problem: you don’t want team members to repeat unproductive patterns, or withhold a great idea that will give better results, just because they feel they can’t speak their mind.

An idea should never get thrown out for fear about how it will be received.

Continuous delivery needs continuous reflection
Agile principles encourage teams to “reflect on how to become more effective, then tune and adjust its behavior accordingly” at regular intervals.

But Agile also calls for us to ship early and ship often. How can you afford to stop and reflect at regular intervals with the next deployment looming on the horizon? At any point in the cycle, setting aside time for a retro can feel like grinding progress to a halt.

Reflection should be baked into the process so you never lose momentum. You might even cancel that hour-long retro meeting forever. Instead, individuals could submit a two-minute “retro” every day. At the end of the week, the team takes 20 minutes to review contributions and take ownership of actions.

Not only does this lighter pace save hours every month, it shortens the time between raising an issue and fixing it. Continuous, real-time updates keep your team on top of problems as they develop, instead of trying to diagnose them in the rearview mirror.

Every “needs improvement” has an equal and opposite action item
Retros are supposed to address what’s not working and suggest how to fix it. But often these takeaways are lost in the barrage of information. There’s no clear delegation of tasks. Five minutes before the meeting ends, someone says, “Wait… so what did we decide?”

What a time waster!  On our teams, if someone suggests an “improvement” entry, they also suggest a corresponding action item with a single owner.

This process changed our retros instantly. Instead of speaking in broad strokes, contributors now think critically about why initiatives fail. They have to dig to the root of the problem to define the way forward.

Make your retros real
Retros are too important to be unproductive, and it doesn’t take much to get them right.   

The key is to adopt a structure that enables honesty, collects feedback continuously and translates that feedback to action.