What is going well in the team and in the project? And what is not? What measures can be derived from this? Retrospectives are a perfect way to bring motivation and momentum to your company or agency. We'll show you how to set up a retrospective and what the dos and don'ts are.

A retrospective (or retro for short) is a type of review to determine together in a group, a team or for an entire organization what successes have been achieved in a set period of time. This allows you to put your project management or agile software development to the test, as well as any other area in your company. At the same time, retro meetings clarify the question of whether cooperation in the teams is actually working so smoothly - and how satisfied your employees are.

The basic rules

Retros are particularly efficient. This is because each unit offers enough room for suggestions for improvement, which are immediately translated into concrete projects. This is precisely what makes retrospectives so valuable and sustainable. When carried out correctly, retros are conducted in a way that

1. Letting everyone in the group or team have their say
2. offers space for various forms of feedback without immediately evaluating it
3. Constructive, forward-looking, respectful and transparent is

Retrospectives are by no means only suitable for companies or agencies, but also for NGOs, associations, voluntary groups, open source initiatives or social and political projects. The open source or WordPress environment in particular appreciates feedback loops that are based on retrospectives. After all, they bring the entire development team on board and open up decision-making processes.

Retros are just as suitable for technical projects as they are for improving corporate culture. Here is a brief overview of the two variants:

Scrum Retrospective

Retrospectives are classically known from the Scrum project management method. Teams from software development or web design in particular rely on Scrum, as it offers an antithesis to classically hierarchically organized projects of the "I tell you what to do and when" variety. To a certain extent, the developers organize themselves in Scrum. Nevertheless, there are fixed structures (such as the Scrum Board) and fixed time periods ("sprint"). Sub-tasks make the whole process particularly flexible and therefore agile. The retro itself runs in five phases:

1. Intro: This is where you get the team in the mood for the retro, define the goals of the meeting, explain the organizational process again if necessary or introduce new participants.
2. Collect data: This step serves to collect topics that should be highlighted in the retro. In other words, points that went well. But also those that you would like to see optimized or that cause conflicts. Initially, all input is allowed here - the joint prioritization only takes place afterwards.
3. Gain insight: The recorded points are discussed together. What are the causes of positive developments, but also those that need to be optimized? What can be derived from this for further projects or for cooperation within the team?
4. Derive measures: The team decides together which improvement measures should apply to the subsequent sprints. These measures should be formulated as specifically as possible ("who does what by when") and recorded in writing.
5. Conclusion of the retrospective: Here you can summarize the results once again, clarify any last open questions, pick up all participants and do a short "retro of the retro", so to speak.

For some teams, agencies and companies, this very open form of exchange takes some getting used to at first. It can then happen that little feedback is received at first, or that conflicts and mutual accusations arise. This can be avoided, but here are a few tips.

Sooner or later, however, the retrospectives should lead to the following improvements:

• Schedules in software development or in the project can be better planned, limiting hurdles are eliminated
• The company creates the necessary technical, structural or personnel resources to be able to work properly
• Employees address conflicts more openly and resolve them together
• The team focuses not only on what is not working, but also on the positive points and process optimization
• The focus is not only on technical challenges, but also on cooperation and team spirit

If one or more of these points are not achieved, you can work together on the format, the tools, the decision-making processes, the involvement of all participants or the moderation. Or the team may realize that certain prerequisites need to be created first. These could be standardized development processes, for example, or better communication or motivation within the company.

Team Retro

And this brings us to the second function that retrospectives can have. Apart from purely project-related processes or as a supplement to technical retros, they can be used to strengthen cohesion within the agency or company. No team can do without conflict. It is crucial to deal with them openly and in a solution-oriented manner so that the organization is not just preoccupied with itself or remains in a "work-to-rule" mode.

Independent team retros that are not involved in Scrum or any other method primarily use the following three questions:

• What worked well? In which cases did we work well together and why?
• What did not work well? Where can something be improved in the collaboration?
• What are we going to try out that we hope will bring about an improvement? Who will take care of the implementation and by when?

In this case, a retrospective is less rigidly organized than with Scrum. In principle, the team is free to determine the format in which the questions listed above are clarified. However, a regular format (such as a review every two months), a representative selection of participants, detailed documentation and written results are helpful. There should also be one person who is responsible for inviting, moderating and processing the meeting.

The topics for the retros should come from the employees themselves, more on that in a moment. To initiate this process, it makes sense to regularly collect feedback beforehand. And to provide both support and motivation. For example, as part of (possibly anonymous) surveys or through a special role in the company. You can read what this can look like in our article on mental health in companies.

This is because employees who previously worked in a very hierarchically structured company are not used to making open and courageous contributions to the corporate culture. Things will only change in your company if there is a framework in which everyone can freely express their opinion.

Dos in a retro

Regardless of technical or rather cultural retro, there are some prerequisites and tools that contribute to the success of the meeting:

