I’ve attended a lot of different retrospectives over the last few years and one thing that seems to happen quite frequently is that a problem will be raised and there will become a massive urgency to find an action to match with that problem.

As a result of this we don’t tend to go very deeply into working out why that problem happened in the first place and how we can stop it happening in the first place.

Any discussion tends to be quite shallow and doesn’t delve very far beyond the surface of the problem.

I’ve noticed that this tends to happen more when there are a lot of people in the retrospective and there’s a desire not to 'waste' everyone’s time which is understandable to some extent.

We recently had an iteration where there were a lot of stories going back and forth between the developers and testers which was leading to a lot of context switching for some developers.

Since it had felt very disruptive we tried to find some way of deciding when we should or shouldn’t context switch from the current story to fix bugs on earlier stories.

In hindsight it would have been more interesting to look at why that problem existed in the first place rather than directly addressing the problem.

In this case, as my colleague Chris pointed out, it might make more sense for a developer (pair) to go and work with a tester on the story until it was ready to be signed off rather than switching back and forth.

I’ve read about other retrospective formats such as the 'five whys' which might help a team to dig deeper into the problems they’re facing but I’m curious whether it’d make sense to follow such a format with over 30 people attending.

We’d need to pick a sufficiently general problem to analyse so that everyone remained engaged.

I’d be curious whether anyone else has made a similar observation and how they made their retrospectives more effective.