What’s going well in your team and project? And what’s not working quite so well? What steps can you derive from these findings? Retrospectives are a perfect way to bring motivation and momentum into your company or agency. We show you how to set up a retrospective and what the dos and don'ts are with this method.
A retrospective (short: retro) is a sort of review where you determine together as a group, team or complete organization what goals you've achieved in a defined period of time. You can use retros to put your project management or agile software development to the test but they're also suitable for every area within the company. Moreover, retrospective meetings check whether cooperation in the teams is really working smoothly - and how satisfied your employees are.
The basic rules
Retros are particularly efficient. Because each one offers enough room for suggestions for improvement that are immediately transferred into concrete projects. This is exactly what makes retrospectives so valuable and sustainable. When properly conducted, retrospectives work in such a way that:
- allows everyone in the group or team to have their say,
- offers space for different forms of feedback without immediate evaluation,
- is constructive, forward-looking, respectful and transparent.
Retrospectives are by no means only suitable for companies or agencies. NGOs, associations, voluntary groups, open source initiatives or social and political projects can certainly benefit from them too. The open source and WordPress worlds especially appreciate feedback loops that are based on retrospectives. After all, this brings the entire development team on board and discloses decision-making processes.
Retros are just as useful for technical projects as they are for improving corporate culture. Here’s a brief overview of the two variants:
Retrospectives are classically known from the Scrum project management method. Especially teams from software development or web design rely on Scrum, because it offers an antithesis to classically hierarchically organized projects of the type "I dictate what you have to do and when". 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"). Subtasks make the whole thing particularly flexible and thus agile. The retro itself runs in five phases:
- 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 required) and introduce new participants.
- Collect data: This step is for collecting topics to be highlighted in the retro. In other words, points that went well. But also those you want to optimize or that are causing coflicts. Initially, all input is allowed here – the joint prioritization takes places later on.
- Gaining insight: The points recorded are in the previous step are now discussed. What are the causes for positive developments but also for developments that need to be optimized? What can be derived from this for further projects or for cooperation in the team?
- Derive measures: The group decides together which improvement measures should apply to the next sprints. These measures should be formulated as concretely as possible ("who does what by when") and recorded in writing.
- Conclusion of the retrospective: Here you can summarize the results once again, clarify last open questions, pick up all participants and make a short "retro of the retro" so to speak.
For some teams, agencies and companies, this very open form of exchange initially takes some getting used to. Not a lot of feedback may be forthcoming at the beginning and conflicts or mutual reproaches can arise. But there are some ways to avoid this, we’ll look at some tips later on.
Sooner or later, however, retrospectives should lead to the following improvements:
- Timelines in software development or in the project can be better planned and hurdles are eliminated.
- The company creates the necessary technical, structural or human resources to be able to work properly.
- Employees address conflicts more openly and solve them together.
- The team doesn’t only focus on what’s not going well, but also on positive points and process optimization.
- Not only technical challenges are in the foreground; focus is also on collaboration and atmosphere within the teams.
If one or more of these points aren’t improving, the team can work together on the format, the tools, the decision-making processes, the involvement of all participants or the moderation. Or the team decides that certain prerequisites must first be created. This could be, for example, uniform development processes or better communication or motivation within the company.
And this brings us to the second function that retrospectives can have. Apart from purely project-related processes or as a supplement to technical retrospectives, they can be used to strengthen cohesion in the agency or company. No team can do without conflicts. It is crucial to deal with them openly and in a solution-oriented manner so that the organization is not only preoccupied with itself or remains in "work by the book".
Free team retros not associated with Scrum or any other method primarily look at the following three points:
- What has worked well? Where did we work well together and why?
- What didn’t work well? Where can we improve things in our collaboration?
- What do we hope to improve and will we test it? Who'll take care of the implementation and by when?
In this case, a retrospective is less rigidly organized than in Scrum. In principle, the team is free to determine the format in which the questions listed above are dealt with. However, it does help to have a regular format (e.g. a retro every two months), a representative selection of participants, detailed documentation, and written results. And someone who looks after the invitation, moderation and processing.
The topics for the retros should come from the employees themselves, more on that in a moment. In order to initiate the process, it makes sense to regularly collect feedback beforehand. And to provide both support and motivation. For example, in the context of (possibly anonymous) surveys or through a special role in the company. You can read about how this can work in our article on Mental Health at RAIDBOXES.
Employees who’ve previously worked in very hierarchically structured companies in particular aren’t used to making open and courageous contributions to the corporate culture. Something will only change in your company if there’s a framework in which everyone can freely express their opinion.
It doesn’t matter is you’re dealing with a technical or more cultural retro, there are some prerequisites and tools that can help make the meeting a success:
- 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 on rotation.
- Flat hierarchies: It is important that the facilitators lead the meeting as equal participants, not "from the top down". The same applies to people from management or other senior executives.
- Define a set of rules: If misunderstandings or disputes arise during retros, reminding people of common values of the agency or company helps. Not as a list of prohibitions, but in the form of examples that stand for positive communication. See, for example, the Code of Conduct of Raidboxes.
- Binding agreements: This includes recording results in minutes. But also not to decide over the heads of absent persons. 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: Do the measures adopted so far lead to improvements? If not, what can a more concrete conclusion of the retro look like? Can the successes be proven or measured? Is the workload sustainably reduced or does the mood in the team improve?
The last point in particular is important: only through positive results does 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 pretext "It's useless anyway" can only be refuted if successes become visible. And if you regularly pick up all roles in the company.
The don'ts arise in part from the above points. But further risks are lurking if the retrospectives aren’t well thought out or lead in a vague way.
Unproductive circle of participants
Openness and sometimes tact are needed here. It’s detrimental if individuals from the team don’t feel included. On the other hand, circles that are too large - or with too much thematic mixing - quickly become unproductive. If individual topics can’t be clarified in the larger group, they can be passed on to the smaller team retros if necessary.
Not enough transparency
If other departments feel they have no insight into the results of a retro, unrest or frustration quickly arise. Here, publicly visible protocols or the regular presentation of the results to everyone can help. This also applies to measure the success of the approved points.
At the same time, the retrospective itself should be a protected place so that there’s no reservations about expressing criticism in it. Some people will only speak openly about what needs to be improved in such a setting. For example, within one's own team or without the management level. If necessary, the retros can be split up to find the right balance between transparency and the need for protection.
Too strict specifications
Is it always the same participants who speak at a retrospective? Are suggestions quickly shot down? Are individual results already known in advance? That’s not going to work well. Retrospectives are only suitable for agencies and companies in which an open culture exists.
Tasks aren't defined precisely or aren't followed up
The question "who does what by when" is extremely important. Retrospectives require the circle to define responsibilities and deadlines for each idea to be implemented.
On the subject of sustainability of the measures: Here it's using project management tool where you enter the individual tasks. Then you can always see at a glance in which areas a retrospective is going well and where it needs to be improved. Do you have several retrospectives in your company? Then they can measure each other or exchange ideas.
Only technology, no culture
It doesn't matter if it's a Sprint Retro or any other variant, it's not solely about about listing and solving purely technical challenges. The social and cultural interaction within the team should also be examined. Because efficient work doesn't work without team spirit. Development departments sometimes find it difficult to combine the two. In this case, different trainings can help. Check out our article on how we use non-violent communication at RAIDBOXES.
Retros should create the space to be able to speak freely about conflict topics. Nevertheless, they need a clear framework and a fixed structure. This includes cornerstones such as regular implementation, the moderator role, if necessary a separate role for the documentation or the minutes, time management and, if desired, the use of special retro tools. A note on this in a moment. The five phases of a retro (see above) will help you maintain the structure.
For all the points mentioned above, you can get help if your agency or company doesn't yet have enough know-how. For example, through training courses or external trainers.
Retros @ Raidboxes
At Raidboxes, we use several forms of retrospectives to organise ourselves. On the one hand, the classic Scrum retrospectives of our product development, through which we can now act much faster. Furthermore, our support team - and soon we in marketing as well - use team-internal retros to continuously improve quality.
In addition, we are currently establishing a format that includes all colleagues at Raidboxes\. We are still in the process of finding a solution. We are still in the process of finding a solution. Due to our current growth, it is no longer easy to get everyone around the table. One idea we are looking into: Each team sends two deputies to the company-wide retrospective, in a rotating process. This would give everyone a chance to contribute.
Retros and Holacracy
Themes for the retro
The positive points and indeed the challenges we bring to this company-wide format come, in part, from our employee survey. We carry out this survey every six months. The prioritization of the topics is quite simple; we weight the points according to how often or urgent a point was rated within the survey.
Another approach is to collect topics for the retro in advance from the team. If there are too many points for a retro, a vote is taken: which of these topics do we want to discuss? All other entries then automatically go into a backlog for the next retro.
Retro software: Echometer
There are now a number of tools available for conducting a software-supported retrospective. We ourselves work with Echometer, a company also based in Münster. Echometer is a tool that helps to systematically conduct a team retrospective and capture the potentials and moods of your employees.
You can choose from a pool of predefined questions for participants to answer, selected according to psychological approaches. Alternatively, you can also submit your own questions. From this pool of answers, Echometer then guides your team step by step through the retrospective. One great benefit: the results are automatically documented and can be compared. After a few retrospectives, you can always see where improvements have been made or where adjustments are due.
Sources and further links
Are you thinking about using retros or Scrum in your agency or company? Here are some further useful resources: