Our Thinking

Running Effective Sprint Retrospectives: or, How I Learned to Stop Being the Expert and Learn From my Team

Posted by Ben Lucas on Sep 30, 2013 9:54:09 AM

Most teams that I have had the chance to work with seem to go through the Group Formation Stages of “forming, storming, norming, and performing” identified by psychologist Bruce Tuckman. As a Scrum Master, it is necessary to help teams navigate through these stages so that they can become highly performing teams.

The Sprint Retrospective is one of the key tools in Scrum that can help teams identify the blocks that they are experiencing and identify concrete actions they can take to improve as a team. Unfortunately, the Sprint Retrospective frequently becomes routine with team members going through the motions of answering the questions of what worked and what didn’t work.

Where it all Falls Apart

The idea for this post comes from an experience I had with a team that was struggling to escape the storming stage. I wanted to provide a means for the team to see the value of teamwork and the detriment that individual mentality can have. So, I selected a retrospective game that emphasizes these characteristics.

The team was subdivided into two groups that were given a task to build a house of cards. Each group, however, was given slightly different scoring instructions. One group was scored as a team while the other had individual scores. Traditionally, this should have met with the individual-scoring group being drastically outperformed.

Unfortunately, that is not how it turned out. The team-scoring group struggled to stand up any cards. In under a minute, the individual-scoring group had a first floor on their house of cards.

All I could tell the team was that I was surprised by the outcome and obviously had something to learn from the experience. What I observed was that the individual-scoring team almost immediately threw out the scoring system and operated as a team. Their group also had somebody who had previous experience building a house of cards and the team accepted his expertise and applied it. Clearly, the group knew how to operate as a team.

What I Learned

The most important thing I learned is that you never know what to expect. Rather than coming in as an expert, it is more important to treat every experience as an opportunity to learn. After all, this drive for continual improvement and continual learning is one of the fundamental principles behind Agile software development. If we can’t model this behavior of continually learning and improving, how can we expect the teams that we lead to do the same?

Being a Scrum Master is much more than being an expert; a Scrum Master needs to be continually learning. A primary source of education for the Scrum Master is the team that they are serving. This fits the following principle from the Agile Manifesto: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Applying What I Learned

Fortunately, the story does not end there. The following retrospective, I was determined to not repeat the mistakes from the previous retrospective. This time, I selected an activity in which the team discussed the five values outlined in the Scrum Code of Ethics: Commitment, Focus, Openness, Respect, and Courage. Instead of having a pre-determined expectation as to where this would lead, I walked the team through the meanings of each of the values and let them share their thoughts on how they were doing as a team. This time, I sat back and listened and just recorded what the team stated.

Towards the end of the retrospective, it is important to identify an action that the team can take to improve their efforts. Instead of letting the team list out many actions that would never get done, I encouraged the team to pick a single action that they could try during the next sprint.

Conclusion

Sprint Retrospectives can easily lose their value when teams just run through the motions. They can also lose their value when the Scrum Master stops facilitating and makes assumptions about what will happen during a retrospective. Use of alternative activities or games can bring a fresh perspective to a team and help improve the value of a retrospective. Likewise, recognize that the point of the Retrospective and Agile practices is to be a constant learner.

If you would like more ideas for how to run sprint retrospectives, the following sites may be helpful:

 

Topics: Agile Development, Application Lifecycle Management (ALM), Methodologies

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates

Recent Posts