Luis Goncalves
Last updated on | Agile Retrospectives General

How To Use The Agile Retrospective in Scrum For Team Learning

by Luís Gonçalves
Retrospective in Scrum

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.



Give Me My Exercises

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?

Rate this post:
Luís Gonçalves

About Luís Gonçalves

Luis is not simply a consultant, he helps people and businesses grow. He expects to deliver 10 times more value than what you’d actually pay for. As an Agile retrospective expert, customer happiness and client success are his biggest drivers!


Share your point of view

  1. Great article! Do you go through posted learnings from the learning wall in next retro and if yes, how do you handle this outcome of learnings? The learning wall is great idea to use no matter there are or not retro actions. Post your learnings during the sprint and share those in retro.


    1. Hi Tomi,

      To be very honest we started this approach now 🙂 🙂 So I am not sure How we are going to handle it 🙂 Maybe every second month having a lunch break where we check what we did learn? I do not know honestly I am still trying to figure out what to do next 😉


  2. Very Good Article…This is completely inline with Doing Agile Vs Being Agile….and leads to actual transformation than just doing mere Agile Adoption….

    Sometime people end up doing a template version of Agile Retrospective without judging/acknowledging the power of true retrospective…..which we need to refrain but face challenges in doing so…

  3. Nice! This approach has the same elements as the Toyota originated Improvement Kata by Rother (problem – target – pdca) that teaches systematic *learning*. However, I feel the approach presented here is a lighter and probably somewhat easier to adopt than Improvement Kata. IK requires experience and discipline from the coach and it can be a bit of “overkill” if you don’t have any major problems at hand. This approach instead can be used in every retrospective if you wish – even though you wouldn’t have any major improvement them ongoing. Thanks for sharing, Luis!

  4. I am leading a Retrospective this morning. Maybe I will steer clear from the typical,what went well? What are areas of improvement? and ask, “What did you learn in this sprint?”. Let’s see how it goes