More often than not retros feel empty, if not forced. Folks just adding cards because they feel they have to have something good to say. I chose this to encourage groups to think and decide what needs focused attention to amplify.
I posted a retro format I made on twitter the other day. I guess it got some attention. Probably because I made the letters “retro” map to categories for discussion. How witty...I know.
Anyhow, here it is, in all its glory:
If you think it's not very original, I wouldn’t disagree. It’s inspired from the “starfish” retro and Alistair Cockburn’s “try, keep, problems” format from Crystal Clear.
But it is a little original...but only a little. Here’s why I chose each word:
Want to know a secret? I don’t really like the “what went well” or “celebration” portions of retros. More often than not they feel empty, if not forced. Folks just adding cards because they feel they have to have something good to say. But skipping it felt wrong too. Groups would be missing valuable information about possible improvements. Especially if “what went well” was something small or serendipitous. So I chose this word to encourage the groups to think about those things and decide if any of them need focused attention to amplify.
By the way, I don’t hate celebrations. But if you want to have a meaningful retro around what went well, have one that focuses on only that. Oh, and maybe include individual appreciations.
Continuing the theme of things I don’t like about retros; I’ve come to really dislike the “what didn’t go well” phrasing. Clearly these things need attention but I often see the phrasing lead to defensiveness or blame. I chose the word “explore” to encourage the group to approach topics that “didn’t go well” with factual information, making it clear when something is one’s perception. Then, continue to explore the situation more deeply, focusing on “what” over “why”. And finally move forward exploring options to try.
One cautionary note: Try to figure out if something that went wrong is a common issue or was a one off. It’s not a great idea to create new policies to address a one-off problem. If the group truly feels like it must do something, throw it in the “observe” bucket for now.
Alistair’s “try, keep, problems” format was my first ever retro format when I was learning the agiles back in the day...so maybe this one is just nostalgia for me. But I always liked the lack of constraint around just wanting to try something! Not because anything needed support or something bad happened...just good ol’ fashioned “hey, what if we did X?”.
The only thing to add, as with any improvement, is to discuss why you want to try something and what you expect to see happen. Basically, frame a mini hypothesis and experiment. Doesn’t need to be too fancy or heavy handed...just intentional.
It’s easy to fall into the trap of continuing to add or change processes and practices. And while doing so is certainly needed for improvement, an overarching goal I’ve always appreciated is improvement through simplification. This could be the same as “stop doing” from the starfish retro. However, sometimes extra effort is needed beyond just stopping to thoroughly remove a process or practice. This is especially true when the thing being stopped crosses any boundaries such as roles, teams, leadership levels, departments, etc.
This category serves two purposes. The first is to review any ongoing experiments. This includes reviewing anything that was previously discussed in “try”. The second is to capture any “hot spots” or areas of worry that the group would like to keep an eye on. I find this a useful outlet when groups aren't certain about what or if it should do anything to address an issue.
The only note here is to not let items live in observe forever. If they are experiments, decide what time frame is appropriate for deeming it a success or failure. I highly encourage using a minimum success criteria for this. If it’s something to just keep an eye on, decide soon if it needs to be explored more deeply and change made or if it was just a one-off occurrence.
So, that’s it - the format in a nutshell.
One thing to keep in mind, if you’re just looking for a new format to keep the group engaged, my advice is that you may be barking up the wrong tree. Different formats can be useful for nudging people to think about things through a slightly different lens. But if you’re struggling with engagement, often it's because the group doesn’t find the time valuable.
The main reasons I’ve seen for lack of engagement in retros are:
If you use the format above, I’d love feedback...good or bad. Or any other thoughts on these ideas. Find me on Twitter @mattbarcomb
Here’s a secret you didn’t know: Developers hate your retros. Not all developers and hopefully not all of your retros, but at some point, a developer has sat in one of your meetings and thought “this retro sucks”. You might wonder if this is a problem, but at the heart of agile lies one key concept, continuous improvement.
In order to keep your team retrospectives productive in the long-term, there are a couple of proven tactics you can use as a facilitator (but also as a team member). To make sure your team is excited for this meeting and you’re leading the team down the path of actionable takeaways, keep these following best practices at bay when you are planning or hosting your upcoming retrospectives.