Iteration retrospectives are the structured reflective practice for the team to learn and improve their ways of working based on the experience of the past iteration. The purpose of retrospection is to examine the process the team uses, to build team commitment, and to transfer knowledge to the next iteration and possibly to other teams.
Retrospectives are usually done at the end of every iteration (but be pragmatic about this!), and they are designed to be a “safe space” for the team where they can share their thoughts and ideas freely.
Why to Do This Practice
During each iteration, during every activity, the team should help each other think about quality issues.
Improving quality involves discipline and mutual commitment. Lean techniques – such as retrospections, keeping a clean environment, testing, and a correct use of patterns and attention to code quality – all help, but only when the team uses them regularly.
One of the goals of agile/lean is to create and share knowledge, collaborating proactively both within the team and within the larger organization. Outcomes of retrospectives can be shared within the organization in order to accelerate value realization and learning.
Who Does This Practice
Here are the roles involved in this practice:
- The whole team is involved in the retrospection. The retrospective is primarily for them.
- The team lead is typically the facilitator for the retrospective.
- The product owner may be involved.
Management and other outsiders are almost never involved in the iteration retrospective. In part, this is because the iteration retrospective is designed to be a “safe place” for team discussions. Sometimes, their input may be valuable to the team’s improvement process; therefore, in exceptional cases, they may be invited by the team to join for a part of the meeting.
What to Do
Inputs to the iteration retrospective include:
- Team availability. The essential prerequisite for a retrospective is that everyone who was involved in the iteration be available. The reason is that everyone has some viewpoint about what happened. If someone is missing, an insight will be lost.
- Facilitation. The team lead (or other facilitator) is prepared to facilitate the meeting.
At the end of each iteration, the whole team conducts a retrospective, usually facilitated by the team lead
The main objective of the retrospective is to identify things to “keep doing”, “stop doing”, and “do more of” and “do less of.”
The key question for the retrospective is,
“If we could do it again, what would we keep doing and what would we improve?”
To answer this, the team can discuss topics such as:
- How well did we do in the iteration? Did we meet the iteration goals?
- How is the project progressing?
- What were our successes? (ask everyone)
- What processes / techniques would be good to use again?
- What were our challenges? What could have gone better? (ask everyone)
- What processes and techniques need to be improved?
- How is the team being? Are we raising impediments? Are we adjusting?
- What impediments are still present?
- On a scale of 1-10, what is the score of this iteration?
The retrospective should be time-boxed to an hour or less.
The retrospective should be facilitated, and different techniques can be used to engage the team and gather information. It is important to realize that retrospectives can go stale – a team that has gone through a number of iterations may not be able to easily come up with novel ways of improving.
The Evolve Way of Working process goal could be a source of inspiration.
The retrospective should result in one to three stories for the next iteration reflecting a “vital few” improvements to the process, to which the team agreed to commit collectively.
It is important to keep improvement activities visible: some teams keep them on a separate improvement board, others add them to their regular work board.
When to Do This Practice
It should be held at the end of each iteration to allow the team to steadily improve over the course of iterations, and it is important that it is held directly at the end of the iteration while the experience from the iteration is still fresh in the minds of the team members.
Where to Do This Practice
Iteration retrospectives are designed to provide a “safe space” for the team where they can freely share their thoughts and ideas. If the team is colocated or near-located, it is best to have the retrospective meeting in a separate room; if the team is virtual make sure that only the directly involved people participate.
The benefits of this practice include:
- A focused set of improvements that can be immediately put into practice.
- Building a habit of improving. The team as a whole and individuals on the team get in the habit of looking for ways to improve.
- The team builds a sense of ownership for their processes.
Impediments to progress that are outside of the team’s control are naturally escalated to management and others who can do something about them.
Product Owner Overview
- Acceptance test-driven development
- Capturing functional requirements
- Controlling work-in-process (WIP)
- Daily coordination
- Decomposing a feature into stories
- Iteration demonstration and review
- Iteration demonstration and review (plan)
- Iteration planning meeting
- Iteration retrospective
- Operational metrics
- Unfinished work
- Visual controls