Retro on the Go

Introduction

Retrospectives are nothing new! It is not a novel concept that was conceived by the founding fathers of Scrum. Have you heard of a "Post Mortem"? No...not the examination of a dead body, but the discussion of actions taken during an important project, usually involving a large team (such as the development of a response to an RFP) after the project has been completed. These were what we called retrospectives back in the 1980s, 90s, and early 2000s before Scrum exploded on the scene. The one thing Scrum Masters do well is take an idea that has been around for a while, tweak the idea, and "re-brand" it to make it seem all nice and fuzzy. So retrospectives have been around quite a while and now it just has a nicer, less morbid name.

Problem

The one thing that I dislike about retrospectives in Scrum (and post mortems as well) is that the discussion and analysis happens after the fact. Just think of when a post mortem happens - after you're dead. Right?!? Wouldn't you have liked a doctor to come to you ahead of time and say "Hey Todd, put down the salt shaker. Your blood pressure is too high and it's going to kill you." The same is true for a retrospective in Scrum. It usually occurs at the end of a sprint (iteration). The feedback or recommendation is old and stale by the time you have your team retrospective and 9 times out of 10, the team has forgotten the problem or at a minimum has forgotten important details.

Why wait to discuss issues or recommendations or acknowledge successes? Discuss them as close to when they occur so that the information and experience is fresh in peoples' minds and your team can take action to address the problem. I know some people will say "That's why a sprint is only 2 weeks, so problems can be corrected and feedback addressed." Well, what happens if you are in the first couple of days of the sprint or still in the first week? You waste an entire week where the problem is still there and possibly getting worse. Don't wait to have a formal retrospective meeting. The action is over and you've squandered the opportunity to address the issue when it would have made more of a difference.

Solution

I have started using a concept that I like to call "Retro on the Go". Each sprint or each quarter, I create a Retrospective Board where my team members can post anonymous feedback, acknowledgements, recommendations, etc. anytime. I recommend to my team members that they post their comments as close to when they experience the retro "worthy" event as possible, so the information is fresh in their minds. Then every day before the team's daily standup or weekly backlog refinement/grooming meeting, I check the Retrospective Board for new items. We then discuss the feedback during the daily standup and immediately determine whether a corrective action is needed. If, indeed, a corrective action is needed, we take it immediately, thereby limiting the lag normally associated with the formal sprint retrospective.

How is Retro on the Go different than what other Scrum Masters are doing? If you do a quick search on Scrum Retrospectives, you'll find that most Scrum Masters have bought into the idea of "gamification" or turning the formal team retrospective into a game to "tease" the feedback out of the team while making the retro "fun". Do you know how developers have fun? They code! You know how they really have fun? They develop code that gets used by large numbers of people. Do you know what happens when you ask them to spend an hour or two in meetings per sprint that takes them away from developing software? They stop having fun. Don't bore your team by asking them to play "Retro from a Hat". Let them do what they love and spare them a couple of hours of meetings by having your Retro on the Go.

Summary

There is ZERO reason to wait for a formal team retrospective. Capturing, discussing, and taking action on feedback, acknowledgements, and actions as close to when the experience happens is truly Agile. Try it out with your teams. It will save them time and may improve the way your team works together. And I can guarantee that your team will appreciate it.