For effective retros, use a google doc and these three questions

I feel quite strongly that one of the most important things a team can do is the improvement of daily work.

I don't just mean producing good work — I mean improving the process by which that work is produced.

To do that, structured reflection is helpful. This often happens in the form of a retrospective meeting (aka retro).

The goal of these meetings is to get a team reflecting and collaborating to improve its own processes.

It's a good idea! That's why they're are a part of a bunch of different "work philosophies" like scrum, agile, etc.

Unfortunately, retros are often poorly run. They become dreaded events.

Here's my guide to running quick and efficient retrospectives that you'll actually look forward to.

I'll assume you've participated in retros before.

The guiding principle: compounding

Remember: the goal of a retro is continuous improvement.

This is about compounding. If you have good retros and keep doing them, you'll get better.

So, at risk of sounding silly, what you should aim for is to:

have retros that actually improve daily work
actually do your retros

This might sound obvious, but I've found that most teams fail at both of these — usually because they have ineffective retros, which are draining, so they stop altogether.

Classic mistakes to avoid

1. Going through every single task

Some teams go through every single task that was assigned and ask: "What's the update on this? Did it get done?"

If you do this, prepare to see everyone's eyes glaze over.

Updating tasks in a meeting in front of everyone is a huge waste of time. It should be done asynchronously.

If your team cannot be bothered to update tasks, the solution is not to torture them by doing it on a call.

There's likely an underlying problem here: misaligned expectations.

If you're the manager, communicate to the team that documenting work is a part of the job.

Treat this as a first-class expectation: discuss it in your 1:1s and performance reviews. It will improve.

Focus your retros on improving daily work, rather than documenting it.

2. Reading everything out loud

Another classic mistake is to act as if ideas have only been shared if they've been said aloud.

This is a trap!

Keep in mind: reading is faster than listening.

Have teammates write their thoughts down and then read what others wrote. This is a core part of the process and template I'll share below.

3. Using a fancy tool

There are retro-specific tools out there, but I've found that they're not worth using.

Here's why:

There's a learning curve to these tools, whereas everyone feels comfortable in a Google Doc.

The "benefits" of these tools include things like upvoting and commenting, which you can do in text on a Google Doc.

It can be hard to copy information out of these tools and into other places, like your task tracking system.

In my experience, no fancy feature can replace the fluency that people have in Google Docs. (or equivalent)

4. Not taking down action items

It's simple enough: improvement requires action.

That said, be realistic: only write down the things that you're actually going to do.

Be clear as a group about what's a brainstormed idea vs. an action item you're committing to doing.

Assign things to people and track these action items the way you track the rest of your work.

Remember: Improving daily work is work, so you should treat it that way.

The Process

Open a google doc and paste in the three questions shown below.

In a bit, I'll tell you why I chose these questions.

1) What was your "one thing" for this sprint? Did you accomplish it?
2) What should we keep doing / start doing / stop doing?
3) Shout-outs / Thanks / Props / Kudos
---
Action Items:
[TODO: Populate this at the end of the meeting]

That's the template.

...now here's the process:

Writing (10mins)

Have everyone open the doc on their own laptop.

Each person should silently write their answers under each prompt.

Reacting / Responding (5mins)

Next, spend five minutes adding +1's to each other's answers.

These can be simple notes like +1: Dan, Sylvia

...or they can be longer notes like: [Dan]: Agreed, and we should consider automating that process

Biggest Take-away (10mins)

Finally, have each person share their single biggest take-away out loud.

As the moderator, you should not be doing a lot of talking here.

As you listen, take notes and write down action items. Use your best judgement.

Final Thoughts

I always like to ask: Is there anything that we haven't talked about and should?

In this case, you should also ask: Are we missing any action items that we should write down?

(After the meeting, put the action items in your task tracking system and copy/paste any context from the doc.)

Why these questions?

Let's break them down one by one.

1) What was your "one thing" for this sprint? Did you accomplish it?

Focused teams excel.

This question encourages focus through accountability.

It sets the cultural tone that doing one big thing is better than a million small things.

Plus, it's helpful to see patterns in what's interrupting the team's focus over time.

The ideal answer to this question is short and sweet:

[Dan]: Yes. I was investigating performance issues in the spreadsheet view. I conducted thorough profiling and documented my findings and recommendations.
[Alex]: No. My plan was to finalize the calendar integration, but I only got about halfway there — I got derailed by the outage that we experienced.

2) What should we keep doing / start doing / stop doing?

This is where the focus on continuous improvement happens.

Folks should spend the bulk of their time answering this question.

Ideal answers should include a bit of context on why this is coming up.

Examples:

[Dan]: Start discussing design decisions in the team Slack channel, rather than in private messages. That way, everyone has context.
[Alex]: Keep doing UX reviews before starting on implementation. Seeing the end-to-end user flow is really helpful and avoids rework later.

3) Shout-outs / Thanks / Props / Kudos

Recognizing other people's efforts is something that folks naturally want to do.

By providing a space for it, you can foster an uplifting environment. Over time, you'll find that thank you's and shout-outs become part of your team culture.

HOWEVER: Be cautious of reading this section out loud (it's tempting). The last thing you want is for kudos to become a drag for the team.

Instead, encourage folks to respond in the Google Doc by leaving a quick reply.

Example:

[Dan]: Shoutout to Sophia for a great whiteboarding session on international payments! This project is so much clearer for me now!! 🙂
- [Sophia]: You bet! That was great!

Bonus Mistake: pre-populating the doc with your own answers

This is a mistake I only had to make once.

"I'll get the ball rolling," I thought.

...I was wrong.

Instead, it had the exact opposite effect: others were hesitant to add ideas, and I accidentally biased the team's answers with my own.

If your team is a bit hesitant to write things down at first, remind them that this is how we get better and that this is a safe space to note the pebbles in our shoes.

Conclusion

Every team is different, so you should feel free to adapt the questions and format.

Hopefully this gives you a good jumping-off point.

If you keep your retros simple and lightweight, your team will look forward to them.