Scrum is an empirical process – as a part of the journey to become self-organized, the team goes through transitions as they face challenges to implement meaningful software that creates value for the end user. Retrospectives are a key instrument to trigger actions and the ideal catalyst of a changing behavior. Therefore, placing particular emphasis on conducting powerful retrospectives goes a long way and will change the face of the product in the long run.
What is a retrospective?
A retrospective is conducted by the Scrum team at the end of an iteration reflecting on how well the team worked together and what problems influence the performance of the team members. Retrospectives are a safe forum for teams to openly discuss and help to facilitate change. It is advised to keep iterations short (2 weeks ideally), especially when a new team is forming.
Longer iterations of 4 weeks, for example, result in retrospectives carried out only once a month, which can prove to be dangerous. Changes do not frequently happen within the team when in fact it is needed as a result of a sub-optimal process being dragged along for weeks.
How to run an Agile retrospective meeting?
A popular technique is the “5 steps of a retrospective”, which defines a guide for valuable Agile retrospectives and how to facilitate team gatherings to discuss its way of working and to identify actionable items how to work more efficiently in the future. let’s see various Agile retrospective techniques below.
1) Setting the stage
Don’t jump right in but let people “warm up”. When working with teams I really like to use an exercise before the actual gathering of data about what went well and wrong.
Ask 3 questions picking subjects that are “hot” matters within the team for instance and do pairings of 2. In rounds of 3 minutes, people get to discuss those topics and align with each other to formulate opinions and exchange thoughts. This is a perfect way to prepare everyone for step 2 where the actual way of working is inspected.
2) Gather data
This is where the magic happens. Time to talk about the details and surface the problems that the team is struggling with. There are hundreds of methods existing on how to structure a retrospective and produce valuable results. The quintessence is to find out what method is fitting the team’s circumstances. It is not a one size fits all.
A general approach - discuss what works well and what doesn’t
A popular method is the sailboat method.
This is a great method to do a health check on the team. What’s important is that not only the negative aspects are talked about but that those aspects that really drive the team forward are put into consideration.
Formulating a direct goal
Not all retrospectives have to be rigorously focused on only talking about what went well and what went wrong in the past sprint. If they do indeed it may create the risk that the same items come up and are discussed over and over again.
Let’s say for instance that there will be someone new joining the team in order to support on development. The direct goal would be to onboard the new team member efficiently.
What you can use here is a method called “Success Criteria”. This exercise revolves around clarifying intentions, target outcomes and results for success criteria.
As the name suggests you plan for the actual success of a goal but you also try to anticipate how a failure scenario may look like. In our example, the activity would structure in the following steps to take.
Summarized, this method helps the team align on upcoming processes that need to be handled in order to be fully focused on the product delivery process and plan ahead.
3) Generating insights
After gathering the data it’s crunch time and bringing the outpouring of ideas, problems, and opportunities into a digestible format where actionable items can be produced from.
A popular technique is to use Affinity Mapping to cluster and bundle facts and ideas together.
4) Decide What To Do
In this step, you produce the actionable items you will focus on. By using Affinity Mapping we have identified patterns and attached names to the different clusters.
It is now time to decide what to do. This can be accomplished by using the method “Start, Stop and Continue” originally introduced by Esther Derby and Diana Larsen in their book “Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers) and enhance it with a dot voting system.
The closing is often underestimated and the group dissolves after the action items are clear. Reflect on what you have just achieved.
Use the “Takeaways” method (Judith Andresen – book “Erfolgreiche Retrospektiven”) and ask everyone to write a note to reflect on the one thing that was outstanding for them in this retro. Each participant then reads out their own note to the group.
Alternatively, use the “Retro dart” method (introduced by Philipp Flenker) to end on a high note. This is a little retro inside a retro.
You draw several dartboards and write a question next to the board (see image above). The participants then add post-its to the dartboard. 100% agreement is right in the middle and 0% outside the disc.
For further inspiration, check out Philipp Roger’s trello board
For a scrum team to be successful it is essential to conduct effective retrospectives to review their way of working and align their processes. It matters what method is used to improve a process or overcome a problem and which idea you use to improve your Scrum Retrospective. After all the product benefits from this and actions defined in a retro will increase the time to market. So, next time you think about skipping a retro, don’t because it may influence your product delivery.
Your email address will not be published. Required fields are marked *