Retro is an effective tool for increasing the development team’s work efficiency and should be used best. In practice, however, retro meetings have various effects, but they are not always positive. In this article, I would like to present an approach that will allow you to make this type of meeting more effective.

Let’s start with the theory. From a psychological point of view, as humans, we learn best through experience. Suppose we design an experience in which the team is supposed to solve a problem and limit the time available to solve the problem. In that case, it will turn out that teams that divide this time into shorter periods and use each episode to act and then implement quick improvements and act again will achieve better results than teams that spend most of their time on conceptual problem-solving. At the end of the time available, they will attempt to solve the problem.

Moreover, active participation in the problem-solving process increases engagement and motivation, leading to more sustainable results. You can read more about the results of the research, among others, in the publication “Learning by Doing: Evidence from Problem-Based Learning,” available here: Effective Learning Behavior in Problem-Based Learning: a Scoping Review – PMC (nih.gov)

Retrospective – time for reflection for the team

Retrospective meetings in development teams are nothing more than a time for reflection for the team, thanks to which they can determine what went well, what was missing, and what can be done better. Working in two or three-week intervals, the development team can very quickly diagnose those elements of the software development process that do not work as they would like, and thanks to this, the team can achieve high work efficiency in a relatively short time.

So much for beautiful practice. Development teams often face problems that can make retro meetings less effective and even frustrate project team members.

Retrospective – popular problems

One of the most common problems is focusing on issues the team needs more direct control over. Often, development teams engage in discussions about company policy, management decisions, or global market trends instead of focusing on specific actions they can take in their daily operations. For this reason, retro meetings do not bring the expected results, and the team revolves around problems beyond their reach. Such a situation leads to frustration and a sense of helplessness, reducing work efficiency and increasing the risk of developers leaving the project team.

Another challenge the development team may encounter when organizing retro meetings is the need for more structure and clearly defined goals. Without a clear plan, retros can turn into chaotic conversation sessions that don’t lead to specific conclusions or actions. A consistent problem-solving process can significantly improve the effectiveness of these meetings, giving your team a clear framework on which to act.

I will also discuss the importance of communication and feedback in this article. Many retro problems arise from ambiguities in communication between team members and between the team and the upper management level. Effective communication is key to understanding and implementing the proposed changes.

Focus on what the team influences.

Choosing topics on which the development team has a real impact is crucial for the effectiveness of retrospective meetings. Your team should focus primarily on aspects of their day-to-day work, such as internal processes, tools and technologies, collaboration between team members, and communication methods. Before the retro meeting, it is worthwhile for each team member to write down their observations and thoughts on activities that can be improved or optimized. Then, during the meeting, the first step will be to qualify each comment into one of two circles:

1. I have influence;
2. I’m interested.

Qualification for both circles is easy to carry out. This is enough to answer the question: Can I do something about it?

Let’s go through this classification using a simple example of buying milk in a store. If I go to the store, I influence which manufacturer I choose for the milk I will take home, but I do not affect the milk price, although the cost is in my sphere of interest because I pay for milk with my own money.

The development team chooses how to carry out development tasks, but although it is interested in business decisions, it does not influence them.

However, this is a black-and-white picture, and life is more gray. The development team may struggle to define clearly which topics they can and cannot influence. It could turn out that during most meetings, the team will come to a consensus on what they can and cannot influence. It is worth using the matrix of influence and effort to avoid such a situation.

How to use the Impact-Effort Matrix

The Impact and Effort Matrix is a tool that helps development teams evaluate and prioritize topics raised during the retrospective. With this technique, your team can focus on the activities that will bring the most value with the least amount of work. Here’s how to use the impact-effort matrix effectively:

Step 1: Preparing the sensor

The matrix of influence and effort consists of two axes: impact and effort. The low-to-high impact axis shows how much an initiative will impact your team or project. The effort axis (from low to high) determines how much work, time, and resources will be required to complete a given task.

Step 2: Evaluate topics

The team evaluates each topic’s impact and the effort needed to solve it. This can be done through brainstorming or discussion to gain a shared understanding of each topic.

Step 3: Placing the subjects on the matrix

After evaluation, the subjects are placed on the matrix in the appropriate places, forming four quadrants:

• Low impact, low effort: Topics that can be dealt with quickly but have little effect on the project.
• High impact, low effort: Priority topics bring significant benefits with little effort.
• Low impact, high effort: Topics that could be considered in the long term but are not currently a priority.
• High impact, high effort: Topics that are important but require a lot of resources and planning. The team can decide whether to take on these topics now or postpone them.

Step 4: Prioritize

The team focuses first on topics in the high-impact, low-effort quadrant because these bring the most benefit with the least effort. Depending on the available resources and time, it moves on to topics in the high-impact, high-impact, low-impact, and low-effort quadrants.

Step 5: Action

Once the topics are prioritized, the team creates an action plan for the selected topics, outlining specific steps, responsible people, and deadlines. Regular reviews and progress assessments help monitor the plan’s implementation and make any adjustments.

Using an impact-effort matrix improves decision-making and increases your team’s awareness of priorities and resources, leading to more effective work and better results.

Retro Meeting Structure

Based on the approach to problem-solving, we can prepare a repeatable structure for retro meetings. This will achieve high efficiency, and the team will be satisfied that the time allocated to retro is well invested.

