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?
Tell me more
×
Programmers Stack Exchange is a question and answer site for
professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
|
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. |
|||
|
