A key artifact in all agile methods, and hence in Scrum, is the retrospective.
Some agilists even go to such lengths as to say “start with retrospectives alone, the team will figure out the rest of the process themselves”.
What are retrospectives then, and are they carried out?
The need for retrospectives can be derived directly from the Agile Manifesto, which states
“Individuals and interactions over processes and tools”.
The 12 principles behind the manifesto literally say:
“At regular intervals, the team reflects on how
to become more effective, then tunes and adjust
its behavior accordingly.”
What this means is that in agile methods the team is in control of the process, not vice versa. If the team thinks it can be more effective by making a change to the process, then it should by any means do so.
This is obviously a very substantial difference to heavyweight processes: Here, the development process itself is beyond question. The team can only optimize its implementation.
Retrospectives focus on improving the team as a whole. This is in contrast to improving the productivity of individual team members. In fact, optimum team performance always goes with non-optimal productivity of individual team members. Focussing on individuals can therefore be counter-productive. E.g., spending time for communication will negatively impact productivity of individual team members (as the can’t do any work while communicating), but increase productivity of the team. Making individuals more effective by telling them not to communicate anymore, however, will cause team productivity to plummet, and is therefore not a good idea.
So, how and when should you have a retrospective?
Well, one the one hand, a certain amount of time should have been passed since the last one (because there will be nothing to talk about, if time is too short). One the other hand, it shouldn’t be all-too long either, otherwise commemoration of events since the last retrospective may already start to fade.
Agile retrospectives should be started immediately after project kick-off. They are not “post mortem” (as it is often the case in traditional models), but focus on improving the current project.
Of course, you can still have a post mortem retrospective if you want to. It just shouldn’t be the only kind of retrospective you do.
Fortunately, the easiest solution has turned out to work just fine: Just do retrospectives at the end of each iteration!
Now that the date is set, it is time to come up with an agenda. As it’s unnecessary to reinvent the wheel, I’d like to refer to the 5-point-agenda from the book “Agile Retrospectives: Making Good Teams Great!” by Esther Derby and Diana Larsen.
It’s widely used throughout the industry, and also proved to work for us.
- Set the stage:
During this first phase, the last iteration’s sprint goal and the agenda for today are read out. If necessary, further agreements on the rules of this retrospective can be made (eg, no cell phones / laptops, no destructive criticism, etc.). This is to maximize participation of all team members. - Gather data:
Here, as much information as possible on the latest iteration is being collected (whether objective or subjective). To achieve this, it is important that each person conributes his or her point-of-view. If done right, it will result in a good overview of events during the last sprint. This serves as data source for the rest of the retrospective. - Generate insights:
The overview is now used for drawing conclusions. There are a number of techniques to support this. I will write an introduction on some of them in part 2 of this article. The result of this phase will be a list of suggestions on how to improve. - Decide what to do:
This list is now being prioritized. Then, the team decides on how many of those suggestions it can implement during the following sprint. If possible, these tasks can be assigned to persons. He or she is then responsible for reporting on this subject in the future. - Close the retrospective:
The retrospective’s results are summarized briefly. This could e.g. also be a to-do-list for all team members. Next, the facilitator thanks everyone for the effort put in this retrospective. Last, you can do a short “retrospective of the retrospective”. This enables the facilitator to improve also.
As you can see from these 5 steps, success of a retrospective depends greatly on the data gathered in steps 2 and 3. However, there exist a number of techniques which support the team in doing just that.
Therfore, I will introduce some of them in part 2 of this article…
BFI
Loading ...