Why using Google Docs as an agile retrospective tool hurts your team
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 agile retrospectives because they deserve so much more than one-person with a checklist or a photo of a whiteboard in Slack. When your agile 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 agile retrospectives in Google Docs. Of all of the Trello, whiteboards, or sticky notes solutions for agile retrospectives we’ve come across — Google Docs has the most negative impact on accountability.
1. Setting low expectations for accountability
Here’s how an agile 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 agile 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 agile 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 agile 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 an agile retrospective tool in any way. If anything, it’s a handy archive but that’s it.
Do you use Google Docs for your agile retros? Let us know and we can help you get started with a tool built specifically for agile retrospectives in Sprintlio.
