LeadingIn Tech #8: Wrapped

December 2021

Dec 03, 2021

Hi there!

Welcome to another edition of the LeadingIn.Tech newsletter.

It's been 6 months since I last wrote to this newsletter, and now that we are in December and this is the time of the year where people start crafting their new year resolutions by looking at how their year went and what they would like to change the year after. New years resolutions are an exercise people do to evaluate what aspects of their lives they want to change and plan for it to try to improve their lives. In the software development world this is known as Retrospectives.

Off-topic: December it's also the time of the year when Spotify releases their Wrapped compilation of your year listening music. Here is "My Audio Aura" if you haven't seen enough yet.

Back to the topic. According to the Principles behind the Agile Manifesto teams are expected to frequently run the exercise to stop and look back to review and reflect on what can be improved.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

There are two main differences between a new years resolution and a retrospective. The first one is that unlike those good intended resolutions to "Eat healthier" or "Do more exercise" retrospectives are expected to generate actionable tasks for the team to improve their process with clear owners. The second difference is the cadence, retrospectives are supposed to be frequent and at a regular intervals, ideally if not always they should be done immediately after every team iteration.

The problem with retrospectives happening with a cadence of every few weeks (or less) is that if you are not creative on how to run them it can become a very monotonous routine that will make it difficult to collect valuable insights to act upon.

On this edition of the newsletter I would like to focus on my take on how I run them with my teams to keep them engaged. The idea is to give the team a variety of retrospective setups based on recent context to encourage participation and collecting insights from different perspectives. To achieve it I'm going to detail 6 different retrospective activities that I've picked as my favourites and that I selectively use them depending on the moment or the kind of outputs I expect for every session. Let's go through them.

Team Radar

When:

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.

Expected Outcome:

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, 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

How it works:

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:

Team: Collaboration, mood.
Process: Methodologies, mechanisms, organization
Requirements: Clarity of requirements, goal alignment
Other teams: Collaboration and cooperation with other teams and stakeholders
Tools: Tools necessary to work, automation, ease of use, productivity

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:

What Went Well, What We’d Like To Improve, What Went badly

When

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.

Expected Outcome

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.

How it works

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.

Three Little Pigs

When

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.

Expected Outcome

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.

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 what are the risks and what needs to be fixed to address them. 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.

House of straw – what are those imminent risks that are hanging from a thread that could break everything.
House of sticks – what are those things that are working fine today but we should not overlook because it could generate issues if conditions changes.
House of bricks – what do we consider to be rock solid and resilient enough to changing conditions?

4Ls

When

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.

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 things a lot better.

How it works

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

Start, Stop, Continue

When

This retrospective activity is specially useful for young teams that are still trying to define their set of 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.

The SailBoat

When

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.

Expected Outcome

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.

How it works

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)

'Wrapping' up

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.

One more thing.

Please keep in mind that retrospectives are not only a place to learn from the obstacles but also its an opportunity to celebrate the team accomplishments. And specially that the team receives the well deserved recognition from their contributions.

Finally, we need to make sure that on every iteration we put emphasis on how the team is improving compared to previous iterations. To make this happen have to commit to the action items identified on each of the sessions with clear owners and S.M.A.R.T. goals