🧭

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.)

Team Radar

When:

Twice a year or when landing to a new team.

Expected Outcome:

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)

Radar Axis:

  • 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

When

Usually after a sprint or a project is completed.

Expected Outcome

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

When

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.

Expected Outcome

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”)
image

4Ls

When

Typically after a Sprint or a Project is completed

Expected Outcome

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.

Liked

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.

Learned

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.

Lacked

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?

Longed For

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

When

After a sprint or a project completion, specially useful for new teams that are still trying to define their initial internal processes

Expected Outcome

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.

image

Source:

📩 Subscribe

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

Read the Past editions in Substack