Agile retrospectives are a key element of Scrum projects: they are _in theory_ the basis of the “develop and inspect” motto. I say in theory because I have yet to moderate a retrospective that was actually beneficial to the team. In short, it’s either “everything went well” or “………………………..”. I am speaking here again in the case of distributed teams which is what I have the most experience with as far as Scrum is concerned.
What are the challenges?
1. It’s hard to get the team to speak up
2. It loses interest after a few sessions (”that retrospective again…”)
3. Get the team to understand the value of these retrospectives
As mentioned earlier, generating informal communication in distributed teams is a tricky one. When local teams get to go for lunch, have a coffee break and the lot, it gets all of sudden a lot easier to speak-up during retrospectives. The case for distributed teams is not so obvious.
Are there any solutions?
I guess there are at least 2 ways to solve the above challenges: try to generate informal communication, or be creative in the way the retrospective is lead:
1. Explore new ways of leading the retrospective - do it anonymously, do it via stand-ups (video conferencing), ice breakers at the beginning of the session. The goal is to set an environment that makes it easy for everyone to generate a discussion.
2. Find new agendas for every sessions - be it teamwork, code quality, communication, processes etc. I find the “what went well”, what went wrong” questions to be very vague and not prone to engage discussions. Being more specific gives direction!
3. Make it clear what the goal of the session is - “in this session we will reflect on how we can increase the quality of our product”
4. Follow up on actions once the session is over - Usually the session generates a list of actions the team needs to follow in order to solve the identified issues. Everybody in the team needs to keep them in mind on a daily basis!
As a Scrum Master I need to spend some more time on this part of the Sprint: plan it better together with the team, get value from it to increase developer and customer satisfaction.
Interesting links on Agile Retrospectives:
http://blog.viocity.com/blog/_archives/2008/3/6/3563380.html
http://www.youtube.com/watch?v=qqtPZYigfNI (Google TechTalk)
Nathan - thanks for the mention.
I’m trying to set aside retrospective days where there are series of meetings throughout the day where various aspects of retrospective are attended to - and delegating preparation to various members of the team - rather than just an hour or two.
I’ve got an idea for you that is great for stimulating any retrospective - and particularly for distributed teams - peer review league table.
It needs to be done with sensitivity but the point is to ensure you have good peer review going on in the first place then get someone to select 3 good reviews and 3 bad reviews. Open these for debate in the retrospective and get the team to vote for the champion and wooden spoon reviews. Years ago I had a guy who copied and pasted the same piece of code 32 times with one variable value changed in each - from there on it was known as his 32 bit code - and he never did it again. Occasionally this creates some friction and raises strong opinions - so long as no blood is drawn its quite healthy over all :)
[...] Interesting post from Nathan Jamin, regarding Retrospectives in Distributed Scrum Teams [...]