One of the most simple and yet most talked-about agile practices is the Daily Stand Up Meeting (a.k.a. Scrum).
On the scrumdevelopment mailing list, Jeff Martin asked the group:
I have searched and can't seem to find what I'm looking for. I'm sure I'm just not using the right terms. Does anyone have a script of an example daily scrum? We are having several issues with our scrum and some team members are wanting to do away with it or change it to a twice a week thing.
That question elicited varied remarks. Marcie Jones suggests that many problems occur from (lack of) meeting facilitation techniques:
1) Don't be late yourself (duh). As a ScrumMaster, this sets a
bad example and sends the message that you don't value the
team's time, or the daily Scrum. If they don't think you value
it, why should they?
2) The meeting needs to start on time. "I'm in the middle of
something, can we wait 5 more minutes" does not respect the
team's time. If you delay routinely for these, again you are
sending the message that this session is not important, when
really it should be one of the most important parts of the day.
3) If #1 and #2 really can't happen, experiment with different
meeting times. Changing the time though will not fix the
underlying attitude issues.
4) Cut off inappropriate discussions. As ScrumMaster you get to
be the facilitator of this session, even if you are just "team
member" the rest of the day. You are allowed to ask people to
take the discussion offline, or hold it until after the general
group is finished. This can be tough at times, but be firm.
5) If the updates are too vague, ask questions. Don't just tell
them "updates need to be at the task level" or that they're
"doing it wrong". If you've been talking with them throughout
the day, ask leading questions during the Scrum, "What happened
with...", "How did you decide to handle...", "Did you ever get
such-and-such from so-and-so". The team will figure out what is
the appropriate level of detail to give over time, partly based
on what questions people ask them, or the opposite problem at
times, when eyes start to glaze over.
6) Ask your team permission to keep trying it daily for say, one
more iteration while you try to fix these problems. Promise
them that if it's not any better after that, you'll switch to
twice a week, and do it. Go from there. If you're having
retrospectives, you can always decide to switch back.
Artem Marchenko suggested that the rules of the Daily Stand Up are so simple that they won't be much help:
Minimal daily scrums are that simple that concrete script won't
probably be of much help. What you are asking for is probably more
about gestures, looks, tone and feeling of trust in that Scrum Master
(and team members) will actually help when help is needed. These
things are difficult to reflect in a script.
Scott Weber suggested a script that looks something like this (by the way, many did not agree with Scott and thought this suggestion was too much on the command-and-control side):
Scrum Master: Scot, what did you accomplish yesterday?
Scot: I finished tasks X and Y, but had a problem with Z. I think I
need Jon's help.
<< presuming Jon's availability is NOT a problem >>
Scrum Master: Scot, what are you planning to do today?
Scot: Get with Jon and complete Z, and start on AA.
[[ cycle through to the next person on the team ]]and later Scott notes:
One of the hoped for artifacts of Scrum is the self organizing team,
meaning the development team members (not all are necessarily
engineers) find their capacity for effective participation and
engagement in the team.
Along the way, several good articles discussing Daily Stand Ups were referenced. Simon Baker gives an overview of Daily Stand Ups (including the chicken and pig joke), Mishkin Bertig tells us about its dysfunctions, and Jason Yip tells us about them in pattern format.
A Daily Stand Up Meeting seems so simple in concept, but is not easy for many teams to adopt. If we were to apply our own Agile principles to Stand Ups (meta-Agile), we should be explicit about the goal of a Stand Up meeting to be able to "test" the success or failure of any particular instance of Stand Up meeting. Unfortunately, the clarity of a goal is lacking in many conversations. In this entire thread, the goals of the meeting were only brought up in passing and never discussed directly.
What are your thoughts on the goals of a Stand Up meeting? Do the implementations above all meet your goals or not?