As a project management expert, you know that Lessons Learned meetings are an essential tool. Agile teams take this a step further. With the agile retrospective, you start thinking about the lessons learned and how to improve the collaboration even before the project is over – starting at the very beginning and continuing at regular intervals.
Such agile retrospective meetings aid the continuous improvement of processes, methods, and teamwork.
This article covers the following topics:
Let us get started with the definition of agile retrospective!
Agile Retrospective: Definition
Retrospectives in project management are regular team meetings with the aim of continuous improvement based on past experience. In various “reviews”, team members evaluate together what went well and what did not. In addition, they analyze why things went well or did not meet expectations. Measures to improve processes, methods and teamwork are formulated and implemented.
The basic concept of a retrospective is anchored in the 12th principle of the agile manifesto:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
Agile teams work in preferably short intervals called iterations (aka “Sprints” in Scrum). These can be viewed as development cycles, but they also represent learning cycles because it is assumed that complex endeavors require a step-by-step approach in which it is necessary to frequently pause to evaluate oneself and the (intermediate) results. “Inspect & adapt” rituals are therefore a key ingredient of each iteration.
This gives you the opportunity to significantly influence the further course of your project. Three factors are analyzed and, if necessary, adapted:
The iteration review meetings or product review meetings with the stakeholders at the end of each iteration serve to evaluate and adapt the product. It also benefits the further development of its functionality, thanks to the stakeholder feedback.
What remains are the aspects of processes and teamwork – which the agile retrospective meetings, aka agile sprint retrospectives, are designed to address. Retrospectives are held at the end of an iteration, just like the review.
Thus, the agile retrospective differs from the Lessons Learned meetings used in traditional project management, especially with regard to the timing and frequency. With projects planned in the traditional manner, you generally have to sit down with the team once at the end of the project to discuss what happened and what has been learned. With agile teams, this happens on a regular basis after each iteration – before the next iteration begins. This enables you to immediately apply what you have learned to the current project, instead of merely gathering these findings to use on some future project.
Stakeholders can be invited to attend a retrospective meeting, but their presence is normally not necessary. If the team wants to speak openly and honestly about the iteration that has just ended, having stakeholders present can be a hindrance.
Agile coaches (a “Scrum Master” in a Scrum Team) help the team identify good practices and possible improvements that can be used in the next iteration. An agile sprint retrospective is therefore a joint team event – and experienced coaches always have a sufficient repertoire of formats to support this effort.
Candor and honesty are therefore essential in a retrospective.
Although the team might be quite satisfied with its accomplishments, with the team members congratulating themselves on a job well done, it is also important to be open about any critical issues and discuss these. This includes any feelings and emotions.
Provide a safe space for dealing with these.
At a minimum, the following people should participate:
An agile retrospective typically takes up to three hours, depending on the length of the iteration being reviewed.
Experience has shown that a meeting with five phases is most effective:
Generally speaking, no special retrospective methods are necessary for holding an agile retrospective, with its individual phases, for your team. It is also not necessary to strictly follow each of the individual steps listed here, although the meeting generally quickly progresses from one step to another. The important thing is to end the meeting with an agreement on 1-2 specific improvements for the next iteration.
Experience has shown that the team often runs out of agile retrospective ideas and loses creativity after a few retrospectives. There is then an urge to abolish these retrospective meetings. Or the project team still has no idea how to ensure that the retrospective meetings are productive and creative.
For these situations, there is a wealth of retrospective methods and moderation techniques for engaging your team and making it easier and much more exciting for the team to work on improvement processes.
Our tip: A website with a trove of good agile retrospective ideas is Retromat: it provides formats for every phase of the retrospective. In the next section, we present a selection of these.
Please note: Teams generally enjoy trying these various techniques, but they can also be a bit overwhelming or exhausting. So, keep in mind that: less is more.
Experienced team coaches use 1-2 methods per agile retrospective. They repeat some methods occasionally to avoid asking too much of the team. They sometimes completely omit one or the other a few times in between.
Choose the methods best suited to your team’s level of development or experience. The “starfish” is a classic format that is easy to use and understand and even works remotely if you use an electronic whiteboard.
For a format such as “Writing The Unspeakable”, on the other hand, you need a team that can meet undisturbed in a separate room and has members that know and trust each other well.
Our tip: Gently introduce your team to the latest retrospective techniques. Choose a rather simple method. Over time, you can progress to more demanding techniques.
Do many of the issues discussed deal with the environment in which your team works? If so, it makes sense to involve the stakeholders as well at some point.
You might also enjoy reading our blog article on agile contract models.
ESVP: Each team member is asked, in turn, which of these they feel like in today’s retrospective meeting:
Each person writes the first letter of their choice on a piece of paper, and the papers are collected anonymously. If any of the papers show a V or a P, this is discussed. Why does someone feel like a “vacationer” or a “prisoner” in this meeting? What needs to change to improve the team’s attitude toward the retrospective?
Sailboat / Motor yacht: Together, the retrospective participants view a picture of a boat on a flipchart or something similar and then, after writing the issues important to them on sticky notes, paste these sticky notes on the area of the picture they feel best represents their issue. Is the issue related to something that:
Our download tip: Here is the template for holding a remote retrospective using the sailboat exercise. You can copy and use it for retrospectives with your team.
5 Whys: Originally developed by former Toyota CEO Taichii Ohno. Just as a child would do, we ask the question Why? five times. Let us look at an example.
Problem: We missed the delivery deadline for our new product version.
What caused the problem? Conflicting priorities among the stakeholders; the priorities were not coordinated well.
Taiichi Ohno believed the source of the problem would be pretty clear after the fifth “Why?” question. After doing this exercise, you can discuss the result and brainstorm ideas for avoiding this problem in the future. For example, it might be helpful to escalate the problem to the next higher level or help stakeholders reach an agreement.
Using colored dots to vote: Present the measures suggested in the retrospective phases and then ask participants to vote on these using the colored dots they have been given. Each person is given two or three colored dots to allocate as they see fit to indicate the measures they deem most important. They can give all their dots to a single measure or distribute them among several measures. The measure with the most dots is implemented in the next iteration.
Respect and appreciation: Each team member is asked to personally thank or praise another participant for something specific that that person contributed to the project. It can be for the help they gave or their strong commitment. After everyone has contributed, the retrospective can be concluded.
Is your team a group of experienced professionals already very familiar with retrospectives? If so, here are a few retrospective examples of methods you may not have used before:
In a futurespective, as the name suggests, you look ahead to the future instead of back to the past. This is especially useful at the project’s start when the goals and objectives are being defined and the risks are being identified. Possible formats that have proven successful are:
Another interesting read: Agile Project Management Certifications
It is also enlightening to repeat an exercise such as this at the project’s halfway point to see what has changed since the project began.
Liberating Structures was originally developed to act as a counterpoint to monotonous presentations ‒ “Death by PowerPoint” (too many slides with too much content) ‒ and endless meetings in which everyone just sits there waiting for them to end. It is a collection of formats designed to extract innovative ideas from the group by using the swarm intelligence of the group’s participants. This technique is useful in other areas as well, but it works especially well in retrospectives.
Tip for beginners: 1-2-4-all: A topic is presented (to encourage more fun and creativity, the question can be formulated in a negative way. For example: “What is the best way to hamper our company’s agility?”).
Agile games are not only helpful for teaching agile methods in introductory workshops, but the gamification principle has also shown that formats using games and / or competition are more effective than discussions or presentations. They lead to a better long-term understanding of what has been learned. Familiar simulations such as Ubongo Flow Game, Lego4Scrum, and the Fearless Journey awaken participants’ playful instincts and function as direct, and often tactile, learning experiences.
Tip for beginners: White Elephant Sizing:
Some of the formats discussed above are intended for groups meeting in-person in a room. Project teams are increasingly global though and collaborating remotely. However, that does not preclude the use of innovative retrospective formats.
In the agile retrospective, it helps to not only have a good videoconferencing tool (ideally with the webcams turned on so that everyone can see each other), but also the following tools:
Note: A possible retrospective template for items 3 and 4 is the sailboat graphic in the figure above (find the download of the sailboat graphic here).
The Miro software shown below provides another retrospective template.
Ideally, your team comes up with at least one concrete, immediately implementable idea in the retrospective. It is important that the team actually implements this measure and that their efforts are taken seriously by those around them so that the team feels that the retrospective was worthwhile and productive.
You should therefore document improvement measures in the backlog.
Treat these with the same diligence as a functional or technical requirement in the next planning meeting: as something that must be planned and accomplished.
Metrics you can use to track the success of the implementation are:
In this article, you have read about:
Make the effort to tackle this topic and contribute to greater project success with regular agile retrospectives!
What has been your experience with the retrospective in agile project management and possibly with specialized methods? We look forward to hearing from you via the contact form or another channel.
Our final tip: Sign up for our bi-weekly blog newsletter to make sure you receive all our updates.