Mark Needham

Thoughts on Software Development

Retrospectives: Getting overly focused on actions

with 2 comments

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.

Be Sociable, Share!

Written by Mark Needham

September 24th, 2011 at 6:56 am

Posted in Agile

Tagged with

  • Is there a reason why you would not have a focused retrospective to pick one problem and solve it, maybe even with a focused group, if all are not interested.

    A problem statement could be  “To make our build times faster”  and the focused group can be Devs and QAs , given UXers and BAs might not be that interested when you dive deeper.

    I would suggest every week pick one such burning problem deep dive for 30 mins and come up with actions from a focused group (Kaizen ? )

  • Actually we did do a focused retrospective one week but then people were unhappy that they didn’t have the chance to talk about general things which weren’t covered by the problem statement!

    We did that for an hour but perhaps a 30 minute time slot like you suggest would work better