The first step in troubleshooting is to select the problem you want to analyze. The problem should be classified beforehand according to the matrix of influence and effort. To do this, the team posts retro slogans describing the issues encountered. Each person then votes on the topic to be further examined. The topic with the most votes is analyzed to find a solution.

The person who reported the problem starts by answering the following questions about the reported problem:

• What’s the problem?
• Who is affected by the problem, and who is involved?
• Where is the problem going on?
• When does the problem occur?
• How does the problem work? How does it manifest itself?

All answers should be written down, and then each team member should refer to these answers, add their perspective and point of view, or ask additional questions to clarify the answers.

The next step is to determine if there have already been attempts to solve the problem. If so, you should discuss them and consider why they were ineffective. What actions were taken, and what effects did they have? It is crucial to isolate the factor that was being changed as much as possible and consider whether this factor was the reason for the observed change. Then, the team should focus on concluding the future from the attempt. What has this taught us?

Suppose the team has been working on a solution to the problem for some time and has a list of potential solutions to review. In that case, this is the moment to discuss what next solution to try and whether, based on previous experience, we want to modify this solution before using it and seeing if it will bring the expected results.

The next step is to define goals. Before we take any action, we need to define a goal. How do we want the aspect we are working on to work after we make changes? The goal should be achievable for the project team and related to the matrix of effort and results. If, when defining the goal, it turns out that it is not attainable by the development team, it means that the team made an overly optimistic assessment when assessing the impact. Such an issue should be updated on the effort and effect board, ending work on it and dealing with another problem the team will have a tangible impact on.

With a goal and a well-described problem, we can prepare a list of ideas for solving a specific problem. In the first step, each team member should prepare slogan ideas for a solution. Then, collect these ideas on the board and start the discussion, starting with those that, in most people’s opinion, give the best result with the least amount of work. It is worth saving all ideas for further work if it turns out that the first idea did not give the results expected by the team.

With the goal and the described course of action, all that remains is to implement the agreed changes from the next sprint. It is good to implement changes in the system one change at a time so that during the next retro, you can say how the implemented changes affected the achievement of the goal.

We are maintaining the results achieved.

If the development team comes up with a solution to bring the expected results, you should wait to consider the problem solved. It may turn out that the situation did not occur for one sprint because the team put much attention into this element to improve it. However, if the problem is out of the team’s area of interest, it may turn out that it manifests itself again.

We do not want this, so it is worth observing the source of the problem and our reactions to emerging issues related to this source for some time. Only when we decide that the developed strategies work well in the long run can we take the topic off the agenda of the retro meeting, considering that it has been effectively eliminated.

Communication during retro meetings

Another element that can negatively affect the effectiveness of retro meetings is communication. Suppose we allow the members of the project team to start attacking each other in a personal way during the retrospective. In that case, we will quickly discover that not only will the problems remain unsolved, but the atmosphere in the project team will deteriorate, harming the team and the project. If we want to avoid this, it is worth focusing on solving the problem during meetings and referring to specific situations without any connection to the people who participated in them.

Let’s start with observations. Describe specific actions or situations without judging or criticizing. For example, instead of saying, “You’re always late with tasks,” say, “I noticed that the last three sprints were finished late.” Thanks to this, we will avoid a situation in which a person feels attacked, forcing them to defend themselves. Instead, we can focus on finding the source of the problem and trying to solve it.

The second element of better communication is expressing emotions. While the first element is easy to achieve, the second is more complicated. Men, in particular, are afraid of expressing their feelings and emotions. However, this step is worth seeing the benefits we can get by expressing feelings and emotions.

Expressing your feelings and emotions related to a given situation allows you to better understand to other people why someone reacts the way they do in specific situations. For example, when a team leader says, “I feel frustrated when sprints aren’t completed on time.” The team has the opportunity to understand why the leader behaves nervously at the end of the sprints. When we know what the behavior of others is based on, it is easier for us to understand, accept, and take action to eliminate the problem.

An indispensable element of emerging feelings is unfulfilled needs.  By identifying the needs behind the feelings, the development team can better recognize what is essential. For example, “I need all of us to meet deadlines because it affects our efficiency.” A development team leader may have such a need.

Contrary to appearances, it is the leader’s and the whole team’s needs. If the leader does not have to explain to the team about subsequent delays, he will have more time to solve other problems or to improve the team’s work. Although the IT market is still experiencing a shortage of experienced developers, it is not the case that teams with ineffective teams can sleep peacefully. The business needs to grow at a predictable pace and direction. If the development team does not deliver solutions on the expected dates, there will be a time when another team or solution can replace it.

The last element is to formulate specific requests to other project team members. If we have an idea to solve problems, it is worth formulating particular requests to help solve them. Requests should be realistic and feasible. For example, “Can we set up regular meetings to monitor progress to ensure we’re on track?”

Applying these steps requires practice and commitment from the entire team. Still, by consistently using the principles of nonviolent communication, you can achieve a higher level of understanding, collaboration, and efficiency in achieving your project goals.

Retro summary

A retrospective is a potent tool, but as with any tool, you need to know how to use it so that it adds value to the team and does not generate frustration and embarrassment. I hope that applying the tips from this article will allow you to look at retro again and use it better, which I sincerely wish you.

If you want to learn how to turn project meetings into highly effective meetings, I invite you here: High performance project meetings