The Retrospective Meeting: A Golden Opportunity to Learn

In 2007, just before my first encounter with Scrum, I went to a lessons learned workshop as the test manager for a multinational company implementing a global technology and corporate change program.

By this time, I had attended many lessons learned workshops, which often took place at the end of projects, as a way of learning from the past project and improving the next. I enjoyed these events as they were an opportunity to work with the whole team to look at and solve all those day-to-day problems that prevent large complex implementations from succeeding.

I was often excited by lessons learned opportunities, but I was particularly looking forward to this one, since it was taking place midway through the project, and there was a chance that much-needed change would be implemented.

We workshopped away for a couple of hours and ended up with a stack of issues that needed solving, all clearly visible on a very large wall. The session had been productive. At this point, the program manager stepped up and announced rhetorically: “Well, I don’t think there’s anything there that we don’t already know!” And then he closed the meeting. We just shrugged reluctantly and went back to our jobs.

That meeting cost several thousand dollars. What did I learn? That leadership was not listening to its teams. What did the teams learn? Nothing that they didn’t already know. That program did not fare well.

Then I Found Scrum …

I was excited when I was introduced to Scrum and the Agile Manifesto shortly afterwards, since continuous learning is not just encouraged, it is essential.

Sure, learning is essential in a waterfall program, too, but the beauty of Scrum is that it makes it achievable by:

Working with small teams so that shared communication is optimal Embedding frequent inspection into the framework through the daily scrum, review and retrospective

When you’re working with a team to get stuff done, being able to adjust and adapt to not only changing circumstances, but also your own internal team dynamics is pure gold. It is one of the behaviours that make a team great.

How Scrum Facilitates Learning Lessons

The Scrum framework gives the team a sprint goal and empowers them to deliver it. The team is therefore invested in learning about itself.

Because of the daily scrum and the close-knit working relationship of the team members, external impediments are quickly identified and raised, so don’t become “lessons learned” flotsam.

The desire to deliver something of value and put the goal of the team first enables individuals to negotiate “personal preference” impediments. These are the impediments that we all bring to any team we join, and are simply our personal preferences for ways of doing things.

Having a clear team goal helps us to put these to one side when we need to and/or negotiate a shared way of working. In this way, the team culture develops.

The Scrum Master, by practicing servant leadership can support teams and invite them to act as servant leaders to one other. The retrospective is a good event for developing this skill.

The Retrospective is a Gold Mine … But Not Everyone Sees It That Way

The retrospective acts as a container in which a team can influence the next sprint by looking at the last one. It is an opportunity for team members to support and acknowledge one other by reflecting on the good work they have done, and their ability to adapt and find creative solutions.

In a positive working environment such as this, issues and difficulties are more easily resolved and can make the retrospective enjoyable, interesting and productive. Conflicts will naturally occur, but in a culture of mutual respect, they can be resolved openly and for the good of all.

However, I have known Scrum teams to discard the retrospective on the grounds that they already know what the problem is, and believe they would make better use of the time in working to deliver more features, especially since they have not delivered much in the last sprint (or two). This is a team that has lost its way.

The following scene is based on a version of real events …

Enter the Scrum Master.

Scrum Master: O Team!

Delivery Team: Yes, O Servant Leader?

Scrum Master: Have you forgotten that if you do not do Scrum, you are not doing Scrum?

Delivery Team: Go away, for we are busy!

Scrum Master: But what is the sprint goal towards which you strive?

Delivery Team: Um…

Scrum Master: Ah, let us retrospect and entreat the product owner to share their vision so we may be enthused and therefore desire to make it so.

Delivery Team: OK, but the product owner is busy and wants us to just get it done.

Scrum Master: Fie!* Let us retrospect all together as one Scrum team and reflect on the importance of the energizing goal.

*interjection, used to express annoyance

In the past 12 months, I have worked with a number of teams that have been introduced to Scrum and retrospectives for the first time.

