Ever since I started working in software, all teams except for one had a weekly or biweekly ritual of an agile retrospective session (which I will be calling “retro” below).
In principle, retros are supposed to let teams improve how they work by reflecting on the last sprint.
In practice, I don’t think I ever experienced any noticeable improvement that would stick for a long time. It makes me question whether retros are worth the time in most teams.
I think there are 2 main reasons for that:
- Many teams, especially bigger ones, struggle to find solutions that everybody agrees on.
- For many problems, the causes can not be realistically changed, because they are outside of the team’s authority.
The first problem – lack of agreement – is a hard social problem, but at least is amenable to better ways of having meetings. I’ve seen some initiatives of teams trying to improve the way they hold meetings and reach agreements, but usually, not everyone agreed to conclusions, and these things tend to not work unless they get buy-in from everyone. Someone some changes are implemented, but after a few weeks, things revert to the old ways.
The second problem – that the causes of team problems are effects of company-wide mandates or team lead’s opinion. This is an even harder problem because I don’t think there is a way out of it from the team’s perspective.
I think that the worst part of that is that team is supposed to try to improve with retros against these odds.
How are your retros?
A simple test can be done by answering 2 questions:
- Can you track any changes to a retro session?
- When you look at actual changes of how work in the team gets done, did they happen by retro (and retro alone)?
In my experience, when any meaningful changes in how team works happen, they come from the team lead or upper management. If you have counter-examples, please do write to me and tell me what was the change and how did it happen.