RE: [scrumdevelopment] Techncial Topics During Retrospectives
- There is a yahoo group specifically for Retrospectives that Esther Derby moderates. You may get some more information there.To learn more about the retrospectives group, visit
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Jim Schiel
Sent: Monday, June 16, 2008 11:28 PM
Subject: Re: [scrumdevelopment] Techncial Topics During Retrospectives
I'll add to the previous thoughts that, as soon as the team decides that the technical approach isn't serving their purposes, they'll recommend another change. Go with it. Learn.On Mon, Jun 16, 2008 at 2:45 PM, Peter Stevens <peterstev@gmail. com> wrote:
I would second Tobias' thoughts and add 'variety is the spice of life'. Any format gets boring after two or three repetitions, so it's important to try out new things. And as Tobias, if they come from the team, so much the better!
Tobias Mayer schrieb:
I believe that a good retrospective needs a strong 'by the team, for the team' flavor, so the fact you have team members who are wanting to drive the format to suit specific needs is great. As a Scrum Master I would recommend you timebox the meeting to something less than 4 hours and ensure the agenda gets covered in that time. Keep it moving.
I am not sure you have to continue with your original three questions, as you may find that the same discussion occurs with these new three questions. Try it and see.
Bottom line. You are very lucky to be working on a team that is taking the initiative to improve in this way. Run with it!
--- On Mon, 6/16/08, myoungtai <myoungtai@yahoo. com> wrote:
From: myoungtai <myoungtai@yahoo. com>
Subject: [scrumdevelopment] Techncial Topics During Retrospectives
To: scrumdevelopment@ yahoogroups. com
Date: Monday, June 16, 2008, 5:45 AM
I am a scrummaster and have been running sprints for a little over a
year now. We have been pretty much running scrum out of the box with
a few tweaks and our own interpretations, and so during our
retrospectives we have used the standard three questions (What worked
well, what needs improvement and what specific steps can we try to
improve). We have two teams of ~5-7 people and hold our
retrospectives together, which typically takes about 2 hours. Last
week, one of the developers on our team proposed asking three
different questions in order to focus more on the technical side of
things than on the group dynamics side. He would like to go through
each story pulled into the sprint and ask
1. What was the problem?
2. How did you figure out what the problem was?
3. How did you solve it and what did you learn from it?
I see the value for the developers to have a forum for technical
interchange, and want to support the idea that scrum teams are
self-directed. I am concerned about the additional meeting time
required to ask/answer these questions in addition to the standard
three questions (our dry-run showed they take ~1.5 hr each to get
through). During the technical discussion, there were items that
probably would have come out if we focused more on development
practices, but it had a very distinct flavor from our previous
retrospectives. I got very few new insights from the discussion since
acting as scrummaster for both teams kept me updated on their progress
daily through standups.
My questions for this group are - has anyone considered or tried the
more technically focused retrospective, and what do you think about
-- Peter Stevens, CSM http://scrum- breakfast. blogspot. com http://fingerspell. sierra-charlie. com tel: +41 44 586 6450
CST, Danube Technologies
Look for Danube at Agile2008 - Toronto | August 4 though 8 - Click, Get Involved, Win Stuff! - www.danube.com/ agile08
This message and any included attachments are from Siemens Medical Solutions
and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information. Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful. If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to Central.SecurityOffice@...