How To Use The Agile Retrospective in Scrum For Team Learning
How To Use The Agile Retrospective in Scrum For Team Learning
Hi guys! This week, I am bringing you something very simple about the Retrospective in Scrum. Something that I believe can have a huge impact. You know, a lot of times simple things cause a great impact, and I believe this is one of them.
More and more often I see people writing and talking about Retrospective in Scrum, but to be honest, I feel that something is missing. Everyone talks about how to run a great Retrospective in Scrum in order to create action items that will allow the team to get better and improve. In my opinion, the most important part is often forgotten; the learning part.
The way that I see most people running their Retrospective in Scrum does not really allow the team to learn. For most people, Retrospectives in Scrum are just a simple mechanical process used to generate some ideas regarding how the team can improve. Retrospectives in Scrum are much more than that.
Agile Retrospectives are the cornerstones of any inspect and adapt cycle. Even though teams should not limit their learning to Agile Retrospectives, they are quite commonly the place where most of the learning happens. This is because they are a common place for data mining, whereby the team collects information about what happened during the sprint and is able to identify challenges. As a result of all of the learning that takes place during these sessions, teams arrange new ways of working in order to avoid default thinking patterns.
During the last week when I worked with a Scrum Master and helped her with the Agile Retrospective, I realised something interesting. If we focus on the learning instead of the outcome, Agile Retrospectives will always be successful. Let me explain. When we run Agile Retrospectives, most of us generate some insights, get some ideas for improvement, and go into the sprint to try them out. Next, we take a look at the actions that were implemented during the sprint and determine whether or not we improved.
But, you know what? I truly believe that if we take this road every time we do not improve, we will feel like we have failed, and that is completely wrong. So what must we do instead?
Focus your Agile Retrospectives on the Learning, not the Outcome
What does this mean? Quite simply, you as a Scrum Master/Agile Coach/Facilitator can start to create the environment where the main point of the Agile Retrospective is to learn something and not only generate topics with the objective of improvement. Here is a concrete example.
Some weeks ago, one of my teams tried to work with daily sprints. Yes, that sounds crazy, but actually, it can be awesome! Imagine all of you as a team coming together in the morning and selecting (together with the PO) the most important topic that should be implemented, and together using MOB Programming to deliver the story in the evening. Before going home, the story is reviewed by the PO and the team creates a small Agile Retrospective about what can be improved for the next day.
As you can imagine, this is not easy and you need a very mature team in order to achieve this.
In their Agile Retrospective, they felt they were losing a lot of time and they were not productive. They mentioned several possible reasons for the lack of productivity in the team, but they believed there was a bigger cause for this situation. The problem was the time spent in dailies, daily planning, daily grooming, and all of the sprint meetings that they had, but in this case, all of the meetings were happening in one single day.
So they decided to move the sprint length to 1 week. That was the outcome of their Agile Retrospective. At that moment, I coached them to use the template that I use in Agile Retrospectives:
We hypothesise by <implementing this change>
We will <solve this problem>
Which will have <these benefits>
As measured by <this measurement>
So the outcome was:
We hypothesise by <increasing the length of our sprint to 1 week>
We will <not spend so much time in meetings>
Which will have <an increase in productivity>
As measured by <the number of stories delivered in the same amount of time as before, and by our “gut feeling”>
At that time, I talked with the Scrum Master to create a learning wall where we will post what we have learned. Here is where I believe the difference is. Most of the teams would come back in 1 week and see if the changes had any effect. If it was positive, the team would proceed happily with their daily jobs. If it was negative, they would be frustrated and upset.
Focus your Agile Retrospectives on the Learnings
So, by focusing on the learning instead of the outcome, in a week we can come back and see what we did learn. Two options could be:
1) Increasing the sprint length to 1 week, which helped the team to become more productive because less time was spent in daily meetings.
2) Increasing the sprint length to 1 week, which did not help at all and most probably the lack of productivity was actually somewhere else.
The outcome of the learning is then put on the learning wall. You might think this is something very irrelevant. However, to be honest, I believe if you use this approach you will start to create a culture of learning and experimentation.
Consequently, you can always celebrate success because instead of getting focused on something that did not work, you can focus on what the team learned. I truly believe this can make a huge difference in productivity, efficiency, and effective teamwork.
What do you think?
[shortcake_call2action title="ORGANISATIONAL MASTERY SCORECARD" description="We have developed a free assessment in the form of a Scorecard to help you establish which areas of business you need to focus on to achieve your particular Organisational Mastery." button_text="Take The Test" button_link="https://www.organisationalmastery.com/scorecard?utm_source=web&utm_medium=Blog - From Luis Goncalves&utm_campaign=Retrospective in Scrum" /]
If you liked this article, feel free to visit my company Products and Services pages.
We provide Team Coaching, Agile Training, and Agile Consulting, OKR Training, OKR Consulting, Innovation Training and Innovation Consulting.
With my team, I built 5 main products: High Performing Teams, Scrum Team Coach, Scrum Master Mentoring, Organisational Mastery and the External Business Accelerator.