And one question I have posed is: “How do we know when we have learned a lesson?” After all, saying that you have learned something is one thing; changing a working practice or behavior is quite another. Change often occurs incrementally. So how can a Scrum Master facilitate this process?

How to Get the Most From Retrospectives

A Scrum Master can help by supporting the team to create its own team charter—becoming a great team is not an accident or coincidence; it needs to be a conscious decision.

The team charter is team created and co-owned by every member. It defines the behaviours and ways of working that will help the team grow and work together. By setting this vision for itself, the team creates something it can reflect on in a retrospective, not as a way of punishing itself for failure, but as a way to honestly look at how it has lived its own principles during the last sprint.

With a clear sprint goal and team charter in place, the retrospective will be a rich source of ongoing learning.

In time, retrospective behavior and thinking can become a part of the daily work: Not everything needs to be saved for the retrospective; equally, not everything can be resolved on the spot.

What I like to do is create an area on the Scrum board called “retrospective,” where team members can stick a note when something occurs to them that may not be an immediate problem, but a creative way to improve the team’s delivery capability. We then review the notes in the retrospective and work with the ones that are still resonant.

This can remove the pressure on team members at retrospective time, as they won’t spend so much time furrowing their brows trying to remember that thing that happened.

Another light touch technique is to get a large white board, draw a horizontal line across the middle, put a vertical start point far left and a vertical finish point far right.

The distance between the two points represents the sprint. The y-axis represents “level of activity”; the top is “frenzied activity,” the bottom is “nothing, zero, zilch.”

Now, ask each team member the draw a line from left to right over the life of the sprint that shows their level of activity as the sprint progressed (different colours work well).

It’s fun, and when done, there is a clear pattern that the team can see. Often the team will annotate sudden plunges or spikes. This technique can be a good place to start if you have a team that often inflicts three days of frenzied activity on itself at the end of every sprint.

In sum, I’ve been through many variations of “lessons learned” meetings throughout my career, and this is what I have learned so far:

Some lessons have to be learned many times. Some lessons are learned quickly, some slowly, bit by bit. Some are never learned. But, the most important lesson of Scrum, for me, is to challenge the team to take responsibility for its own development by creating a charter, trust it to live those principles and remind it to reflect on them at the retrospective meeting.

Choosing a Retrospective Topic

I am a firm believer that the best retrospectives tend to be focused on a specific topic. Picking a theme and exploring what we currently think of it, and how we can improve in that area is almost always more productive for a team than having a general "how can we get better" conversation.

But how do you pick the topic? There are a few common ways for teams to do this ...

Ask The Team

Dedicate some time at the start of the retrospective to ask the team what they think the topic should be.

This could be as simple as giving each member of the team three sticky notes and asking them to write a topic on each, then gathering them all on the wall and looking to see if there is a clear majority winner such as "Dealing wiht bugs."

Perhaps there are some connections that make sense to tackle together.

Alternatively, we could ask each team member to write three feelings on sticky notes and do the same exercise of clustering them on the wall.

We might then end up having a retrospective on frustrattion. Why are we frustrated? How could we become less frustrated in our next sprint?

Ballot Box

Technically, this is still in the "ask the team" area, but there is a difference in that this is anonymous and in real time before the retrospective as opposed to at the start of the meeting.

With ballot box, a box is placed in the team area where team members can post cards with an idea for a retrospective topic as they occur during the sprint.

Then, at the start of the retrospective, we just empty the box and see what ideas we have, and make a decision.

ScrumMaster Choice

In my Scrum Mastery course, I explain that I believe ScrumMasters should always reserve the right to pick the topic that the team should explore in a retrospective.

An elephant in the room is what the English refer to as an obvious truth that is going unaddressed.


Sometimes the team may be too nervous to address the topic that really needs addressing and in those cases, the ScrumMaster should be prepared to help the team by highlighting it. 

As with anything, if the elephant is avoided for long enough, the team will develop coping mechanisms.

The problem is, these coping mechanisms don’t deal with the issue and actually make the problem even less likely to be removed because it doesn’t seem quite as necessary any more.

