Foster the team Growth
All the achievements made by the teams are done with the best resources and practices they had at their disposal. But in order to reach the next level, teams need to include their growth in the daily basis. Retrospectives are an amazing tool to identify improvement points in the team, and include the Continuous Improvement in every iteration!
Frank M.L.
9 min read


One of the most common things I observe in my work with engineering teams: the team tends to focus on what they need to do, getting stuck using the tools and practices they know and feel comfortable with, even when the challenges evolve and what worked well in the past no longer work to deliver as expected.
Then the team starts adding more and more tasks to the work in progress and struggle to meet their expectations.
In this situation, the frustration starts to grow and a common short-sighted mindset emerges:
We cannot focus on improvement tasks, there is too much to do, and this would slow us down.
But, contrary to this assumption, investing effort, to analyse, understand and improve, always pays off. Not only with efficiency in the time to market, but also in the quality of the product they are delivering.
In this post I am going to share my essentials about retrospectives. As always, this is what worked well in my teams, but every team is different and I encourage everyone to find what works best in their teams.
Meet the Retrospectives
In my teams we always adopt an Agile Framework to organise our daily work. Wether we work on Scrum, Kanban or an adaptation of any of these frameworks, the Retrospectives are one of the most important sessions.
A Retrospective is a session where the team sits together to reflect on the last iteration. To get the most out of the retrospective sessions, we work on several aspects of the team performance: the mood of the team, our previous improvement actions, the team goals, and the team metrics. Finally, we participate in a dynamic for identifying the improvement areas and define actions to be included in our next iteration.
Phase 0: Let the team participate
In my experience, it is impossible to have a great retrospective if the facilitator is also a participant in the session. As a facilitator, taking part in the session, it is easy to override priorities, preventing the team from really working together, or even dismissing some key points for the team.
As a manager, I like to include other sessions, to discuss other topics or concerns with the team e.g one-on-ones, technical sessions, even ad-hoc retrospectives for specific topics. So there is no need to override the regular retrospective.
A team with clear goals and purpose, will come with similar priorities to the session. To get the most out of these sessions, my work as a manager is to ensure that the team is pushing in the same direction, providing a safe feedback environment, where all the team members can express their thoughts in an open, constructive and respectful way.
Phase 1: Getting the team temperature.
Start the session by helping the team reveal their mood on arriving at the retrospective. This has proven to be a great tool for the team and for managerial purposes.
Benefits for the team:
Help the team to perform a first introspection about the actual iteration.
To have a better visibility of their peers' mood and worries.
Better understand some of the worries carried by different roles in the team.
Compare their evolution over the iterations.
Benefits for the manager:
Helps to identify the general mood of the team.
Identify any possible clashes between roles.
To be able to track the evolution of the team mood over the iterations.
Visualise the team status to higher management or stakeholders.
We usually gather the team temperature with a clime semaphore, we start by asking all the team: how is their mood on starting the retrospective? Additionally, I like to add the comment: take a moment to reflect on your mood during this iteration. Then I ask them to add a sun (I'm feeling amazing), cloudy (I'm feeling good but there are some topics bothering me), or rainy (I'm not feeling good at all).
In new teams, I always start with an anonymous semaphore, generating a safe environment for the shy members to feel comfortable sharing their mood. Once the team is more comfortable in this dynamic, it naturally will become an open space, where none of the team members will need to share their feelings discreetly.
Once all of the team members have added their mood to the semaphore, I like to launch a question: Does anyone want to share their choice? Letting anyone share their thoughts, but preventing discussions or debates. We have other spaces to have these kinds of conversations.
In order to prevent discussions between team members, I always remind the team that these are personal feelings, and every one of them is entitled to have their own experience.
Finally I take notes of anything that arises. I then follow this up in the personal one-on-ones, or even in separated sessions.
Phase 2: How we performed the last iteration?
The goal for this phase is to analyse the data of the last iteration.
Analyse the team Goals.
In my teams there were always between 2 and 4 goals per iteration. It is important to acknowledge how the team performed regarding these goals.
Here you have to be objective, achieving a goal usually is a boolean answer: Was the goal X achieved? (Yes 🟢 | No 🔴)
You can add side notes to each of the answers e.g.: 🔴 -> We are currently working in this goal, but because of the change in the priority we couldn't achieve it.
The idea of this is not to analyse what was the reason for reaching or not reaching our goals, but to give a clear view of the completion. The deeper analysis will come further in the session.
Celebrate the achievements! The continuous improvement is not only focused on identifying the improvements, but also acknowledging what the team achieved. This also gives a boost of positivity to the team.
For the goals we didn't reach, I always encourage the team to take their own notes of what they think happened and what we can improve. We then look at these during the following phases.
Analyse the performance data.
It is time to go deeper, check the performance of the team in terms of committed features, achieved features, burn-down charts, time in each of the status (this is amazing to track bottlenecks), unexpected bugs or changes in the priority, ...
I illustrate this information to the team using a dashboard. JIRA is great for task tracking, but you might have to complement it with the Git data, or observability reports. Then I encourage the team to share their thoughts about the information they see and take public notes on the side of the metrics.
This is an analysis phase, so we want the focus to be on what happened. We can then build on this during the last dynamic, when we detect and prioritise the improvements.
If improvement points appear, mark them and tell the team to save them for later.
Here I like to get insights from the team. Sometimes these metrics do not reflect all that the team needs, or there are metrics that lose their value. Hearing the team during the analysis can help to improve the dashboards.
Take time to review the previous retrospective actions.
This is the moment to bring the previous retrospective actions and review them. This has proven to be a key way to engage the team in the Continuous Improvement mindset. They will see that there is a continuity in these sessions, giving more visibility and raising the importance of the improvement actions.
For this review, I use the same philosophy as in the goal review, presenting the actions and asking two questions:
Did we do this action? (Yes 🟢 | No 🔴)
Did this improvement point really improve because of the action? (Yes 🟢 | No 🔴)
With this review we want to:
Remind the team of the context of why we were doing a specific action (it seems silly, but after several weeks the team tends to forget).
Help the team to analyse if an action was really effective.
Give more visibility to the improvement actions.
As in the previous points, prevent any deep debates about these points and just add side notes of direct outcomes. The inner analysis of what happened comes next!
Phase 3: The Retrospective dynamic.
Now is the moment, after all the analysis, where we have all the information about the team performance. So let's find the improvement points, prioritise them and define actions to start implementing as soon as the session finishes.
Here I have tried many different dynamics, but my best advice here is: select the dynamic based on the team and the context. The retrospective dynamics are tools and as with every tool, they work better when you use them in the right moment.
Here I leave you the dynamics I used the most:
DAKI (MIME in Spanish): This dynamic is an evolution from the typical pluses and deltas. It is great at identifying what is really blocking the team from becoming its best version.
Sailboat: This dynamic works great when the team is in the middle of a big development. It helps to detect improvement points during the development process. It also identifies future risks that could delay or compromise the quality of the project.
Timeline: This dynamic works really well after a task-force or finishing a project. It helps the team to remember the inception of a feature/project. In this way, not only focusing on the final part of the project, but also on what we can improve in future developments at the start.
Remove the external noise.
Some teams tend to use the retrospective to treat external noise, or even topics related to the company that they cannot do anything about. But remember, the retrospective is a tool to help the team to improve and so, it should focus on the team.
When I detect this kind of topic, I always raise this question to the team: What can we do as a team to correct this improvement point?
If the answer is no:
Remind the team that the retrospective and the improvement actions should focus on our team.
Put the topic aside to be evaluated in a transversal way. As a manager, it is part of your job to reduce the friction between the team and the rest of the company. Take the topic to a transversal forum, or even take an action involving the other party. Always reflect back to the team about any actions or outcomes for the team.
Prioritise the improvements the team needs.
It is very typical that the board starts filling with nine or ten different improvement points. But it is not feasible to treat all of these topics at the same time. In my teams we always prioritise the 2-3 most important or impactful topics. We take actions on these topics, leaving the rest for the following iterations.
In order to reduce the amount of topics, I always encourage the team to group the different topics into related groups.
If the team is big enough, a good practice is splitting the team into work groups focused on one or two topics. In the end, the different groups share the actions with their key points. This has proven very helpful in building communication and trust inside of the team.
Take notes about the process.
As a facilitator, I like to take public notes of the ideas and comments that the team develops. This helps the team to have a clear focus on the topic. Giving them visibility of their own process.
It has also been useful to draw the connections between topics, or actions. This helps to detect possible relationships between topics or even actions, that could help to improve on multiple fronts.
Different kinds of actions.
An action could be:
Tasks: it is important that the team defines tasks that can be completed within the next iteration. This way, they will be able to get fast-feedback about the task. In order to ensure the tasks can fit inside the next iteration, I always raise the question: Can you commit to executing the task within the next iteration? If not, encourage them to break it down, or even de-prioritise it and look for an alternative.
Working agreements: these are new agreements for the team or their workflow. This kind of action will live inside of the team, so make sure the team has a common place for visualising them. Those rules should be a tool for the team, so encourage the team to review them regularly. Changing them if they feel they are not useful anymore.
Never forget the good points.
After working on what we need to improve, the team can be left with a negative aftertaste. So in my retrospective sessions, we always end on the good points (keep doings, suns, winds, ...), extending the retrospective some minutes if it is needed. It is really important to celebrate and acknowledge the achievements and what made the team feel good, this will give a boost to the team morale.
Phase 4: Let's use the outcome.
Include the actions in the next iteration.
After all of this amazing work, now is your turn, to ensure the actions make it inside the next iteration, in order to keep the continuous improvement environment.
During the initial retrospectives, it is useful that you (as a manager) create and include the tasks inside of the backlog. Over time, I like to move this responsibility to the team, giving them ownership of their improvement actions and a sense of autonomy in this way.
Visualise the outcome.
As a manager, I like to send the team a summary of the retrospective, with the key points, actions and working agreements. This helps the team to have a place to review the outcome of the session, giving the team the possibility to review it whenever they need it.
Also, I like to share the outcome of the session with the rest of the department/company. Encouraging everyone to reach for any doubts or feedback. This has proven to be useful for:
Giving visibility of the team to the rest of the company.
Encouraging other teams or departments to include the Improvement session within their team.
Identify possible collaboration between teams, reducing the effort of the process.
Raising possible issues or clashes with other teams faster.
Keep the summaries on hand.
After this whole process, having these summaries of the retrospectives in a team wiki has been a great asset for my teams. These summaries helped the team to:
Maintain the team growth track.
Revisit the previous improvement points and actions. Being able to respond faster when facing a given scenario.
Remember which actions worked or not, and why.
These are my main tips for having great retrospectives. Building the team's hunger for growth and continuous improvement.
I hope this post helps you to bring this step up in your teams!
If you have any doubts or feedback about this topic, please contact me: