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 traditionally known from the Scrum project management method. Software development and web design teams in particular rely on Scrum methodology, because it offers an antithesis to the classically hierarchically organized projects of "I’ll tell you what to do and when". To a certain extent, developers organize themselves in Scrum. Nevertheless, there are fixed structures (e.g. the Scrum board) and fixed time periods (sprints). 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 organisational process again if necessary or 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 for which optimization is desired or which cause conflicts. Initially, all input is allowed here - the joint prioritization takes place only afterwards.
- Gaining Insight: The points recorded are discussed together. What are the causes for positive developments but also for developments that need to be optimised? 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".
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. Aside from purely project-related processes or as a supplement to technical retrospectives, they can be used to strengthen cohesion in the agency or company. There will always be conflicts in any team. It’s essential to deal with conflicts in an open way that is focused on solutions. This way, the organization isn’t just preoccupied with itself or just working to a rigid set of rules.
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 this 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 look in our article on Mental Health in companies.
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 as part of a 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 the management or other senior executives.
- Define set of rules: When misunderstandings or disagreements arise during retros, reminding people of common agency or company values 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 from 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 positive results anchor the retro permanently and are accepted by everyone. Not everyone in your team will get the point of retrospectives from the start. You can only change a mindset of "it's useless anyway” if people can see successes. And if you regularly include 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 and 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 is worthwhile to rely on a project management tool in which the individual tasks are entered. 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 is not exclusively 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. In this case, suitable trainings can help, see for example our blog post on non-violent communication.
Retros should create the space to be able to speak freely about conflictual 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 to keep to 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 at RAIDBOXES
At RAIDBOXES , we use several forms of retros to organize 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 involves all colleagues at RAIDBOXES . We are still in the discovery phase. We are still in the discovery phase here. Due to our current growth, it is no longer easy to bring everyone together at one 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 contribute.
Retros and Holacracy
All this fits well with the approach of Holacracy , which RAIDBOXES has implemented. This is a form of organization that allows for very self-determined work. You can find more information about this in our blog post New Leadership with 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, which is also based in Münster. Echometer is a tool that helps to systematically conduct a team retrospective. To 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: