Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Facilitating Effective Agile Retrospectives

DZone's Guide to

Facilitating Effective Agile Retrospectives

Agile retrospectives help teams reflect, learn, and improve. Teams should leave the retrospective with actions that they'll do in the next iteration.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

This article is featured in the new DZone Guide to the Software Development Lifecycle: QA and Testing, Volume II. Get your free copy for more insightful articles, industry statistics, and more!

Agile teams use retrospectives to reflect, learn, and adopt their way of working. Let's explore how you can do effective agile retrospectives and what facilitators can do to get more value out of them.

An agile retrospective, or sprint retrospective as Scrum calls it, is a practice used by teams to reflect on their way of working, and to continuously become better in what they do. The whole team, including the product owner, attends the retrospective meeting. In the meeting they “inspect” how the iteration (sprint) has gone, and decide what and how they want to “adapt” their way of working to improve. Actions coming out of a retrospective are communicated and done in the next iteration, which makes retrospectives an effective way to do short-cycled improvement to deliver software faster with higher quality.

One technique that's often used in agile retrospectives is to ask questions to the Scrum team, and collect and cluster the answers to define improvements that the team will do in the next iteration. Asking questions is a technique that is easy to learn, but the effectiveness depends on the questions that you ask to the team. Questions that I often use and which have proven to help teams find things that they could improve upon are:

  • What helps you to be successful as a team?

  • How did you do this sprint?

  • Where and when did it go wrong in this sprint?

  • What do you expect, from who?

  • Which tools or techniques proved to be useful? Which did not?

  • Did we have any major bugs? How did we solve them?

  • What is your biggest impediment?

  • If you could change 1 thing, what would it be?

  • What caused the problems that you had in this sprint?

  • Where did things go wrong in coding/testing/etc?

  • What’s keeping you awake at night?

  • Which things went smoothly in this sprint? Which didn’t?

Here are some examples of the answers that came up using these questions:

  • Several team members stated that they expect that the team starts and ends the stand-up on time and that all are present. Action decided was that someone who showed up late or was absent without notice had to buy the team a cake. Stand-up became shorter and more effective.

  • Our biggest impediment is that we cannot test our software in a live environment. As a result, the team got access to the production environment to do integration tests.

  • The team felt that things went smoothly because they focused on getting things done together and helping each other. Since the company's reward system was still focused in individual behavior they started a discussion with their manager and HR on how to reward team behavior.

There’s a risk of teams getting bored when retrospectives are always done in a similar way and the same actions come up. A solution to this is to introduce variation by using different retrospective exercises, and by making sure that actions get done (more on that below). Another thing that you can do is to chance the setting for the retrospective. Go outside, hop over to a nearby meeting center or training facility, visit a museum, or have a drink or dinner together. Basically try anything that moves team members out of the daily routine to help them take a fresh look at how they are doing and find new things to improve.

Facilitating the Retrospective Meeting

The retrospective facilitator has to do everything needed to make retrospectives valuable for the team. This includes:

  • Planning the meeting and assuring that team members can attend.

  • Selecting appropriate exercises and preparing them.

  • Running the retrospective meeting effectively.

  • Guarding the culture in the room, creating a safe environment where people speak up.

  • Setting the conditions for effective follow-up on the actions.

The retrospective facilitator must have the proper skills to organize and lead the meeting:

  • Excellent communication skills: Listen, ask questions, recap discussions.

  • Servant leadership: Process focused, independent, supportive to the team.

  • Maintaining an open culture: Encourage people, manage conflict, give feedback.

  • Goal-oriented: Planning and execution, able to adapt and improvise.

Who facilitates the retrospective? In most teams it’s the Scrum master who leads the retrospective, but it can also be another team member or a Scrum master from another team. Or it can be an agile coach, process responsible, quality manager, or even somebody from HR or a line manager. The position or role that the facilitator has is irrelevant; what matters is that the person can act as an independent facilitator and has the right skills.

My advice for a new team is to have an external facilitator for their first couple of retrospectives, instead of their Scrum master doing it. Such a team has just started on a journey to discover how to work in an agile way, and that means changing the way people work together. This change impacts everybody on the team, and will have a significant impact on how the Scrum master plays its role. Having to lead the retrospective, and reflect on the teams’s and your own behavior and learn at the same time is hard. Therefore, my advice is to have the whole team, including the Scrum master, focus on the learning and get someone else to facilitate the meeting.

