What is a retrospective?
(from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place.
, a retrospective is a meeting held with a project team at the end of a project or process to discuss what was successful about the project, what could be improved, and how to incorporate the successes and improvements in future projects.
, a retrospective is a meeting held by the project team at the end of every iteration/sprint to discuss what we learnt as a team, what we can improve as a team and plan the future iteration/sprint based on this learning.
Why do we need retrospectives?
- Improve learning: Reflection is a key step in learning from experience. Retrospectives can help you capture the continuous learning process of a team and take it one step further.
- Communication and Feedback mechanism for any agile team.
- Helps the team to adapt their process based on their learning of what works and what does not work. In other words, it gives a team a way to adapt process to their context.
- Helps the team to consciously work towards improving work quality, satisfaction and work culture.
- Helps the team self organize by empowering the team members.
Retrospectives should be focused at improving customer and team satisfaction. Which means, we have to focus heavily on people and the process around them, their interactions/communication patterns, workspace and work culture. Everything else is secondary.
They can be 15 mins to 2 days. As long as the group have or feel something important to discuss. If retrospectives are always lengthy, it might mean you need to increase their frequency. Even after increasing the frequency does not solve the problem, it means something important on the project is broken and it needs to be fixed.
Lots of factors contribute towards this. Team size, experience working together, nature of the work, etc. Ideally you need frequent retrospectives to begin with, but as you go on, it should become less frequent and shorter. Most of the agile projects end of the iteration/sprint is a good time to have a retrospective.
The schedule of a retrospective is very important. Trying to mix them up with lots of other meetings on the same day can make it very ineffective. Participants should not feel like it‘s just another meeting. I would ideally conduct a retrospective at the end of the iteration/sprint and before the planning meeting. Outcome of the retrospective can greatly affect the next iteration/sprint planning.
Same location as the team room can be a mind block. [Too much of the same thing.] I prefer a conference room with a lot of white boards, open walls [visible surface] to stick cards/posters and food. It should be away from people‘s workstations and phones. Some people prefer going to a bar/pub for these meetings.
It is difficult to say who would be a good facilitator. But it‘s easy to say who should not play the role of the facilitator. Team leads, Iteration Managers, Scrum Masters, Managers, etc are a big NO NO. You want an unbiased person who has sufficient knowledge about the project and process. Having someone from the team facilitate has the risk of turning the discussion towards personal goals. Getting someone from outside can reduce personal conflicts. But at the risk of not having a focused discussion targeted towards the real pain points. The discussion can turn out to be very superficial.
Ideally the team and not just the manager. We want to build self organized teams who can constantly learn and fix problems.
Retrospectives are brainstorming session which should try to identify issues, find the root cause and try to come up with an unanimous resolution. If we just identify issues and leave them, what next? Who would resolve it? This would make the retrospectives a bitch session. Trying to come up with a unanimous resolution drives home the team ownership aspect.
Mixed feelings. While we need to start somewhere, the way to identify top 3 issues can be very difficult. If you have different number of people playing different roles [Dev, QA, Analyst, etc] on the team, the voting would be heavily biased towards the majority of people in a role. Developers might get their issues prioritized while QA issues might be neglected. Often different people rate issues differently. Letting team members own the issues and resolve them based on their priority can help the team overall.
Team members skipping retrospectives is a big project smell. Even if someone is not interested/willing to speak, they can still listen to other team member‘s perspectives. The team should focus on creating a work environment where all the team members have the sense of ownership. Once this happens, even if you try to stop people from attending retrospectives, they won‘t miss it.
The whole team including the customers. Some times it is helpful to have chickens, other team members as silent spectators. It is important to have honest and open communication with in the whole team. Retrospectives have really helped my team build trust with the customer by improving communication and increasing visibility thru retrospectives.
Mixed feelings. Retrospective is a way to resolve communication problems and give feedback. By having distributed people participate in retrospectives we might introduce the same issues with low quality of communication. Flip side is, if you do not involve distributed teams, each team might drift away into separate islands. A middle round can be worked out, where each team conducts their local retrospectives and then representatives from each location have a cross location retrospective. Preferably face to face.