A retrospective is a meeting to look back over an iteration, release, or project, specifically to discuss what worked well, what could be improved, and most importantly, how to translate the lessons learned into actionable change. Retrospectives are a forum for the team to improve upon their process. They’re an integral part of Scrum and Extreme Programming (XP).
Retrospectives directly address one of the twelve principles of Agile: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This can result in: improved productivity, better capability, higher product quality, and happier team members.
- The value of retrospectives
- How to conduct retrospectives effectively
Retrospectives directly address one of the twelve principles of Agile: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.1
A retrospective is a meeting to look back over an iteration, release, or project, specifically to discuss what worked well, what could be improved, and most importantly, how to translate the lessons learned into actionable change. Retrospectives are a forum for the team to improve upon their process. They’re an integral part of Scrum and Extreme Programming (XP).2
The purpose of a retrospective is to inspect and adapt.
This can result in:
- Improved productivity
- Better capability
- Higher product quality
- Happier team members
There are always opportunities for continuous improvement, no matter how good you already are.
Retrospectives are the basis for an overall continuous improvement process:
- The process is primarily applicable to short format retrospectives (more on retrospective forms on slide 9)
- At the retrospective, the team identifies and plans for improvement activities. The team then makes some change. At the following retrospective, the team checks on the implemented changes and decides what further actions to take
The scope for a retrospective can include anything to do with the team or the project outside of direct story work. Matters can be categorized as follows:
- Technical matters
- e.g. Lack of skills with technologies used on the project
- Development process matters
- e.g. Automated build process keeps breaking down and is not getting fixed
- People and team matters
- e.g. Some team members are not fully engaged or are not in the room enough
A team will be motivated to implement improvements because of the following reasons:
- They deal with real problems that affect the team
- Team members should see value in the planned improvements and will be excited to see them implemented
- They do not need management permission
- Improvements happen within the team
- They are chosen, not imposed
- Improvements are chosen by the team, providing feelings of self empowerment and responsibility
The retrospective should involve:
- The team – anyone directly involved in the iteration, release or project:
- Project manager(s)
- Customer and client
- Et al.
- A facilitator – somebody familiar with the team, project and process, but not directly involved with the project
- Set The Stage – Prepare the team
- Gather Data – Create a shared picture of what happened
- Generate Insights – Gather data, interpret and analyze it
- Decide What To Do – Think ahead to action items for the next iteration
- Close the Retrospective – Reflect on what happened, wrap up
- Prepare the team for the work they’ll be doing in the retrospective
- Usually only takes 5 minutes or less.
- Can be as simple as:
- Making introductions
- Reviewing the goal(s) for the retrospective
- Checking on the status of activities defined in the previous retrospective
- Reviewing the agenda
- Checking in3
- Should take about 15 minutes
- A typical activity is creating a timeline
- Determine start and end dates
- Have the team write Post-it notes and place them on the timeline, or have the facilitator add them
- Post-it notes can be colour coded or dots added to indicate feelings about the events, e.g. glad, sad, mad
- Allow the team to dig deeper into what happened on the iteration, release or project
- Length of time will vary:
- Short format retrospective – about 30 minutes
- Long format retrospective – 1 or more hours may be required
- Similar to a timeline, observations can be recorded on cards and placed on whiteboards, or they can be recorded by the facilitator
- Two example activities:
- What went well, what didn’t go so well, …
- More, less, keep, start, stop
- Ask the team these questions:
- What went well?
- What didn’t go so well?
- What could we have done better?
- The questions do not need to be followed sequentially
- The team can write their insights on Post-it notes and place them on the board, or the facilitator can record them
- This is the preferred activity for a long-format retrospective
- Ask the team these questions: What could we…
- Do more of?
- Do less of?
- Keep doing?
- Start doing?
- Stop doing?
- Actions can be written on Post-it notes and placed on the board by the team, or recorded by the facilitator
- Preferred activity for a short-format retrospective as it leads to specific actions
- Identify key issues and priority actions:
- 1. Prioritize key issues
- Dot voting and/or affinity analysis
- 2. Brainstorm actions
- 3. Prioritize actions
- 4. Assign actions
- Be realistic about how much time you’ll spend on continuous improvement.
- Choosing one or two high priority actions is more likely to result in success rather than a long bucket list
- Important to allow the team to reflect on what happened during the retrospective, and to provide closure
- Should take no more than 5 to 10 minutes
- Some sample activities:
- Recap – the facilitator reviews key insights and actions, the team confirms next steps.
- Appreciations – team members share appreciations with others using the following format:
- “I appreciate person X for something Y.”
- Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. The definitive guide to Agile retrospectives.
- Project Retrospectives: A Handbook for Team Reviews by Norm Kerth. A good complement to Agile Retrospectives.
- Agile Retrospective Resource Wiki : shared retrospective plans, tips & tricks, etc.
- Retrospective Plan: a collection of detailed retrospective plans you can run or take inspiration from.
Derby, Esther and Larsen, Diana, 2006. Agile Retrospectives: Making Good Teams Great. The Pragmatic Bookshelf, Raleigh, North Carolina.