InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

What Makes a Good Stand Up Meeting?

Posted by Amr Elssamadisy on May 20, 2008

Sections
Process & Practices
Topics
Agile Techniques ,
Agile
Tags
Scrum ,
Self-organizing Team ,
Adoption

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? 

It's a discipline by Deborah Hartmann Posted
Crucial 15 minutes by Vikas Hazrati Posted
Tests.... by Amr Elssamadisy Posted
Re: Tests.... by Vikas Hazrati Posted
No control and command by chris barrow Posted
Actual Stand-up Practice by Allan Tan Posted
  1. Back to top

    It's a discipline

    by Deborah Hartmann

    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.

  2. Back to top

    Crucial 15 minutes

    by Vikas Hazrati

    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

  3. Back to top

    Tests....

    by Amr Elssamadisy

    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.)

  4. Back to top

    Re: Tests....

    by Vikas Hazrati


    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 ;)

  5. Back to top

    No control and command

    by chris barrow

    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.

  6. Back to top

    Actual Stand-up Practice

    by Allan Tan

    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

Educational Content

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.