Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
News
What Makes a Good Stand Up Meeting?
Posted by Amr Elssamadisy on May 20, 2008 04:53 PM
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?
RelatedVendorContent
Give-away eBook – Confessions of an IT Manager
Ebook: Scaling Agile with C/ALM
The Agile Business Analyst: Skills and Techniques needed for Agile
Related Sponsor
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
It's a discipline
by
Deborah Hartmann
Posted
May 20, 2008 7:26 PM
Crucial 15 minutes
by
Vikas Hazrati
Posted
May 20, 2008 11:36 PM
Tests....
by
Amr Elssamadisy
Posted
May 21, 2008 12:11 AM
Re: Tests....
by
Vikas Hazrati
Posted
May 21, 2008 11:36 AM
No control and command
by
chris barrow
Posted
May 22, 2008 12:18 PM
Actual Stand-up Practice
by
Allan Tan
Posted
Jul 4, 2008 8:52 AM
-
Sometimes, what's good about a Standup meeting is just that it is daily. It's a safety net. The summary for a week of standup meetings might go like this: Monday: normal Tuesday: normal Wednesday: normal (this is getting boring) Thursday: OH MY GOSH! THE ROOF IS FALLING! THE CODEBASE IS FULL OF ALIEN LIFEFORMS! The team decided what steps to take, and discussed with the product owner which story they could remove from the iteration to compensate. Friday: normal. It's the fact that there is a daily check in that let Thursday's problem be fixed on Thursday, so the team could go back to normal on Friday. If the standup were only on M-W-F and Friday was the sprint's end, this could have derailed a whole sprint. Let's admit it: on a team with no crises, few interruptions, stable requirements (um, do you know many teams like that?) the standup turns into a wax-on/wax-off** exercise. The question is: what risk does a day's (or a week's) delay and confusion carry for this team? How important is is that they keep their promises? (Or, perhaps, why is an "all normal" standup taking more than 7 minutes?) ** reference from The Karate Kid film.
-
Standups are those crucial 15 minutes or less which help you get a quick health check of how the team is progressing. Do it in a wrong way and you would get less than half the benefit that was expected out of it. I tried to summarize list of 15 points for those crucial 15 minutes here. Standup Commitments
-
Maybe it's the developer in me, or maybe it's that I just don't trust lists of things to do because my context is always unique (just like everybody else). So - instead of telling my why they are important, or what I have to do to get them right, I'd rather know what I should expect from a StandUp.
As far as I understand StandUps they are meant to do the following:
1) Provide visibility - both pigs and chickens can see things inching along.
2) Provide visibility - the (self organizing) team members are informed of roadblocks so they can remove them
and
3) Provide visibility - the team can know what to expect for tomorrow.
If some other thing meets that criterion then I'm fine with it. The scrums I participate in usually pass those tests. Are there more tests that need to be passed for a good scrum?
(by the way, I've also been part of teams that had such great communication that these meetings were dropped without any negative effects. Small teams of 3-4 in one room talking all day. We passed all three tests without the need for the meeting.) -
Small teams of 3-4 in one room talking all day. We passed all three tests without the need for the meeting.
This is very interesting. Sometimes I tend to feel the same that when we are working in smaller teams (2-4) people then we might not need to do the "official" standup. The communication throughout the day takes care of it. That being said I have to try skipping the standup in my small team and see the results ;) -
Three great things to remember for a great stand up:
- Keep it short and sweet - 5 minutes tops.
- Keep it daily.
- Don't discuss list of tasks (that's what a storyboard is for). Discuss any obstacles keeping team members from completing known tasks.
-
I've posted actual practice that we do during our stand-up meetings. Here's some detail about it - Finding Value in Stand-up Meetings
6 comments
Watch Thread Reply