The Trouble With Retrospectives

get things changed but authority is not the answer to all problems. Before managers can change anything they need to know what to change and how to change it.

Rather than diagnose problems and suggest solutions managers should ask the people who actually do the work and face the problems everyday. Team members normally know the solutions already. All it requires is the time to ask and the ability to listen. Unfortunately, it seems, too many managers only talk to one another and do not spend enough time listening to those who actually do the work and face the problems.

One way of understanding problems is to try and explain them to another person. Even explaining it to yourself can help and maintaining a journal can help here. You don't need to write in it every day, or record everything that happens. Just taking some time each week, to record major events and explain in words what has been happening will help improve understanding and inform decision making.

There are times when problems and solutions are better discussed in groups rather than on one's own or in one-to-one conversations. Such forums do not need to be retrospectives. It helps if the group meets regularly and if there is a hook to base the discussion around.

One manager used to convene monthly improvement meetings. She would take a specific subject, say code quality, and base a discussion around that. At the end of the meeting, the group would have a collective agreement on what it wanted to achieve and how.

Another group at the same company formed a book study group. The group would meet every second week and work their way through a relevant book. Over time participants increasingly applied ideas from the books to the company. The book acted as a seed to help the group collectively identify problems and solutions. In time the book became less important and the discussion more important.

Back to Retrospectives

Techniques such as these have both direct and indirect benefits. Teams learn directly from these excises and their collective learning leads to change. These exercise also help build an environment where learning is valued, people can talk freely and trust one another. When individuals can talk openly about serious issues, they will feel confident raising issues in public and they will understand when such issues are better kept private. Thus some of the barriers to effective retrospectives are removed.

There is no sure fire way to ensure that recommendations for change are acted on after a retrospective. It gets easier if we have already identified and fixed some problems, and over time we gain confidence in our ability to do it again.

Although it may sound counter-intuitive, one technique is to deliberately limit the scope of the retrospective. Placing issues we cannot address out-of-bounds allows attention to be focused on issues that can be fixed. So we might accept that requirements come in large documents not on cards, or that the Test Manager wants a two-week code freeze before release. When a team is confident with retrospectives and has a track record of improvement these issues can be tackled.

We can also limit the outcome of the retrospective. Trying to change many things at once dilutes our ability to change anything. So rather than try and implement 10 changes, we can focus our attention on the top one or two.

Once you have chosen your thing to change talk about it in the retrospective, discuss what you mean by this change, talk about how things will be different, what obstacles you might encounter.