Highly Productive Retros

The retrospective occurs regularly in a high performing team and requires that the whole team come together to discuss their problems, solutions and improvements. As the team lead, if you aspire to lead a highly productive team, then the retro will be a key tool for identifying weak points in the team and working to address them.

These are some good practices that encourage teams to be open and increase the free flow of information.

Retro on the Last Day

Have retros as close as possible to the end of your sprint / team cycle. It is very easy to leave the retro until the start of the next sprint, but this leads to a couple of problems.

Firstly, your team forgets easily. After a couple of days, if you ask your team their problems for the last 3 weeks excluding the previous week, they won't remember anything. The team needs to have a fresh mind. That means having the retro as soon as your sprint is over, preferably on the same day it finishes. In my case, we take the latter half of Friday evening to relax together and go through the feedback from the previous three weeks.

Secondly, actions needs to be brought into the upcoming sprint. If your planning happens on the first day of your sprint, and you have the retro a day or 2 later, you can't address the problems on time and account for them in the sprint planning.

Make it fun

If the team don't enjoy getting together and talking, then they will not enjoy the retro. Make a game of it as much as possible.

Write feedback on colorful stickies. Bring in some biscuits or cake and have the retro over some coffee. Take a break from your usual office space and go out for lunch together.

Keep records organised

It is critical to connect each retro to the previous one. If your retro does not refer to previous retros to show progress, then the previous retro is effectively lost.

At the beginning of each retro, go through the actions from the previous retro. This develops value in the retro, because now your team feels that progress is being made.

If an item keeps coming up at every retro, address it ASAP. In my last retro, I realised that a problem (albeit small) was mentioned 5 retros in a row! That was a signal to me that it had to be prioritised.

Prioritise actions for the upcoming sprint

This is the most valuable part of your retro. Once the problems have been stated and solutions or improvements identified, prioritise them and execute on them. This could be on a technical level (test cases missing) or on an interpersonal level (manager X is interfering in the team).

Pick out the top two or three actions your team think are needed as a priority. Create tasks from these actions and bring them into the upcoming planning session to make sure they get completed.

Put the tasks front and center - don't let them get lost on a virtual document where nobody can see it. You could create physical stickies on a notice board above your team space or put them on your virtual board that you share at your morning standup.

Remember, without making an effort to improve the team's problems, the retro is of no benefit.

Don't leave problems until the retro

As the team lead, take note of the problems during the sprint. Don't let the team get into the habit of saying "It's fine for now - we'll discuss it at the retro". It is tempting to get lazy or to delay fixing problems. By the time the retro comes, they will have forgotten their pain.

Get the team to practice bringing up issues as they arise. You can discuss them further in the retro, but the right moment to discuss is now, not later.

Case Study

The following is an example of how my team performs our retrospective.

Frequency: Every 3rd Friday
Attendees: Whole team, sometimes the product owner in the background.
Preparation: Create a digital document with the following categories:

• Previous retro.
  • Fill in with the actions.
• The Good
• The Bad
• General Improvements
• Top 3 actions
• Thank yous

Schedule

Previous Actions

Briefly go through the previous retro's actions.
Were the most important actions completed? If not, why?

Example

• [John] Raise a ticket with operations to fix our test environment. DONE.

The Good

Take 5 mins for each person to write down what they enjoyed or what they achieved since the last retro. Categorize the items and pick out the common themes. This is where your team pats themselves on the back for the good work they have done.

Example

• Great communication despite working from home. [TEAM]
• Quick response to messages online from the team. [TEAM]
• Less than 5 bugs for the whole sprint. [BUGS]

The Bad

Categorize and discuss the bad things that have happened since your last retro. Make sure you attach a solution or improvement to each bad item.

Example

• Frequent missing of morning standup meetings.
  • Improvement: Move morning standup ahead by 15 mins to avoid the clash with the other meeting.
• Poor ticket writing from our QA team.
  • Improvement: Create a template for the QA team to fill out every time they write a ticket.

General Improvements

What general improvements would the team like to discuss?

Example

• A test case is missing in our test suite. We should add it before we get stung with a bug ticket.
• The morning standups are going over the 15 mins mark - set a timer to cut off the standup at 15 mins.

Top 3 actions

What are the top 3 things from 'The Bad' and 'General Improvements' we should address in the next sprint?

Thank yous (Optional)

This can be a nice way of finishing off the retro. It is surprising how powerful saying thank you to someone can be. They will be more inclined to help you in the future. Is there anyone we should thank that helped us out?