What I’ve Learned About Scrum Retrospectives

Since our Agile transformation began 9 months ago, I have been able to observe over 100 retrospectives spanning 10 dedicated Agile teams.  It’s pretty fascinating to watch the evolution of a newly formed team turn into a well-functioning and dynamic group.

Every team has their own language and interactions and it’s important to give the team the time and space to go through Tuckman’s phases of group development naturally.  Over the past couple of months, I have heard the term “family” being used more and more by the teams to describe the relationships they are starting to form with each other.

While the very nature of Scrum (with daily stand ups and common workplaces) feed into creating this experience, I feel that well-crafted and well-designed retrospectives also play a role in making this happen. In my opinion, the retrospective is the most important meeting in Scrum – this is when the “family” takes care of “family matters.”

So, what makes some retrospectives more meaningful or powerful than others?  I have captured 5 observations:

The product owner sets the tone. Having a fully engaged and receptive product owner allows the team to learn that they can share “bad” news or areas of improvement in front of the product owner without repercussion.  I have seen some retrospectives with seemingly uninterested product owners and the team dynamics are noticeably  reduced – sometimes dramatically.  It’s also a powerful example when the leader admits improvement areas and takes accountability for their actions (for example, “I could have done a much better job detailing that acceptance criteria for you guys.”)  The comfort of the team to share openly will happen almost immediately after this happens.

The healthier the team, the fewer the words from the Scrum Master. During early retrospectives, it’s important for the Scrum Master to use facilitation techniques to draw some of the dialog out of the team and make sure the team becomes familiar with the retrospective process.  As the team becomes more comfortable with themselves and the process, the need for these techniques should be reduced.  A true self-healing team will talk through the issues and will be able to solve internal team issues without outside influence.  Scrum Masters, you will need to test this every once in awhile by putting yourself in the background and see if the team is ready to take over.

Creativity matters. From time to time, change up the approach to facilitating the retrospective.  If the energy begins to feel low or if they begin to shut down, using creative and unique facilitation approaches with the team may be necessary.  I have seen some great retrospectives when team members create a drawing of what worked well or isn’t working.  Maybe have the retrospective outside or at a local establishment.  Try the Seven Pillars of Agile exercise with the team.  There are many other techniques out there so don’t be afraid to experiment.

Engaging with remote team members is hard but not impossible. It’s not always easy when team members are participating in a retrospective from remote locations.  Often times, the remote team members will send an email or instant message to the Scrum Master with their feedback and the Scrum Master will transfer that information to index cards.  There are also online collaboration tools that can be tried and if possible, try using video conferencing as well.  There is nothing like face to face conversation but it’s worth the effort to make the experience of remote employees as close to being in-person as possible.

Change topics should be captured and made visible. For meaningful improvements within the team and as a constant reminder, identified areas to be changed or improved should be captured and displayed somewhere within the team area.  This may be at the task wall or if you are using a virtual task wall, sketch them out on a large piece of paper and stick it on the wall. Bring the list of changes to the product grooming sessions, planning meetings, and close meetings and do a quick review of them prior to getting the meeting started.


Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

4 thoughts on “What I’ve Learned About Scrum Retrospectives

  1. Len, I would turn your second observation around: the fewer words from the scrum master, the healthier the team. By that I mean that in order for the team to really engage, they must realize that their meetings, and especially their retrospectives, are in fact *their* meetings, and not simply a series of reports to the scrum master. Changes indicated by the retrospectives have to be made by the team. If the scrum master is drawing the conclusions and making recommendations and taking charge, teams will sit back and “observe” rather than engaging.

    • Completely agree Jacque…team sessions should be owned by the team with the Scrum Master there just to facilitate getting to the desired outcome. The best retrospectives (and most Scrum meetings) I have seen are when the Scrum Master drops some pens and cards on the table and hovers in the background, looking for signs of deteriorating team health and dysfunction.