Retrospectives

Here is a set of retrospective activities to use to collect different kind of outputs as needed depending on different team stages or context (new team, project completion, regular sprint retrospectives, team health check, etc.)

This is the activity I run with less frequency because the changes you can compile for this session could take longer to generate a visible impact. That's why I usually run them twice a year or when landing to a new team where I want to get a temperature check of the team health.

This retrospective pretends to collect a general overview of the team perception on a set of 5 (or more) dimensions such as: Team, Process, Requirements, Collaboration with external teams and Tools. As a result you will generate a visual to show the team where they stand strong and what areas need to be looked at. By asking additional probing questions on this areas the team creates action items to improve the areas where the team is not happy with the current situation.

The team vote with an emoji for each of the dimensions, in the end all points get aggregated for each and represented in a radar chart (ideally) . This will show to the team a visual on what are the strengths and weaknesses to put focus on. Finally triggering a conversation on how to tackle on the weakest points and how to double down on the strengths.

😃 (happy= 2 points), 😐 (neutral = 1 point), 😞 (sad = 0 points)

Radar Axis:

The end result might look like something like this:

Image: The first Team Radar retrospective when I joined my current team.

Or simply put in a table:

This is the most common activity as it is the simplest when you are running multiple iterations for a long term project. This activity can be done usually after a sprint or a project is completed.

This activity aims to get the team to be vocally self critical on the things that did not work as expected and then gather learnings that can be used to create mechanisms to prevent them from happening in future instances. The focus is on detecting opportunities for improvements in team processes specially if they are recently implemented and you want to collect feedback to improve it.

Starting with a board with a column for each input type Went Well, To Improve and Went Badly The team takes a few minutes (10-15min) to enter their inputs on each. Afterwards initiates a discussion of the things that went well and why, this is also a as good opportunity to give kudos to peers. From the To Improve column the team collects info about things that are ok but can be made better. Finally the on the Went Badly column where the discussion is oriented on identifying the root causes of what things did not work as expected and find mechanisms to prevent them from happening again.

The Three Little Pigs is one of my favourite retrospective activities, its particularly useful after a new project has been in production for a few iterations and you want to identify risks and weak points. It can also help as a post-mortem for moments when system resilience is affected generally after a spike on production incidents or system failures. This activity is a perfect fit for identifying technical debt.

The overall expectation to detect technical/operational debt and latent risks that need to be tackled promptly before they can produce real impact to your customers in production. This activity can generate the need to plan for improving the system architecture or refactoring weak points.

The team identifies what things are just about to break imminently, what things are working but could potentially generate issues if certain conditions are met and finally what things are rock solid that the team is proud of. Then a discussion is triggered on what are the risks and a prioritised list of what needs to be fixed. Also It serves as a good opportunity for the team to celebrate those parts that are rock solid and the team is proud to mention.

The 4L is an activity that I like to use after iterations where either because we made an interesting discovery or we learned something new from making a mistake. Also its an interesting activity to focus on the things we liked about how things went and think or visualise an ideal long term accomplishment.

The purpose of this retrospective activity is to document learnings after a sprint or a project has been completed specially on situations when the team discovered something novel, learned from obstacles found in the process, lacked something that was expected to happen, or longed for the existence of something that could have made things a lot better.

Similar to other activities the team starts with a board with a column for each input type, Liked, Learned, Lacked and Longed for. Then they take some minutes to reflect on each theme. The moderator puts special focus on having the team to think about the things that they enjoyed (Liked) and learned something new (Learned). And things where they learned from an issue (Learned) and they felt that something that was missing could have helped address the issue (Lacked). Finally having the team thinking about an ideal state of something that could improve the team productivity (Longed for).

This retrospective activity is specially useful for young teams that are still trying to define their set of internal processes.

The expected outcome is to identify the right set of team processes for the team to operate, identify which ones are missing, which ones are not adding any value or slow down the team and which ones the team is happy with and should keep/improve. At the end of this activity there will be processes that will be deprecated and new ones be trialed for the next iterations together with improvements to existing ones.

The team collects for each column which processes or activities the team need to start doing to improve in an area, then the ones that are unnecessary or inefficient that need to be stopped. Finally collect the ones that the team is happy with and wish to double down.

For long running projects the Sailboat activity is a very interesting one to collect insights on the team about how confident they feel about completing it successfully. Specially to identify what are the main risks of the project and what things are slowing down the team.

The expectation of this activity is to have the team reflect on what are the potential risks and obstacles that can compromise the team's ability to successfully reach their goals. Then having a discussion on how to mitigate those risks and remove obstacles.

The Sailboat activity is performed as a metaphor of the team (The boat) navigating towards their goals (The island). During the team's journey the team might encounter risks (Rocks) that can impede the team from reaching their goals. Also, there can be present handicaps or inefficiencies that can slow the team (Anchor) and prevent the team from reaching their goals within schedule. Finally the team can also reflect on what are the things that keep them moving forward (Wind) and what makes them enjoy the journey (Sun)

Here it is a quick summary of a very subjective view of how I choose what retro activity to run in each retrospective depending on the kind of inputs I'm interested in collecting from the team. The expectation is to use them to gather relevant information from the team, identify needed changes.

Follow @leadingIn_tech to stay up to date and/or subscribe to the newsletter for updates

Read the Past editions in Substack