How retrospectives in Google Docs prevent your team from improving

Reflection without action makes things worse

It’s our belief that any team with aspects of Agile in their DNA that doesn’t hold itself accountable for improvement is defeating the purpose of being Agile. We’ve given tips on how to bring accountability to your team’s retrospectives because they deserve so much more than one-person with a checklist or a photo of a whiteboard in Slack. When your retrospectives become festering, repetitive discussions without action, you negatively shape the trust and confidence of the team over time — you take its hope away.

The trick to a retro or health monitor, isn’t the exercise itself, but the action you take afterwards.
 — Dom Price, Head of R&D and Work Futurist at Atlassian

The opportunity to discuss and improve things as a team is sacred and rare outside of most development and engineering teams. The impact it can have on team health and productivity should not be ignored, and failing to take advantage of that is a huge miss. So it baffles me when I hear about teams running their retrospectives in Google Docs. Of all of the Trello, whiteboards, or sticky notes solutions for retrospectives we’ve come across — Google Docs has the most negative impact on accountability.

1. Setting low expectations for accountability

Here’s how a retrospective is closed using Google Docs. *Closes tab* That’s it!

At least with a whiteboard, someone on your team will be compelled to take a photo of it and post it in your Wiki or team chat. Without a recap or connection to the team’s chat or project management tools to keep things top of mind, you are effectively archiving the action items the second the meeting ends — never to be seen again until the next retro.

Google doesn’t intend to do you any favours in terms of accountability either. Without the concepts of due dates, tagging, recap functions, chat integrations beyond deeplinking, or integrations with project management tools — your team’s to-dos are stuck there.

2. Weaker discussions

The retrospectives we’ve seen run through Google Docs were typically ongoing lists with a new page break or section for each sprint. It would be re-shared sprint after sprint and the team would add to it. It would contain the format the team used broken out into vertical bullet point lists as the metaphor for columns and topics. Action items would get their own bullet list below that. And that was about it.

When you limit the meeting to text and bullet lists, you strip out all of the nuance that comes from an effective retrospective. Say goodbye to voting, comments, sorting, code snippets, visuals, dates, grouping, labels, timers, authors, due dates, or tagging. By having the discussion without many of these, your team is not going to be able to identify where the areas of attention should be.

Plus, what you end up with is a list of things that were said and no idea how your team felt about them or who even said them. It’s like comparing a fossil and a dinosaur. They’re directly related but it’ll take a massive effort to discern what the facts are when you compare the meeting and the notes.

I have been a champion GSuite user for more than a decade like the rest of us. It is excellent. It is so good that I think its pricing actually hurts SaaS companies who get compared to it. But Google Docs is not a retrospective tool in any way. If anything, it’s a handy archive but that’s it.

Do you use Google Docs for your retros? Let us know and we can help you get started with a tool built specifically for retrospectives in Sprintlio. Message us here or visit