Making Retrospectives Effective
An Agile retrospective is a meeting that's held at the end of a software development iteration where the team reflects on what happened in the sprint and identifies actions for improvement going forward. Retrospectives, or retros for short, are important meetings to ensure the next iteration of a project benefits from important lessons learned during the previous one.
- 90-minute meetings held prior to planning the next sprint
- Can be shorter or longer depending on the nature of the project
- Result in concrete actions and experiments for the next iteration
- Sets the stage for follow-through and accountability
Five Steps for Effective Retrospectives
Set the Stage
Seek positive goals on ways to improve the project. Focus on specific areas and set all other issues to the side for purposes of the retro.
- The retro meeting leader shares the meeting process and lays out how the team will work together during the session.
- Start with a simple welcome and appreciation for the team’s investment of time.
- Everyone in the room gets a turn to speak.
- Suggestion: Focus-On, Focus-Off activity to break the ice.
- An 8 to 12-minute activity that involves establishing a positive mindset that can foster productive communication and basic working approach for the entire retro.
- Emphasizes inquiry over advocacy, dialog instead of debate, conversation as opposed to argument, and understanding rather than debating.
Create a shared pool of data that considers both objective and subjective experiences to help the team sort through the issue at hand. Subjective experience information, or “feeling data”, can be generated using some specific activities.
- 30-60 minutes to generate ideas for actions or recommendations.
- Divide up into small groups of 5 or less.
- Each person has 5 minutes to individually brainstorm.
- Each passes their paper to the right and repeats the process by expanding on the ideas.
- Repeat until the paper returns to the original owner.
- Debrief as a group.
- What did you notice while you wrote ideas?
- What was surprising? What was not? Why?
- What is missing from the lists?
- What ideas and topics should we examine further?
Mad, Sad, Glad
- 20-30 minutes to get the “feeling” facts out in the open.
- Color coded sticky notes to describe time where they were mad, sad, or glad.
- Cluster, title and debrief.
- What stands out?
- What was unexpected about the cards?
- What was difficult about the card topic?
- What parts felt positive?
- What patterns do we see in the cluster?
- What do those patterns tell us about our team?
- What does this suggest for our next step?
Understand systemic influences and root causes that have emerged by reviewing the data to observe patterns, build shared awareness and to identify system effects that may be at work.
Activities that help generate insights include Fishbone, Asking the Five "Whys?" or Force Field Analysis (which is outlined below):
- 45-60 minutes when proposing a change, to determine what factors will support or inhibit the change.
- Each group works for a few minutes to identify and present factors.
- As a group, they score the factors and examine.
- How can the driving factors be strengthened and how can the restraining factors be mitigated?
- Ask whether enhancing driving factors or reducing restraining factors is more likely to achieve the desired state.
Decide What to Do
Move from discussion to action by settling on no more than two actions or experiments.
- Apply the SMART test to potential action items the team has identified.
- 20 – 60 minutes to translate ideas into priorities and action plans.
- Evaluate goals to validate that they meet the SMART Goal characteristics.
- Select goals that meet the SMART test; discard goals that do not.
Don’t view these goals as action items that will fix the problem. Look at them as experiments to review in the next retro to see if they worked. Incremental change, as opposed to constant change, allows improvement to be made over time.
Close the Retrospective
Reiterate the actions and the follow-up needed. The conclusion is also an opportunity to identify ways to make the next retrospective better.
- Set individual commitments, otherwise people will assume 'the team' will do the work and then no one does it.
- Leave with a concrete plan and accountable parties clearly identified.
- Allow time to appreciate contributions. Allow the team to thank someone else and to appreciate one another.
Retrospective meetings improve software development projects when the team faithfully follows the five-step process that results in actionable experiments applicable to the next iteration. It’s important to set the environment for a retro session that is welcoming; a place where people can speak and where there won’t be retribution. Effective retrospectives can change the way people think.