Agile Retrospectives: A Tool for Team Learning
By Luis Gonçalves | Co-founder of Evolution4All, Founder of ScrumMaster Growth
An Agile retrospective is an effective tool used at the end of every iteration to analyze the team’s performance during the project.
Team members gather to review what worked well and what did not so they can improve their performance on future projects.
For companies that are unfamiliar with retrospectives, there are tools and exercises they can use to make the sessions run more smoothly:
- The Sailboat exercise uses illustrations to identify the strengths and weaknesses. In the diagram, the team is the boat while the “worked well” parts are the wind and the “did not work” areas are anchors. Once the team has established what worked and what did not, they can discuss improvements they can make for the next project.
- The Starfish retrospective does not focus on what worked versus what did not. Instead, it uses five categories to address what the team should keep doing, start doing, stop doing, do more of and do less of. The diagram helps the team reflect on varying degrees of success or failure with each part of the project.
- The Happiness retrospective analyzes how the different areas of the project made each team member feel during the project. Each member rates their feelings towards the team, process, and technology as sad, happy, or somewhere in between. Once everyone has inputted their feelings, the group can discuss each area to find improvements for next project.
The Learning Component
Agile retrospectives are a simple yet highly effective way to improve team performance for software projects. Many industry professionals often provide insight or advice on running a great session to make their team work better and improve performance. However, one area of the retrospective that tends to be overlooked is the learning component.
Most retrospective sessions do not create opportunities for the team to learn from their experience. For some, it has become merely a mechanical process and part of the project closing. While the session might generate ideas on ways to improve, it often does not encourage actual learning.
Retrospective Scrums are so much more than just an end-of-project meeting. They are the cornerstone for all inspection and adaptation cycles. While teams should not limit their learning just to the retrospective, the truth is this is where most of the learning occurs. It is the most common place for data mining, or collecting information about the sprint; what happened and the challenges faced.
The learning that can be done during the session becomes secondary to the ideas that are generated by the team to avoid default thinking patterns in future projects. When the focus on agile retrospectives is on the learning, they will always be successful.
Agile Retrospectives with a Focus on Learning
To illustrate this, a Scrum Master recently ran an Agile Retrospective for her team with the focus being on learning. Like most retrospectives, the team looked at the project, provided insight on what worked or did not work, generated ideas to improve performance and then went into the sprint to try the ideas.
Rather than focusing on the outcome of the idea, the team paid attention to the learning that occurred. They ended the process feeling successful because not only did they learn something, but they were able to objectively discuss topics and solutions for improvement.
By creating an environment where the focus is on the learning aspect and not the outcome, the facilitator was able to run a successful session.
In the traditional method, when the focus is more on the outcome, the team may often feel like they failed when they discuss their actions and find their implementations were ineffective because they did not learn anything from the process.
Another example occurred recently when a team tried to work with daily sprints. They met in the morning with the product owner to discuss the topic that they wanted to implement. Using MOB Programming, the owner and team were able to deliver their story that same evening.
Want to expand your agile & scrum knowledge? Check out our 3rd annual Agile & Scrum Conference here.
Before their day ended, the team and product owner met for an agile retrospective. While not an easy meeting, the team members were highly professional and mature.
One issue that was listed was the amount of time lost during the day. There were several possible reasons for their time management issues but the team felt that the biggest waster was the time that members spent on planning, grooming, and meeting for sprints. Rather than hosting daily sprints, the team decided that it would be more beneficial to only have weekly sprints. They came to this conclusion using this model:
We hypothesize by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
Their sentences read:
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 <an increase in productivity>
As measured <the number of stories delivered in the same amount of time as before, and by our gut feeling>
During the Sprint meeting one week later, the Scrum Master created a learning wall so that the team could provide input on what they felt they learned during the week. In this method, the staff could measure and clearly see if their changes were effective. The team felt happy when they were successful but frustrated and sad when their changes did not work.
There were 2 possible options they could have learned:
- Increasing sprint meetings to one per week, staff would spend less time in daily meetings which would improve productivity.
- Increasing sprints to once per week would have no effect because there were other external factors interfering with the level of productivity.
Either way, the team felt that they had succeeded in their learning objective.
By focusing their session on the learning aspect, the team assessed and discussed what they learned during the week. They could then use their knowledge to initiate improvements and adaptations in their behavior for the next project. In this session, the team felt successful because they learned from their experience.
Learning is a vital part of the Agile Retrospective that is often overlooked. By focusing more energy on the learning part rather than the outcomes, the team will feel more successful as they adapt their behavior and implement changes to improve their performance for future projects. For more information or ideas, visit this List or read Tools for Distributed Agile Retrospectives.
About the Author
He is co-author of Getting Value Out Of Agile Retrospectives which has more than 25,000 copies distributed and discusses the importance of Agile Retrospective.