I would like to first thank Agile Alliance for letting me write this guest blog. Agile retrospectives is a topic that I am very familiar with and I want to share a couple of thoughts on that topic.
I have trained many companies with this exercise to analyze their software projects and improve their teamwork. I have written many publications about Agile, Agile Retrospectives, Scrum, and Scrum Masters and have played an instrumental role in facilitating sessions for companies.
Agile retrospectives are a vital part of the end-of-project process where team members meet to discuss what worked and what did not. Retrospectives are used to improve team efficiency so that they can better perform in future projects.
For teams that are new to the process, there are simple exercises to help facilitate and simplify the retrospective. These exercises include the Starfish Retrospective, the Sailboat Retrospective, and the Happiness Retrospective. Each exercise uses tables and images to assess the positives and negatives of each project in easy-to-understand formats.
The Sailboat exercise uses pictures to illustrate what moved the team forward and what held the team back. A sailboat is the team, anchors hold the team back and the wind moves the team forward. Each team member can write what they believe was wind and what was an anchor. Then, the whole team can discuss their findings.
The Starfish retrospective divides a board into five sections to categorize what they should keep doing, start doing, do more of, do less of, and stop doing. This exercise allows the team to look at the outcomes differently.
The Happiness retrospective uses columns to list what part of the team, process, and technology made each member feel happy, sad, or somewhere in between. This exercise focuses more on feelings and less on what worked or did not work. Once the information has been gathered, the team can collectively discuss their findings.
The simplest thing can have the greatest impact. The Agile retrospective is a simple process but its outcome can greatly affect how future projects are handled. Agile Retrospectives are a great exercise to create a call-to-action so that the team can improve their strategies in upcoming projects.
However, as great as the Agile retrospective is, one area that I believe is continually overlooked is the learning process of the session. Retrospectives in Scrum are not just about identifying what worked and what did not; they are the cornerstones of any inspect and adapt cycle.
While teams should never limit their learning exclusively to the Agile retrospective, the reality is that this is where most of their learning occurs. Retrospectives are a common place for team members to collect information about what happened during the sprint, while also identifying the challenges. Teams can then take what they have learned in the session to develop new ways to work on projects and avoid default thinking patterns.
I have come to realize that if we focus on the learning part, retrospectives will also be successful. To explain, most team members provide insights or ideas for improvement during the session then go into the sprint to try their ideas. But when they go back to look at their actions to see what worked, they come away from the sprint with a feeling of failure because they did not improve. But what did they learn from the process?
To improve the team, the focus of the Agile retrospective should be on the learning and not the outcome. This simply means that the facilitator should create an environment where the focus is on what people have learned from the process instead of just generating topics or ideas for improvement.
To illustrate this point, a few weeks ago, one of my teams tried working with daily sprints. As crazy as this may sound, it was a wonderful opportunity. The team got together with the product owner in the morning to select what they felt was the most important topic to implement. They used Mob Programming to deliver the story by evening.
Before going home at the end of the day, the product owner and team met to create a small Agile retrospective to discuss what worked and what could be improved for the following day. This was not an easy task and took maturity and professionalism from the whole team.
One problem they discussed was the amount of time spent on daily tasks like planning, refinement, and sprint meetings. They felt that the “dailies” took too much time away from their work; there were too many sprint meetings in one day. The outcome of the session was to hold the sprint meeting one week later instead of the next day.
The template that we used to determine this outcome was:
We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
It read as follows:
We hypothesize by <increasing the length of our sprint to 1 week>
We will <not spend so much time in the meeting>
Which will have <and increase in productivity>
As measured <the number of stories delivered in the same
amount of time as before, and by our gut feeling>
Per my recommendation, the Scrum Master created a learning wall for the team to post what they learned during the session. The difference between traditional methods and this style was that, when the staff returned a week later, they could see if their changes were effective. The team was happy when the outcome was positive, but frustrated and upset when their outcomes were negative.
The two possible outcomes were:
- Increasing the sprint length by one week helped the team become more productive because it decreased the amount of time spent in daily meetings.
- Increasing the sprint length by one week did not help the team become more productive because there were other reasons for the lack of productivity.
By focusing their retrospective on the learning component, the team could assess what they did learn from the initial session one week later. They could use their findings to improve and adapt their behavior in future projects.
By focusing on what the team learned rather than what did or did not work, the team will always feel successful. This is what I believe to be the biggest difference in the productivity, efficiency, and effectiveness of teamwork.
For more information on this topic, you can find different ideas on this list or, for distributed teams, by clicking on Tools for Distributed Agile Retrospectives.
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-150x150.jpg)
![[Case Study] Lessons from descaling 25 Scrum teams](https://www.agilealliance.org/wp-content/uploads/2024/12/descaling-teams-1200x630-1-300x158.jpg)
