Focus your Sprint Retrospectives on learning, not on the result
In the Sprint Retrospective, the Scrum Team evaluates itself and makes a plan for improvements that can be implemented during the next Sprint. No matter how good a Scrum team is, there is always room for improvement.
The Scrum Master organizes the meeting and ensures that everyone receives sufficient information in advance. All team members are present, not only the Scrum Master but also the Product Owner must participate. Team members who want to leave the team may not be so motivated, but their contribution is important. The point is that the entire team is present.
The Sprint Retrospective takes place after the Sprint Review and prior to the next Sprint Planning. It comes down to a three-hour meeting for a one-month sprint. For shorter Sprints, the meeting is usually shorter. Occasionally, a hot topic will arise or a team conflict will escalate. The retrospective will then take longer. It is important that everything is discussed.
During the Sprint Retrospective the team discusses:
- What went well during the sprint.
- What sprints can be improved.
- How the team will tackle the improvements in the next Sprint.
The role of the Scrum Master during the Sprint Retrospective
The Scrum Master encourages the Scrum Team to:
- To improve the development process and methods.
- Making the next Sprint more effective.
- Make it more fun for the next Sprint.
- All work processes to be considered for improvement.
- To question the definition of “Done”.
- Keep the entire sprint against product or organization standards.
The Scrum Team plans Retrospective activities during every Sprint to improve product quality. The team also assesses whether these improvements do not conflict with the standards of the organization .
Although a good Scrum team is constantly looking for opportunities for improvement, the Sprint Retrospective is the moment when everyone sits together and all thoughts can be shared. The short special meeting is planned to deliberately think about ways to improve the sprints.
There are many ways to run a Sprint Retrospective. It is often recommended to make it a start-stop-continue meeting. This is the simplest and often the most effective way to perform a retrospective. Using this approach, each team member is asked to name specific things that the team should do:
- The team must start with.
- Must stop.
- Keep going with.
There are many variations on this simple format.
- The Scrum Master prepares the Sprint Retrospective meeting by asking everyone to remember ideas during the scrum.
- He asks everyone in the room if something should be started, stopped or continued.
- He asks everyone to focus on things that should be stopped because there is not enough attention for stopping. After brainstorming about the ideas, a vote will be taken on which specific items will be focused during the coming sprint. At the end of the sprint, the retrospective often starts by assessing the points for improvement that were selected in the previous sprint retrospective.
Implementing points for improvement
Towards the end of the Sprint Retrospective meeting, the Scrum Team identified the improvements it will implement in the next Sprint. The Scrum Team will assess the implementation of these improvements in the next Sprint. Although improvements can be implemented at any time, the Sprint Retrospective offers a formal opportunity to assess the adjustments.
Learn from the Sprint Retrospective
The Sprint Retrospective can have a huge impact. However, the most important part is often forgotten; the learning section.
Often teams do not really learn from their Retrospectives. For most, a retrospective in Scrum is just a simple mechanical process that is used to generate ideas about how the team can improve. Sprint Retrospectives are much more than that in Scrum.
Although you should not limit learning to Sprints Retrospectives, they are often the moment where most of the learning takes place. This is because the moments are when the team collects information about what happened during the sprint and is able to identify challenges. As a result of all the learning that takes place during these sessions, teams devise new ways of working and avoid wrong thinking patterns.
If we focus on learning instead of the result, a Sprint Retrospective will always be successful. During the Sprint Retrospectives, team members often generate a number of insights. You get ideas for improvement and you start the next sprint to try them out. We then look at the actions that were carried out during the sprint and determine whether we have improved.
But what happens if you can’t improve anything? Do you feel that you have failed? That is not good.
Focus your Sprint Retrospectives on learning, not on the result
Assume that the most important point of the Agile Retrospective is to learn something and not just to generate points for improvement.
So by focusing on learning instead of the result, we can return to our learning points during the Sprint Retrospective and see what the results are. There are two options:
- The adjustment worked, making the team more productive. Less time was spent in daily stand-ups.
- The adjustment did not help. Increasing productivity must be achieved somewhere else.
The outcome of the lesson is placed on the learning wall as a reminder. You might think that this is irrelevant. However, if you use this approach, you create a culture of learning and experimenting.
In this way you can always celebrate success, because instead of finding that something didn’t work, you can determine that the team has learned something.
Scrum as a quality system
Sprint Retrospectives are the cornerstones of every assessment and improvement cycle. The whole purpose of Scrum is actually a quality system according to the ideas of Deming. Deming came up with the Plan – Do – Check – Act quality cycle. You see this PDCA cycle in scrum where the Sprint Retrospective is one of the Check elements in addition to testing the software.
Retrospective in a SaaS project
For SaaS projects, workshops are often organized in which consultants get to see the user requirements . The workshop is the start of a sprint that is about a subsystem or a function of the software. After implementation , there is an opportunity to test whether the software works as desired. By starting the workshop with an evaluation of the previous sprint, a retrospective is built into a SaaS project. The next sprint therefore starts with what was learned from the previous sprint.