Running Effective Retrospective Meetings

In the last article we talked about why it's a good idea to do a retrospective regularly – right? I had mentioned in that article that we will be having a separate article to talk about how to conduct effective Retrospective meetings that are productive and add value to the scrum team/project.

The Basics:

Before we get into conducting or running a retrospective, there are a couple of prerequisites or like I tell my team, there are two important ground rules that we need to follow.

Rule 1: No Management Team in Retrospective

Even though Scrum advocates that the scrum team shouldn't have any roles like a lead or manager, it is very difficult in real life to run an organization without people managers. The Retrospective is supposed to be an open discussion where people can share their opinion and ideas freely. The presence of someone from the management team is a very big detriment to an open discussion.

As Scrum Master it is our responsibility to ensure the meeting is productive and does not get impacted due to the presence of the management team.

Real life trivia: The senior management team may suggest to you that, their presence will give them an insight into the mindset of the team or get to hear first-hand their suggestions. But, trust me – their presence will only result in the team being more cautious and reserved about what they are going to say and end up missing vital improvement points. One of your scrum team members may feel that senior management isn’t supportive enough on the project initiative and keep pulling out members to work on adhoc assignments which is impacting team velocity. But, if someone from senior management is present in the meeting, do you think he/she will be willing to say that point out loud? Even if management team members promise to keep an open mind and not be judgmental of the team, the fear factor will always linger in the teams mind and will result in pointless retrospective discussions.

So, what if your Management Team insists on attending the meeting?

As Scrum Master, there are a couple of things you can do:

1.     Educate the members of Management that their presence results in people being more reserved and isn’t resulting in effective discussion

2.     Explain to the members of the Management that, you will eventually collate all the improvement/feedback points and as representative of the scrum team, you will bring all those points to their attention/review

Every member of the management team would be interested in understanding how they can help the scrum team/project and if you help them understand that their presence is causing a problem, most likely they will listen. More importantly, if you are committing to share the suggestions with them, they don't have the need to actually attend the meeting personally – isn’t it?

Rule 2: No Finger Pointing or Blaming during Retrospective

This again is a very important ground rule that I try to enforce during my retrospectives. When we are blamed for some mishap, it is natural human tendency to become defensive and try to refute the allegation and defend ourselves. When one member of the team points a finger at another and blames them for some mistake, the discussion deviates into the more of a personal attack territory which is firstly unwarranted and secondly uncomfortable for all parties in the meeting.

I always try to keep the discussion from getting into that territory and all team members are encouraged to share their points without pointing fingers at other members of the project team.

Bonus Rule: Full Attendance

This one is a no brainer. In order to collect feedback from all members of the team, I try to schedule the retrospective on a day that the entire team is present. Of course, unplanned sick leaves are unavoidable but usually I schedule the meeting and request all participants (including product owner) to attend the session.

Running a Good Retrospective

Ok, coming back to the topic at hand of running a good retrospective, I try to follow the simple/tried & tested – Start/Stop/Continue Approach.

I like to run the retrospective by asking team members what would they like to Start, Stop and Continue doing. Each team member takes turns and suggests points that they think the team should start or stop or continue doing – plain and simple.

Some examples could be :

•      We should start doing code reviews to improve code quality
•       We should continue to have a quick demo with the product owner after we finish story development and before the full-fledged testing of the story starts
•        We should all start showing up on time for stand-ups
•        We shouldn't start work on a story or task until the current assigned task/story is completed
•        And so on…

You may be wondering – what will go under the Continue option?

Usually, new ideas that go under the start category must be checked for their effectiveness in the subsequent retrospectives and if the team feels the idea was good, they can reiterate the same by including the point under the Continue category. After a couple of sprints if the team is habitually following the suggestion, we no longer need to include that point in the continue section as well.

Spice Things up

Sometimes, this start/stop/continue may become too monotonous if we do the same thing again and again. Team may feel the meetings are becoming boring. You may think of ideas to spice things up.

We could do things like – pass a stick pad bundle to all participants and ask them to write their suggestions, fold up their point and put it in a basket. After 30 mins, we start taking out one item at a time and the team can discuss on the point. Or you could ask a different member of the team to run the meeting every week so they too understand the tricks of the trade.

Or, we could document all the key takeaways from the retrospective and start off the next sprint retrospective by looking at these points and evaluating if we have really worked on the improvement items. in my projects, I document the sprint wise retrospective findings in a wiki and we review the previous weeks improvement points and assess where we are before we add more entries to the list. This way the team understands that you as the scrum master are serious and aren’t doing this to just tick off one of the recommended meetings list.

Some last words:

I personally find that this start/stop/continue method is fast, easy and effective way to run a retrospective. By not associating any names and focusing only on actions, we don't waste our time on feelings. We don't need to worry about whether team members are happy or sad – we just focus on work.

Each item we document will directly result in change in the way we work. The team will start doing newer or better things, they will stop low value activities and continue to strive towards being a better team as a whole. That's the point behind the whole retrospective meeting isn’t it?

What do you think? Do sound off in the comments section…