Agile Retrospectives: more than a team dynamic

Pamela Peixinho
Blog Técnico QuintoAndar
7 min readNov 28, 2019

More than agile meetings or a team dynamic, it's a point of iteration — enhancement of process, product and tech — for the entire team

Two pens with a paper with a graph from past and future with a rule
Look to the past to achieve the future — using metrics always (Unsplash)

The agile retrospective is a meeting that's held at the end of a development cycle in Agile software development. The literature says that it is time of iteration to work on the team process.

However, it's not reality! Commonly, we only go to the meeting and do a team dynamic to talk and complain without real action points. The truth is… It can be so much better if we think as a point of iteration like a product has.

So, let’s take a tour about a good agenda for the retrospective, then how to prepare the retrospective (with an explanation to help to decide the dynamic that fits better), and finally tips for the retrospective facilitator.

Disclaimer: The order and the samples are just to help to understand. It’s not mandatory and should be updated for each team.

Agenda for a good retrospective

A good retrospective is more than a dynamic of stop/continue/start. It's the point of interaction after a cycle of development.

So, we also need to review what happened in the last cycle because this will be the base for any further discussion.

You can't improve what you don't measure and review

Agenda

  1. Review the last deliveries
  2. Review team metrics
  3. Review previous actions points
  4. Retrospective dynamic

Review the last deliveries

It’s the time that we review what we delivered in the last cycle for the user or the company, the progress of what we’re developing and, mainly, what we promised and didn’t delivery, along with the explanations.

Deliveries of the last cycle (two weeks)
a chart with the green line (estimated) and orange line (resolved) of the feature
Progress of the feature being developed (estimated x resolved)

Review team metrics

Reviewing the team metrics is another important step to extract strong points and the issues that the team is facing. This can be very insightful on how we can improve.

The team metrics can be about the Product, Tech perspective and "One Team perspective".

Product:
It can be about the progress of OKRs, user metrics, support calls metrics (HM-health metrics), discoveries or any other metrics that can be relevant to the team know about the product/project that they are developing.

Tech Perspective:
It's the moment that we can look for the engineering perspective of the last cycle. For example:

  1. Velocity/throughput: How is the team’s velocity? Increased? Is there any reason? What can we do to improve?
  2. Bugs in production: How are the bugs? Are we adding or solving bugs? Do we need to take another action to help to decrease the number of bugs? Is it healthy for the team and product?
  3. Bugs in development (defects): How are the bugs that are a deviation from the requirements of what we're developing? What is about? Are they increasing by category? What can we do to reduce the number of defects?
  4. Any other metric that can be relevant for the team, mainly understanding the team moment and what people need to listen to. For example: "time to close a PR", "explanation of team deliveries moments"
Sample of team tech metrics (bugs, defects, defects per category, throughput)

One team perspective:
This step is not necessary for all retrospectives but sometimes its good to remind us that we're a multidisciplinary team. One Team. A group of people together to solve a problem. So, we need also to review what is and isn’t good for all.

There're some good metrics to look, like:
Team Morale, Agile Radar (an article about that coming soon), and Cross-company impact (actions that impact other teams in your company).

Sample of Team morale view — by time
Sample of Agile Radar view — by time

Review previous actions points

Another important point is to review our previous action points and their respective status. This will help to celebrate what we've ACHIEVED, let everybody know what it's still in progress (WIP — work in progress) and understand why we didn't achieve what it's for TODO.

Retrospective dynamic

Ok... Now it's time to go the team dynamic. It's important to remember:

  1. Gather data: Let the team know it is a safe environment to talk about anything, explain the dynamic and wait for people to write their post-its.
  2. Generate insights: talk about problems, cluster it
  3. Decide what to do: think about action points based on the problems discussed
Image found in this amazing article about retrospectives (Reference)

After, understanding a good agenda for a retrospective, let’s see how to prepare it

Preparing the retrospective

Looking back

  1. Get all data related to the last deliveries
  2. Get all team metrics
  3. Get all last action points, all status, and owners

Retrospective Dynamic

First, there’s no “owner” of the retrospective. So, anyone can be the facilitator. There are teams where the PM is the facilitator, in others is the tech lead and there are some that the team members do this job. Sometimes it's rotating, sometimes not, and it’s ok. There are no rules for this moment. It’s just important to pay attention to some points:

  • Are we getting reasonable action points?
  • Is everybody talking about the problems? Do they feel like a safe env?
  • Are we getting the logs of the retrospective to remember in the next ones

Now talking about the actual dynamic, there’s a lot of agile retrospective or futurespective group dynamics, but all have the same core:

  • Understand what is going well (continue doing or do more of)
  • Understand what is not going well (start doing something or stop doing something)

It can have other names, it can have movie characters or objects attached. It can have a lot of aspects to look or just abstract. In the end, we want to get info to help improve the team and the deliveries. For that, the formats of the dynamic help to get the best of the team. We can choose based on our gut feeling, or in a specific thing that happened or (what I personally prefer) consider some other team aspects:

  • Team phase (based on Tuckman’s model: forming, storming, norming…)
  • Team formation (more junior, senior, multidisciplinary or not)
  • Team deliveries' moment (starting a new project, finish the project, big or small projects)

So, choose one that you feel that it’s going to be good for your team, and go ahead!

If you need some help for choosing a retrospective dynamic, you can access this compiled google sheets within agile retrospectives with the respective aspects for each team (suggestion) that link into a document with dynamic descriptions.

A table with retrospective name and link within respective of arguments like formation / type, etc. (Just a Sample)
Print of some retrospectives within team phase; team deliveries moment; formation type

⭐️ Tips for the facilitator during the retrospective

  • Try to start on the “not going well” points, because it has more time to discuss and people are not tired yet;
  • Avoid giving your opinion first, make questions in order to make people talk, discuss and also arrive in action points;
  • Make everybody feels that it’s a team problem and the team needs to solve it together. It must not have any type of blaming;

Thanks for reading! I’m always open to receive feedback, recommendations or questions, feel free to contact me!!

Pamela Peixinho, Lead Software Engineer at QuintoAndar

LinkedIn: https://www.linkedin.com/in/pamepeixinho
GitHub: https://github.com/pamepeixinho

My last name is LittleFish, “sea” you later! 😉

--

--