Great ScrumMasters courageously expose, and encourage teams to explore, the elephants in the room as soon as they notice them.

They don’t judge, but neither will they let their team tolerate and get dragged down by these problems.

Instead, they offer to lead an exploration. For example, the elephant in the room could be that one of the team members is getting into the office later and later.

The team is accommodating him by shifting the daily scrum and, sometimes, writing up their conversations, but this is leading to inefficient teamwork and resentment is growing in the team. 

Before this spirals into outright anger and rebellion, the team should confront and solve the problem.

A great ScrumMaster acts as a mirror for the team so she can reflect back what is happening in the team.

This is not a finger-pointing exercise but done with as much compassion as ruthlessness so that the team feels this is important enough to tackle but not defensive about admitting it needs tackling.

I recently blogged on compassionate ruthlessness here.

There is always room for good old ScrumMaster intuition. During the sprint, ScrumMasters are in a privileged position, able to see a lot of what is going on with a certain detachment.

They can -- and should -- be listening to what is being said and what is not being said, looking out for good examples of team dynamics and development as well as opportunities for further team growth.

Great ScrumMasters have no issue with starting the retrospective with a challenge based on their own observations, for example:

“This sprint, I have noticed a larger proportion of time than normal has been spent on fixing defects. I wonder if it would be a good idea to take some time out to explore why this might be and what we could do about it.”

Set The Team Up

Whichever method you choose, and you will definitely take the context of the situation into account, it's almost always a great idea to start the retrospective with a compelling goal that engages the team and helps set them up for success.

Most of the time, this goal will come from the team, but sometimes, it's OK for the ScrumMaster to step in and challenge the team with a compelling challenge to explore. 


Should The Product Owner Attend The Retrospective?

One question I get asked a lot is:

Should the product owner attend the retrospective at the end of the sprint?

The word “should” makes this a multi-dimensional question, so first, I want to address a slightly different question.

Can the product owner attend the retrospective?

This one is easier to answer, because according to the Scrum Guide:

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

Since the Scrum Guide also states that the Scrum team = product owner + Scrum Master + development team, we can deduce that (officially at least) the product owner is allowed to attend the retrospective.

Now whether they should attend is not as easy. Having worked with many many Scrum teams and seen many, many retrospectives, I have noticed two patterns:

The best Scrum teams tend to have their product owner attend their retrospectives The worst Scrum teams tend to have their product owner attend their retrospectives

What I have determined from these two patterns is that the product owner attending a retrospective tends to have a big impact on the development team in one way or another. In the positive examples, it is a very clear symbol of everyone acting as one team, working together collaboratively to improve the overall situation with true transparency and respect.

In the other cases, I see teams avoiding issues, scared to speak up and customers looking for individual SMART goals for improvement and targets for velocity growth.

Going back to the Scrum Guide, the Scrum Master is responsible for “removing impediments to the Development Team’s progress,” and if the product owner being present at the retrospective is proving to be an impediment to the team feeling comfortable and exploring their situation, reflecting upon it and identifying ways to improve their process, then you could argue that the Scrum Master should remove that impediment.

As a coach, the Scrum Master would most likely coach the product owner in the impact they are having on the team, and how that is ultimately affecting the results they are receiving from the development team. This is because, in an ideal world, having the product owner present at the retrospective has got to be better than not having them there.

As the Scrum Guide points out, the retrospective is for the Scrum team, and any decisions that are made in order to improve the Scrum team’s process will inevitably impact the product owner. Making decisions is an important part of our THEMED structure of facilitating retrospectives:

Topics to help everyone focus in on a specific area
Hooks to engage all attendees as soon as the meeting starts
Events of the last sprint or iteration using interactive exercises
Meanings behind the events
Else - exploring variations on the exercises or considering alternative perspectives or things they might be missing
Decisions they need to make as a team to move forward

You can find out more about this structure and get some ready-to-use templates for retrospectives in my newest course with agile coach Paul Goddard -- the "THEMED Retrospective Handbook" -- here.