A retrospective is a team meeting conducted at the end of each iteration (sprint) in which the team talks about how to improve how they work. I believe that the effectiveness of an agile team strongly correlates with their ability to engage in productive retrospective discussion.
The topics in retrospectives I’ve been involved with have been concerned to ask and answer the questions, What worked?, What didn’t work?, What can we do better? One thing easily overlooked is to examine how well the retrospective meeting itself is working. If it becomes rote, it may become less effective. But why is it so important?
An agile team is supposed to be self-managing. To do that it needs to observe itself! People are not usually very good at self-observation, and neither are groups. The goal of continuous improvement requires taking stock of where we are, as a team. It’s not obvious how to go about this.
I must interject a point I learned from Alistair Cockburn in his book, Agile Software Development. Comparing agile approaches to the Capability Maturity Model, Cockburn notes that in CMMI optimization of the ‘process’ does not take place until the highest level – five- is reached. That’s because in level four the project keeps metrics about the process and then in level five uses the metrics to feed back and improve. Agile teams don’t need to gather metrics before they begin optimizing. Why? Because agile teams make use of the subjective judgments of members. Collectively, a team can agree on ways to improve without needing objective measurements.
How team members are feeling is important. In their book, Agile Retrospectives, Esther Derby and Diana Larsen give many exercises useful to elicit feelings, as well as ideas about how things are going. “Coming into this retrospective, if you were a car, what kind of car would you be?” is one of their questions. The answers will give a clue about how people are feeling and will enliven the talk. One of the goals of an agile coach or scrum master is to help foster a safe space where people are free to express contrary opinions without fear. By getting issues into the open in discussion, things that everyone knows are problems can be brought out and addressed.
An agile team takes responsibility for the outcome of its projects. They can do this because they are empowered to make decisions about many aspects of development. This way of working together asks the members to engage in a high level of social cooperation. To work well and to improve continuously, the team needs to be able to take a frank look at themselves. Only if they can gain insights will they be able to put these into play. That is why I say that without effective retrospective meetings, a team can’t be effectively agile.
Don’t give short shrift to your retrospective meeting!