Retrospectives: Some thoughts
I've worked on two different teams this year which had quite different approaches to retrospectives.
In the first team we had a retrospective at the beginning of every iteration i.e. once every two weeks and in the second team we tried out the idea of having a rolling retrospective i.e. we put up potential retrospective items on the wall and when there were enough of those we discussed them in the standup.
The problem we had with the first approach was that we often had the same types of discussions in each retrospective and the same types of issues were raised each week so that it seemed almost pointless to even have it in the first place.
Several people ended up disliking the idea of even doing a retrospective in the first place because of this.
We came up with the idea of having a vote at the beginning of the iteration to decide whether or not we should have one with the idea being that if it didn't seem necessary then we could skip it for one week but would definitely then have the next one.
I think this worked reasonably well although it's slightly different to the approach taken by Rolf Knutsen which he discussed at XP2010 in his session on 'Feedback and Retrospectives in Agile Projects'.
Rolf suggested that we should have a retrospective at a given time interval and just cut it short if we don't have anything else to discuss.
I think I prefer Rolf's suggestion as it's too easy to come to the conclusion that we don't need a retrospective especially if we think that they're a waste of time.
I thought the rolling retrospective approach that we took on the second project would work much better as we could just address any problems as soon as they came up but it hasn't worked quite that way from my experience.
Several issues which would normally be addressed in a retrospective seemed to go by unchecked and without being resolved.
Having a retrospective is a very useful way to put people in a reflective mindset where they look for things that aren't being done well or that could be done differently whereas during the day we might not do that.
I hadn't appreciated this benefit of a retrospective session and had felt that problems were often being saved up for a retrospective even if they could have been addressed earlier.
Fabio previously wrote about the idea of the future retrospective box to ensure that we don't forget anything that happened early on in an iteration when we come to a retrospective but that still doesn't address the problem of only addressing problems in the retrospective!
It seems like a combination of having a pre scheduled retrospective with problem solving on a day to day basis is what we need so I'd be interested to know how others have addressed this.
Hi,
IMO retros should never be skipped either. It is very easy to feel that they do not bring any value but then I would start wondering whether the retrospectives are facilitated properly. Good ideas can be found in the Agile Retrospectives book (http://pragprog.com/titles/dlret/agile-retrospectives) or with the help of Dr. Google.
Bring in a facilitator from outside, someone outside the team. Retrospectives are the most important part of Scrum, it is the only place where you can inspect and adapt. Skip it, and you'll be doomed to stagnation (or at least you will have hard time of improving the ways you work)
Jussi Mononen
10 Jun 10 at 11:00 am
[...] This post was mentioned on Twitter by Arnon Rotem-Gal-Oz, Bruce Onder. Bruce Onder said: Mark Needham: Retrospectives: Some thoughts http://ff.im/-lNP6V [...]
Tweets that mention Retrospectives: Some thoughts at Mark Needham -- Topsy.com
10 Jun 10 at 2:36 pm
Really Nice ,Needham! Here at Bluesoft in Brazil we have weekly retrospectives at the very end of each sprint, and we also have a space in our kanban for things do improve (or not so nice events), things that went well, and ideas. We use postits for each item.
We lived a moment in the past like you described when the team were demotivated to have retrospectives meetings because the subjects were always the same, but then after reading the Diana's Book from the pragmatic programmers, we started to use some techniques that really helped us out.
Things like:
- Taking the bugs and make a root cause analysis.
- Taking the last potencial problems and apply the 5 whys (lean).
- The 5 hats of thinking technique
- The brainstorming and filtering from the Art of Agile Book
André Faria Gomes
10 Jun 10 at 4:49 pm
@Andre – ah cool I haven't read the Prag book on Retrospectives, I think that's gotta be one for me to look at now!
Have you read the Kerth one by the way? Heard that one's meant to be good although I haven't read it either.
I like the ideas for 5 why's/root cause analysis – that sounds like a cool way to make a retro a bit less boring.
Somehow never thought of that – thanks for the tips!
Mark Needham
10 Jun 10 at 4:53 pm
[...] example I wrote a post about a month ago outlining some of the problems that we'd been having with retrospec… on some of the projects that I've been working on and at one stage towards the beginning of the [...]
Writing off a badly executed practice at Mark Needham
17 Jul 10 at 5:55 pm