why did they change the format three times and what problems did they want to solve?

Hello! I am Tanya Afanasyeva, product manager at Selectel. Our department develops and maintains external network services. The team consists of ten people, including a team lead, product manager, UX specialist, developers, DevOps engineers and others. The main team was formed two years ago, when the company combined several products into one service. Most came from other departments or companies, so the colleagues initially did not know each other.

Over time, we began to encounter typical project development problems that negatively affected the product results and the overall atmosphere in the team. Colleagues did not understand what the purpose of the task was, why it was important to complete it within a certain time frame, and why it was necessary to synchronize with others. To solve these problems, it was necessary to establish communication and reflect on previous experience. That's when we decided to use a retrospective. In the text we will tell you what we did.

Use the navigation if you don't want to read the whole thing:
→ What is retro
→ The first format, or “nagging”
→ The second format, or “there are problems, but we will not solve them”
→ Third format
→ Conclusion

What is retro

Retrospective, or retro, is a process in which employees analyze the work done, identify problems and ways to improve current processes. After self-reflection, colleagues can quickly achieve their goals and complete tasks in sprints with high quality.

Typically a retro is done at the end of a work sprint or project. The duration depends on the number of colleagues and the scale of the tasks, but generally one to two hours. At the meeting, participants take turns sharing their findings and then discussing each other's ideas. There is also a facilitator present at the retro, usually a team lead or product manager.

The entire process is based on transparency and trust within the team. This helps improve communication between colleagues and prevent problems before they become serious barriers.

The first format, or “nagging”

There is no single retro format – each team adapts it to its own goals and objectives. For example, colleagues from client and internal services are having fun are discussing “Jokes”, “Problems” and “Solutions”, and then vote for the most responsive stickers. We, on the other hand, chose a standardized format and began using Confluence – it did not require much preparation and had an easy process.

Retro teams of client and internal services. Source.

In the internal knowledge base, you can easily share results, see the history of discussions, and track the progress of tasks. Before retro, our team used Confluence for product documentation, so at that time it seemed like a logical solution.
We divided the page into three blocks: “What helped the work?”, “What hindered (closing the sprint) and can be improved?” and “What new things did you learn? What new did you learn?” During the sprint, colleagues left answers to questions, and their hearing was read out at the meeting. I was the retro moderator.

An example of the first retro format. All entries are fictitious.

Flaws

It soon became obvious that the format had significant shortcomings. It needed to be improved to cope with a number of emerging problems.

• We didn't have a clear goal. The guys complained about work problems, but nothing changed for the next sprint. Thus, retro did not solve our problems, but served as a tool for splashing out emotions.
• Confluence's interface was not suitable for interactive interactionbecause it was too formalized and dry. It felt like we were filling out a report rather than discussing problems.
• The guys spent a lot of time preparing the recordings. It all came down to the fact that the participants forgot to fill out the page. As a result, out of ten people, only two wrote.
• Everyone took turns reading their notes out loud.. Retro turned into a monotonous lecture that participants did not want to attend.

The second format, or “there are problems, but we will not solve them”

The new format has been transferred to Miro; it is convenient to use for brainstorming, planning and solving joint problems. Three columns with the previous questions were placed on the board, only reformulated as well, sad and new. Each participant was given note cards.

An example of the second retro format. All entries are fictitious.

In the first ten minutes, the participants prepared their notes, and after that they discussed with the team. Unlike the previous retro, in this format we not only talked about the problem, but also planned how to solve it. Tasks were created from the received cards and recorded in the margins so as not to forget. As a result, retro became more interactive, everyone could make suggestions for solving problems.

Flaws

Every retro format has its drawbacks, and this is no exception. Fortunately, there were much fewer of them than in the first one.

• Participants completed the page only at the beginning of the retro. Usually a sprint lasts two weeks, so at the end most people couldn’t remember what happened in the last one.
• Future tasks were not tracked and were often forgotten. It’s easy to come up with a solution to a problem, but to control it, you need to try.
• The “nagging” format was maintained. Everyone came to the meeting to complain, not to get results.

Principles of “healthy” retro

Changing the retro format again is not enough. It was necessary to formulate the principles by which our “event” would function. With their help, you can solve problems that the team encounters while working on common tasks.

Desire and proactivity
At retro, colleagues can openly share their ideas, problems and solutions. No one will condemn them – on the contrary, such initiatives are encouraged. If the participants do not see the problems and are not ready to discuss them, the retro may not be carried out. Managers should reconsider tasks and improve communication within the team.

Teamwork
We conduct a retro for an internal team, so all project or product participants must be present. We do not invite employees of related departments and top managers. It is important that colleagues can feel comfortable and open.

In addition, all tasks and decisions made at the meeting are the responsibility of the participants themselves, and not the leader. This allows each team member to feel important and influence the effectiveness of the process.

Moderator
The team must have a person who is involved in the preparation and analysis of retros in order to exclude sabotage from colleagues. For example, when a specialist claims that everything is fine, but in fact he completed the sprint for the last quarter by only 15%, or when a task was set, but the performer forgot about it and did not solve the problem.

In this case, it is necessary to identify a facilitator who will ask clarifying questions and guide participants in the discussion process. This role can be combined with the responsibilities of a retrospective moderator.

Regularity and consistency
We still cannot determine how much time we are willing to allocate for review. For now we decided to stick to one meeting every two weeks for one and a half to two hours. Perhaps we'll change our minds in the future.

It is also important to establish a uniform retro format. The team must understand why we are conducting it and what our goals are. It’s like a game – the rules should be known to everyone.

Human qualities
Constructiveness, openness, honesty and respect are the basic principles that are applied in all processes. Without them, it is difficult to build healthy communication and interaction in a team.

Third format

The purpose of our retrospective is to improve the efficiency of work processes, identify current problems and formulate a further plan for changes. To solve them, we fixed new regulations: we developed a retro structure and divided it into several stages. Let's take a closer look at them.

Preparing for retro

The day before the retro, the moderator reminds participants to fill out cards in Miro. The latter write notes in two columns “What helped me in my work” and “What hindered me (to close the sprint) and can be improved?” Here it is important to avoid excessive praise of colleagues and obvious problems – for example, “thanks to the UX designer for drawing the prototype,” or “I was unable to complete the task on time because I was not in the mood.”

Retro structure

Stage 1. “What was good and helped the work?” and “What hindered (closing the sprint) and can be improved?”

Stage 2. Problem analysis and brainstorming.

Stage 3. Forming action items.

Completion of retro and feedback from colleagues.

Process after retro

It's not over yet! A team lead or product manager creates issues in Jira to organize work on current issues. Next, he assigns performers and copies the task link to the sticker.

Start of the next sprint

At the start of a new sprint, the team conducts planning to discuss the tasks that members will take on that week. Not all solutions must be implemented strictly before the next retro. It is important to set only deadlines so as not to delay implementation and track your progress. This way we can correct course and adapt actions to changing conditions.

Conclusion

Retro allowed us to achieve several key goals that we set at the beginning. In particular, we were able to involve participants in the process and solve some problems within the team. Of course, the third format is not ideal: sometimes we have to “pull” information from participants, but we continue to work on it.

In conclusion, I would like to know about your experience of holding a retro. How do you deal with problems? What tools do you use? How do you involve guys who are not ready to participate in such a format? Share your options in the comments!