Why a retrospective meeting is a best practice for any team

Does the team complain about bottlenecks that slow them down? The same things happen over and over again? Luckily there is a simple practice that, in my experience, can help instantly. What I actually mean is, does your team take part in a retrospective meeting? No?! 😱 Make sure to adapt it ASAP, no matter which software development methodology you follow.

“Those who don’t learn from the past are doomed to repeat it.” — George Santayana

A retrospect meeting is a safe place. Everyone can say what’s on their mind without being judged for their opinions or getting negative feedback, making it a psychological safety environment. Plus, It gets everyone involved.

Besides, this kind of session pushes each team member to look back (and not forward as done daily), share their views, and eventually, learn as a team from their mistakes. Encouraging to build trust in each other is highly valuable for any team (more on that). Another essential point is that it creates a place where we can celebrate our small wins by pointing out what went well and making sure we keep doing that.

Furthermore, retros have an immediate feedback loop that promotes a virtuous circle. The team collaborates to identify low-hanging fruits and add them to the backlog.

Anything that can be solved instantly (next sprint or so) makes everyone happier (satisfied and motivated). Having more clarity on what needs to be done next, thus continuously improving the team.

Just play it safe; it’s easy to jump into the blame-game trap and weak excuses, so be careful and focus on self-reflection as individuals and as a team.

There are plenty of tools to facilitate retros (though you can do without since the idea behind it is what matters). I’ve experienced ideaboardz, a free tool to create your own board, where each participant can create and share his thoughts. Simple and gets the job done. You can test here:

IdeaBoardz - test
Conduct collaborative brainstorming sessions with distributed teams

I’ve read many recommendations about parabol but haven’t tried it myself. This tool focus on making m̵e̵e̵t̵i̵n̵g̵ work session great and its UX shows it. It has a free layer which suffices up to two teams. Among its features, you’ll find guidance through the different stages of the retrospective (icebreaker, reflections, grouping, voting, discussing). And it sends you a meeting summary at the end, so no-one needs to take notes—a must.

A different but similar tool, reetro, has many features in its free versions, such as action tracker, export to various formats, and integration to Jira or Azure DevOps. So consider that too. Lastly, if you look for activities and ideas for making agile retrospectives more engaging — go to funretrospectives.

To wrap it up

Retros create a change (in the long run), and due to their nature, changes tend to feel unclear and overwhelming. Thus, in my experience, you’ve got to start somewhere and tweak along the way. Regardless of your current practices, retros will create transparency for future activities, leading to continuous improvement.

daily.dev delivers the best programming news every new tab. We will rank hundreds of qualified sources for you so that you can hack the future.