How Agile Retrospectives Contribute For Team Learning

Hello,

I am privileged to be asked by Dennis Mansell to write a guest post about this fascinating and important topic: Agile Retrospective.

Agile retrospective plays an important role in team building and should be performed at the end of every sprint. The process helps the team identify what worked and what didn’t so that they can make improvements in the next Sprint. For teams’ new to the process, they can do these easy exercises to help facilitate their meetings.

The Sailboat Retrospective

In this exercise, the facilitator draws a sailboat in the middle of a whiteboard or large poster paper. To represent the team. Team members then write on post it notes what they felt was an anchor (something that held them back) and what was the wind (parts of the project that worked and moved them forward). After place the anchors and wind on the board by the sailboat, the team discusses their findings.

The Starfish Retrospective

The facilitator draws a starfish shape to divide the whiteboard into five sections. Each section is then titled: Keep Doing, Start Doing, Do More Of, Do Less Of, and Stop Doing. Through this exercise, the team can look at the project in a different way to see what was effective, what wasn’t, and areas that could be improved.  Rather than assessing what went well and what didn’t, the team looks at the tasks performed during the project in a different perspective.

The Happiness Retrospective

This exercise narrows the context of the project through sequencing of the information. Each team member ranks the people, technology, and the process on how they felt during the project. The team can then discuss what made them feel happy, sad, or in between. The information is collected using a table format on a whiteboard.

Getting Started

Simple things can have a significant impact on future outcomes; the retrospective is one task that can create great change by making improvements in team projects. However, one area of the retrospective continually appears to be overlooked and that is the process of learning.

Most people who run retrospectives do not place enough emphasis on allowing the team to learn from the exercise. Instead, they are often treated as a simple, mechanical processes used to generate ideas only on ways to improve a team.

However, retrospectives in Scrum is so much more. Agile Retrospectives are cornerstones in the inspection and adaptation cycles and, where most of the team’s learning should occur.  By learning from the exercise, teams can create new ways to work on other projects and, at the same time, avoid falling back into their default thinking patterns.

While helping a Scrum Master with her agile retrospective last week, I saw just how successful the exercise was when the team focused on the learning instead of the outcome. I saw first hand how successful the retrospective was when the team changed their priority of the agile retrospective to the learning process. I believe that when teams focus more on learning, the retrospective will always be successful.

To explain, when Agile Retrospectives are run, the focus is primarily on generating insights and ideas for improvement. Teams will often start implementing these ideas immediately without a clear understanding of why or how their actions create improvement.

If teams take this route every time they run an agile retrospective, they will not improve but instead, feel like they have failed again. Therefore, to make an Agile Retrospective successful, the focus should be on the learning and not the outcome.

What Does This Mean?

The facilitator can create an environment that focuses on learning while generating topic to improve outcomes. To further emphasize this point, a few weeks ago, one of my teams tried working with daily sprints. The team got together in the morning and, along with the product owner, chose what they felt was the most important topic. They used the MOB Programming to deliver the story by that evening.

Before the end of the day, the product owner reviewed the story and the team created an agile retrospective to discuss the outcome.  One concern addressed in the retrospective was the amount of productive time they felt they lost. There were many reasons for the loss of time discussed. They then focused on what was believed to be the biggest reason for lost time: time spent on daily tasks like planning, grooming, and the number of sprint meetings. So, one outcome of their agile retrospective was to delay the sprint meeting by one week.

To come to this outcome, they used this template:

We hypothesize by <implementing this change>

We will <solve this problem>

Which will have <these benefits>

As measured by <this measurement>

Using the above template, their outcome was:

We hypothesize by <increasing the length of our sprint to 1 week>

We will <not spend so much time in the meeting>

Which will have <and increase in productivity>

As measured <the number of stories delivered in the same amount of time as before, and by our gut feeling>

The Scrum Master then created a learning wall where the team could post was they had learned during the retrospective. The difference between this format and other retrospectives is when the team revisited the learning wall a week later, they could assess the effectiveness of their changes.  When the changes were effective, the team felt happy; when the outcomes were negative, the team members became frustrated and upset.

Conclusion:

There were two possible outcomes that they could have learned:

1. Increasing the sprint length by 1 week helped the team increase their productivity because they were spending less time in daily meetings.

2. Increasing the sprint length to one week did not help increase productivity because there were other issues that interfered with productivity.

By focusing on the learning instead of the outcome, the team could return a week later to see what they learned from the retrospective and put their findings on the learning wall. In my belief, this style fosters a culture of learning and experimentation, a key component in the agile retrospective.

For more information, you can view this list for agile retrospectives ideas or read Tools for distributed Agile Retrospectives.

I am Luis Gonçalves, an Agile Consultant and an Organizational Transformation Coach. For more valuable information, read my other blogs about Agile. If you are interested in an online training, I am currently developing several online trainings that can be found under: Scrum Master Training..