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.)
Twice a year or when landing to a new team.
Collect a general overview of the team health, collecting team perception on 5 (or more) dimensions: Team, Process, Requirements, Collaboration with external teams, Tools. Create action items to improve the areas where the team is not happy with the current situation
How it works:
The team vote with an emoji for each of the dimensions, in the end all points get aggregated for each dimension and represented in a radar chart. 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)
- Team: Collaboration, mood.
- Process: Methodologies, mechanisms, organization
- Requirements: Clarity of requirements, goal alignment
- Other teams: Collaboration and cooperation with other teams
- Tools: Tools necessary to work, automation, ease of use, productivity
What Went Well, What We’d Like To Improve, What Went badly
Usually after a sprint or a project is completed.
Gather learnings of things that didn’t work during the project/sprint and create mechanisms to prevent them from happening again. The focus is on detecting opportunities for improvements in team processes.
How it works
The team takes a few minutes (10-15min) to enter their inputs on each of the columns. The second part of the meeting is to have a discussion of the things that went well and why, this serves as good opportunity to give kudos to peers. What needs improvements tries to collect info about things that are ok but can be revisited for improvement. Went badly, is used to talk about aspects that did not work as expected and find mechanisms to prevent them from happening again.
Three Little Pigs
Can be done at any time but its particularly useful after a new project has been in production for a few iterations. It can help as a post-mortem for moments when there are OE deficiencies detected or after a spike on production incidents or system failures.
This activity has the expectation to detect technical/operational debt. Identify what are the team and operational deficiencies and what needs to be done to fix them. If the team is struggling with technical debt, services/pipelines failures, or an increase of tickets due to any failure this is a good activity to detect endemic issues.
How it works
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 (e.g: load increases) and finally what things are rock solid that the team is proud of. Then a discussion is triggered on how to improve the opportunities detected in the first two by also taking the latter as reference for inspiration.
- House of straw – what do we do that just about hangs together, but could topple over at any minute? (e.g. “our deployment script is very manual, and prone to error – we could break production very easily”)
- House of sticks – what do we do that is pretty solid, but could be improved? (e.g. “our automated tests are pretty good, but sometime they fail for no reason, and we have to run them, which is a pain”)
- House of bricks – what do we do that is rock solid? (e.g. “our automated deployment and cutover has never failed. It rocks”)
Typically after a Sprint or a Project is completed
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 it better for the sprint/project
How it works
The team collects the inputs from the four dimensions of Liked, Learned, Lacked, Longed for (10 - 15 min). Then opens a discussion on each column to share the positive aspects and learnings to finally gather some action items for things that were missing or things that can be added for next iterations.
This may be the most simple. What were the positive aspects of the sprint that the team enjoyed or appreciated? This can encompass any aspect of the sprint, including actions, processes, or achievements. What went better than expected? This is all about the positive.
Any good sprint includes opportunities to learn new things. Were there any new discoveries that stood out? Everything is on the table here, from technical findings to interpersonal learnings. It can be results of formal experiments or things that just bubbled to the surface.
It would be a rare event to finish a sprint and find nothing lacking. Was there something missing from the last iteration? Could something have been done better? Was there a resource lacking that would have made things run smoother?
There is a subtle, yet essential difference between "lacked" and “longed for." In the previous category, the team identified things that they saw were missing. Now it is time to dream about things the team wished were possible, or tools they wished existed or were available to them. These are things that may or may not be possible but would improve the chances of completing a successful project.
Start, Stop, Continue
After a sprint or a project completion, specially useful for new teams that are still trying to define their initial 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.
How it works
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.
Follow @LeadingIn_Tech to stay up to date and/or subscribe to the newsletter for updates
Read the Past editions in Substack