Getting Doable Actions, and Getting Them Done

Agile retrospectives are a great way to continuously improve the way of working. Getting doable actions out of a retrospective and getting retrospective actions done helps teams to learn and improve.

Actions can be technical, e.g. trying a new coding pattern or testing technique; process based, like doing code reviews or pairing; or in the way the team works together, like trying something new in the stand-up or changing the setup of the task board.

Real continuous improvement from retrospectives starts with making the results of the retrospective meeting actionable. Make sure that the team leaves the room with actions that they can and will do in the next iteration.Add those actions to the team status board and/or to the backlog, so that they are visible and will not be forgotten.

Here’s an example from a team that I worked with. They did a retrospective, and found out that since there was a multidisciplinary team, the skills and knowledge were spread out. In some cases there was only one person who was capable of doing certain work, which was undesirable to them.

They defined an action to “do more pairing.” The action itself is still somewhat vague, but we agreed to use any opportunity for people to work together and develop new skills. This made the action doable.

During the iteration there was a task that was stuck. A piece of software needed to be tested, but the testers were busy testing other modules. A developer mentioned during the stand up that he wants to do it, but has little testing experience. The Scrum master asked the testers if one of them could pair with the developer to help him get started and learn how to do testing. He referred to the action on the task board, reminding the team that this was something that they decided to do in this iteration.

One of the testers stepped in, and the two people paired for just a couple of hours.

It turned out that this was more than enough for the developer to do the testing. With some additional questions he was able to finish the task. In next iteration she picked up more testing tasks and became better attesting. The team was able to do more testing this way,which helped them to get user stories finished.

In your actions you should also mention the “why:” the reason that you are doing the action, the problem you expect it to solve, the benefit that team will get from doing it, etc. This will motivate team members to do the action.

Retrospective Facilitation Good Practices

To keep the retrospective effective, facilitators should focus on the following:

  • Establishing an open and honest culture in the meeting.

  • Ensuring that all team members participate in the meeting.

  • Ensuring that the team establishes a shared understanding of how things went.

  • Helping the team to decide upon the vital few actions that they will take.

Here’s a couple of practices that I recommend for facilitating retrospectives and make them valuable for the participants (for more practices and tips, see 7 Retrospective Facilitation Good Practices).

Many retrospective facilitators use the prime directive to establish a culture where team members speak up and will be open and honest. It sets the assumption that team member did the best they could possibly do, and that the purpose of the retrospective is not to blame people.

Retrospective facilitators must be able to deal with negative issues. Help the team to focus on the issue and understand them and don’t blame any team members for what has happened. This requires strong communication skills, being able to pay attention to verbal and non-verbal communication. For retrospectives with remote or distributed teams, facilitators should be able to make communication issues explicit and visible, keeping everyone involved and maintaining a good meeting culture.

A facilitator should serve the team in the meeting, and should not lead them based on their own opinion on what the team should do. It is important that a facilitator remains independent, which again can be challenging when the facilitator is also the Scrum master of the team.

Retrospective Exercises

As a retrospective facilitator it’s important to have a toolbox of retrospective exercises which you can use to design a retrospective. Before having a retrospective meeting, you want to prepare yourself by considering which exercises would be most suitable. That depends on the team, the situation at hand, and on what the team would like to work on.

Possible exercises that retrospective facilitators can useare a one-word retrospective, perfection game, exploringstrengths with core qualities, and futurespectives. As an example, this is how you can do a one-word retrospective where there are issues in a team that need to be discussed:

Start by asking each team member to state how they feel about the past iteration in one word. Note these words on a flip chart or whiteboard. When everyone has spoken up, ask team members to describe why they feel this way. Stimulate adiscussion where feelings are shared about theteam that often don’t reach the surface. Once team members recognize the problems, change the discussions towards actions to solve the team issues. Put these actions on the team board to make them visible for the next iteration.

My advice to retrospective facilitators is to learn many different retrospective exercises. The Retrospective Exercise Toolbox provides many exercises that facilitators can use to design valuable agile retrospectives. A great way to learn new retrospective exercises is by doing them. Practice an exercise, reflect how it went, learn, and improve yourself. You may need a specific exercise one day, so make sure that you are prepared.

More Agile Goodness

For more insight on TDD strategies, Agile retrospectives, and more, get your free copy of the new DZone Guide to the SDLC!

If you'd like to see other articles in the guide, be sure to check out:

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,retrospectives ,teamwork ,agile implementation

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}