I've seen it done as a free-for-all where the scrum master just asks everyone to throw out comments. Or a time-boxed session where "anonymous" comments are posted on the walls bucketed by category. My current team is constrained by being spread out, so it has be done online/over the phone. What is everyone's best experience with soliciting constructive feedback? And how do you follow through on action items for improvement?
closed as too broad by gnat, GlenH7, MichaelT, Tulains Córdova, mattnz Jul 1 '14 at 0:34
There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.
Generally about the retrospective, I highly recommend this book : http://pragprog.com/book/dlret/agile-retrospectives
It is a short and very practical book. It explains all sorts of games, exercise and techniques to gather feedback in the different context your retrospective might be, the kind of team you have, and the current situation of your project. It helps a lot keeping a good dynamic in this kind of meeting, balancing the positive and negative feedback and analyzing properly all that info you have gathered.
I would also recommend The back of the napkin.
More specifically about your question, we dont know much about your environment, but keeping the chickens (authority) out of the retrospective can remove the 'fear' of sharing.
Another thing that has proven to work is to start the meeting with a simple 'check-in question'. Everyone express his feeling about the iteration in 1/2 word, no more, no question asks (yet). That breaks the ice and get everyone started on sharing/talking.
If people are not comfortable sharing in front of everyone, maybe make pairs of people sharing to eachother, and then everyone reports their findings/ideas?
A good start is to make note of issues that arise during the daily stand-up meetings. Also useful is to build a time-line of Sprint just completed, asking team members to bring up events and issues that occurred through the time-line - things that went right as well as things that went wrong.
Once items have been raised, it's up to the Team to figure out what they want to address and how they want to address it.
It's also important to understand that Sprint retrospectives aren't about "feedback". What the are about is implemented "continuous improvement" through the process of inspect and adapt. How does the Team make the things that worked well work even better in the future, and how do they fix the things that didn't work well?
The Scrum Master's role is to ensure that the Retrospective is held, and to coach the Team and keep them focused on the purpose of the Retrospective. Follow-through is really the responsibility of the Team, although it often helps to review the effects of prior action items in future retrospectives.
I have been part of Retrospectives where people were geographically located in different places. In such cases Retrospectives were conducted over video conference. We used an online tool (ideaboardz) to collect the retro points and action items. Rest of the activity used to be as it is. The usual stuff.
As for the honesty and participation is concerned, @Stephane's answer covers a good point about checkin question. The facilitator asks questions like:
On getting the numbers, the facilitator gets a good idea about the mix of people in the room. Based on the numbers you can choose to have an open retrospective or an anonymous one. Thats where online tools like mentioned above helps.