A good retrospective is the core of every Agile process.
(For the records: I am not talking about some fancy kind of meeting but about retrospective process itself)
What is retrospective?
I think that the most common understanding of retrospective comes from Scrum definition.
“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan
for improvements to be enacted during the next Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
This is a three-hour time-boxed meeting for one-month Sprints. For shorter Sprints, the event is
usually shorter. The Scrum Master ensures that the event takes place and that attendants
understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum
Master participates as a peer team member in the meeting from the accountability over the
Scrum process.
The purpose of the Sprint Retrospective is to:
– Inspect how the last Sprint went with regards to people, relationships, process, and
tools;
– Identify and order the major items that went well and potential improvements; and,
– Create a plan for implementing improvements to the way the Scrum Team does its
work.”
Source: http://www.scrumguides.org/
In Scrum Sprint Retrospective is an event which occurs at the end of each iteration (Sprint). The goal is as described above is to inspect our process and adapt it to achieve better results. I think that the core of retrospective itself is this Inspect & Adapt process.
Is retrospective really needed?
The answer for this question is simple: YES! I can not imagine any empirical, adaptive process without this inspect and adapt loop. This is exactly why Scrum and Agile works. If you are trying to use Scrum you could fail in implementing any of the practices described in Scrum Guide but not Sprint Retrospective.
If you struggle with Scrum adoption and have your Sprint Retrospective in place and know how to use it properly, then your process should sooner or later adapt. That’s way we are learning and improving from Sprint to Sprint.
From the other hand – is Sprint Retrospective meeting needed? In few experienced teams which I had a pleasure to work with we managed to get to the point where this inspect and loop for our working process worked without any meetings. Improvement process was just continuous and any problems were discussed just right away when they occurred and were solved as soon as possible. Sometimes it happened during Daily Scrum but sometimes just next to the coffee machine or late in the evening in a pub over the glass of beer.
But for the majority of teams who are not that experienced and effective in an agile process, I would recommend to start from traditional approach and then let it evolve. So…
How to run a good retrospective in Scrum?
First of all – Retrospective “meeting” needs to bring value to all participants. Otherwise people will sooner or later start complaining that this is just another meeting which consumes their precious time that they could spend coding.
Besides of proper meeting format (for which you can easily find some clues in the web) I would like to share with you few good practical advises:
- Invite all the people who have an impact on your process. I found it crucial – regardless of what Scrum gurus wrote in the Scrum Guide, Sprint Retrospective does not have to be only for the Scrum Team. If there are some problems which the team can not solve on its own, or those problems depend on others – you should invite those people (even just for a 5 minute discussion of the problem). If it is not possible to invite those people during the retrospective, set up a meeting as soon as possible.
- Make retrospective optional but inform people that they might be asked to join it if needed. Do not force your team to take a part in retrospective. If you are a Scrum Master you need at least one more team member to start retrospective. Then if you start talking about problems which involve others just – ask them to join the discussion for a while.
- Focus on the value added. If you want more people to join retrospective you have to prove that this event brings value to all of them. First of all during retrospective you can not just talk about problems, you need to find a solution and create an action plan for implementing it. Make all your action points visible to the entire organization and share information about the progress in implementation.
- Start with some kind of icebreaker. Ask a simple question which every participant will answer. It could be something like: “From 1 to 10 how would you rate the last iteration and what should happen to make it 10?”. It might sound silly for you but if people will have an opportunity to say something at the beginning (and hear their own voice) they will have more courage to join the real discussion later.
- Visualize. For some of you, it might be obvious but I have seen many teams which just discuss problems for one and half hour without any solution proposals or notes. When you write things down on the whiteboard or flip-chart and put all problems together it is easier to choose what is really important and to find connections between things.
- Ask others to lead retrospective. It might be difficult to be both facilitator and participant. Ask other team members to lead retrospective from time to time. Teach them what the goal is and what good practices have you been using. It is also good to invite someone from outside the team to lead retrospective from time to time.
Is there any alternative?
For teams that are new to Agile and/or Scrum I would recommend to start with Retrospective in Scrum format.
What I have noticed when working with more mature teams is that sometimes the process of retrospective goes beyond the meeting itself and team members use every opportunity to inspect and adapt their process. Waiting for the meeting to change or improve something could be a waste of time. But it works only if you as a team know how to perform good retrospective first.
The sense of Agile (and Lean too) is to implement this continuous improvement process. It could be iterative but in my opinion it is better to aim for something that is way more continuous than inspecting and adapting only once per iteration.
