Continuous Learning in Scrum – How to Conduct Powerful Retrospectives?

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.

• The wind that pushes the boat forward stands for items that help the team to perform well.
• The anchors are things that drag the team down and hinder them from achieving their goals.

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.

• Intention: We would like to onboard a new member of the team.
• Target: New team member is well connected with the team, knows the infrastructure, the tools the team works with, the product scope, the roadmap going forward and practices pair programming in order to learn and broaden expertise.
• Successful if: The new team member can independently work on backlog items and deliver customer-oriented features.
• Failure if: Within the sprint, a good portion of the time is spent to help the new team member work efficiently on the items.

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.

1. You start out by taking one post-it and make it the first post-it in the first group.
2. Another post-it is picked up and the facilitator asks if this is similar to the first one or if it differs. Following that, you will place it in the first group or into a newly-formed group.
3. Once the participants have clustered everything into groups you continue to discuss the most important items from the different clusters.
4. It is now time to attach names to the clusters in order to help you make the information more meaningful and point out various themes.
5. You now have a mutual understanding of the biggest problems the team is facing.

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.

• You draw three sections with the headings start, stop and continue.
• We now place our clusters into those three sections.
• Following we use a dot voting giving each person three votes to vote on those items most important to them. Votes can either be cast on a single item or distributed across multiple.
• Pick the ones with the most votes. Try to really focus on what impacts the team the most. It is a good idea to reflect on actual feasibility and what can be accomplished short and long-term before coming to a decision on the items. Based on the size and scope of clusters it also makes sense to not go for too many action items. A Top 3 is reasonable.

5) Closing

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

Elevate your career with our PRINCE2 Foundation online classes. Gain expert knowledge in project management and master the art of successful project delivery.

Summary
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.