• Moderation: In the Sprint Retrospective, this role is assumed by the Scrum Master. In a non-formal retrospective, this task can be freely determined, perhaps even as part of a rotation.
• Flat hierarchies: It is important that the moderators lead the meeting as equal participants, not "from the top down". The same applies to people from management or other senior employees.
• Define a set of rules: If misunderstandings or arguments arise during retros, it helps to remember the agency's or company's shared values. Not as a list of prohibitions, but in the form of examples that stand for positive communication. See, for example, the Raidboxes Code of Conduct.
• Binding agreements: This includes recording results in minutes. But it also means not making decisions over the heads of absent people. In case of doubt, the group of participants must be expanded. Or, depending on the expected topics, guests from other departments and teams can be invited.
• Measuring success: Have the measures adopted so far led to improvements? If not, what can a more concrete conclusion of the retro look like? Can the successes be proven or measured? Has the workload been sustainably reduced or has the mood in the team improved?

The last point in particular is important: only through positive results will the retro become permanently anchored and accepted by everyone. After all, not everyone in your team will understand the purpose of retrospectives right from the start. The excuse "It's no use anyway" can only be refuted if successes become visible. And if you regularly pick up all roles in the company.

Don'ts of a retro

Some of the don'ts arise from the points mentioned above. But risks also lurk beyond this if the retrospectives are not well thought out or if they are not well guided:

Unproductive circle of participants

Openness and sometimes tact are required here. It is detrimental if individual members of the team do not feel included. On the other hand, meetings that are too large - or if the topics are too mixed - quickly become unproductive. If individual topics cannot be clarified in the large group, they can be passed on to the smaller team retros if necessary.

Too little transparency

If other departments feel that they have no insight into the results of a retro, unrest or frustration can quickly arise. This is where publicly accessible minutes or the regular presentation of results to everyone can help. This also applies to measuring the success of the adopted points.

Protected frame

At the same time, the retrospective itself should be a protected space so that there are no reservations about expressing criticism in it. Some people only speak openly about what needs to be improved in such a setting. For example, within their own team or without the management level. If necessary, the retros can be split up in order to find the right balance between transparency and the need for protection.

Specifications too strict

Is it always the same participants who speak up at a retrospective? Are suggestions quickly shot down? Or are individual results already known in advance? That can't work. Retros are only suitable for agencies and companies that have an open culture.

Tasks are not precisely defined or are not tracked

The question of "who does what by when" is extremely important. Retrospectives require the group to define responsibilities and deadlines for each idea to be implemented.

On the subject of sustainability of the measures: It is worth using a project management tool in which the individual tasks are entered. You can then see at a glance at any time in which areas a retro is going well and where improvements need to be made. Do you have several retrospectives in your company? Then they can measure each other or exchange ideas.

Pure technology, no culture

Regardless of whether it is a Sprint Retro or any other variant: It is not just about listing and solving purely technical challenges. The social and cultural interaction within the team should also be examined. Because one (efficient work) does not work without the other (team spirit). Development departments sometimes find it difficult to combine the two. This is where suitable training can help, such as our blog post on non-violent communication.

Unclear structure

Retros should create the freedom to talk freely about conflicting topics. Nevertheless, they need a clear framework and a fixed structure. This includes key points such as regular implementation, the moderation role, a separate role for documentation or minutes if necessary, time management and - if desired - the use of special retro tools. A note on this right away. The five phases of a retro (see above) will help you to adhere to the structure.

You can get help with all of these points if your agency or company does not yet have sufficient knowledge. For example, through training courses or external trainers.

Retros @ Raidboxes

At Raidboxes, we use several forms of retros to organize ourselves. Firstly, the classic Scrum retrospectives for our product development, which now allow us to act much faster. In addition, our support team - and soon also our marketing team - use internal team retros to continuously improve quality.

We are also currently establishing a format that involves all colleagues at Raidboxes. We are still in the discovery phase here. Due to our current growth, it's no longer so easy to get everyone around the table. One idea we are looking into: Each team sends two deputies to the company-wide retrospective on a rotating basis. This would give everyone the chance to get involved.

Themes for the retro

The positive points and challenges that we include in this company-wide format come in part from our employee survey. We conduct this every six months. The prioritization of the topics is quite simple: among other things, we weight them according to how often or urgently a point was rated within this survey.

Another approach could be to collect topics for the retro in the team in advance. If there are too many points for a retro, a vote is taken: Which of these do we want to discuss? All other entries then automatically go into a backlog for the next retro.

Retro Software: Echometer

There are now several tools for carrying out a retrospective with software support. We ourselves work with Echometer, which is also based in Münster. Echometer is a tool that helps to systematically carry out a team retrospective. To capture the potential and moods of your employees.

You can choose from a pool of ready-made questions selected according to psychological approaches, which the participants answer. Alternatively, you can also submit your own questions. Echometer then guides your team step by step through the retrospective from this pool of answers. A particular advantage is that the results are automatically documented and can be compared with each other. After a few retrospectives, you can find out at any time where improvements have been made or where adjustments can still be made.

Sources and further links

Do you want to introduce Retros or Scrum in your agency or company? Here are some further sources:

• Sipgate Blog: Retrospectives as a driver of improvement
• Projektmagazin.de: What is a sprint retrospective?
• t2informatik.de: Methods of the Scrum Retrospective
• echometer: Creative methods for online retrospectives
• Mistakes made during the introduction of Scrum
• Compact introduction to Scrum