Loading ...
Sorry, an error occurred while loading the content.
 

Constraining and Redirecting Speech during the Daily Scrum

Expand Messages
  • igoodrich
    In the spirit of starting Scrum by following the practices as closely as possible, I have some questions about the Daily Scrum. Even though the Daily Scrum is
    Message 1 of 3 , Apr 9, 2004
      In the spirit of starting Scrum by following the practices as closely as possible, I have some
      questions about the Daily Scrum.

      Even though the Daily Scrum is clear to me in structure, I'm a little iffy on the subtleties of
      the rules surrounding constraining speech and redirecting it to working meetings. I'm
      thinking here of the rules like Only the status reporter speaks, No discussions of
      problems, etc. What about questions of clarification? What about discussions of problems
      so that they can be understood (not solved) by the team? (*My* common sense tells me to
      allow questions of clarification (from team member to team member), but does this violate
      the rules?) How aggressively should everything be shunted into separate working
      meetings and/or truncated entirely?

      Below is an imagined exchange during an imagined Daily Scrum. I have no experience of
      an actual Daily Scrum, but the exchange should still suffice to set the stage to ask, At what
      point should the ScrumMaster constrain/redirect communication and move the meeting
      forward? I understand that there are fuzzy borders here, and the excericise of (gasp!)
      judgement, but what does *your* common sense tell you? What do you do? What about
      when the ScrumMaster moves the meeting along without understanding what's been said?

      I look forward to hearing what you think and have done.

      Thanks!

      -Ian Goodrich (dialog follows)

      Imagined Daily Scrum Dialog
      ---------------------------

      [A. Standard question 1]
      ScrumMaster:
      And what did our Sam do since the last meeting?

      [B. Standard technical answer]
      Sam (Team Member):
      I squiggled the whirlly wu-ma-bob.

      [C. ScrumMaster asks for clarification]
      ScrumMaster:
      You what'ed the who?

      [D. Initial clarification]
      Sam:
      Well, when the pearly nap hit the smelly and needed an answer, the whirlly wu-ma-bob
      wasn't squiggling. So I squiggled the whirlly wu-ma-bob. See?

      [E. ScrumMaster pretends he understands to keep meeting going]
      ScrumMaster: Got it.

      [F. Team Member asks for more detailed clarification]
      Jim: I didn't know the pearly nap ever hit the smelly.

      [G. Person giving status begins using props]
      Sam (goes to whiteboard, begins drawing sequence diagram):
      If the skew-mommie dies (illustrates by standing on one foot)...

      [H. Clarification worked]
      Jim:
      Oh.

      [I. Team Member questions decision]
      Sarah (Team Member):
      Why didn't you just clip the nah-new-nah-new?

      [J. Just in time or not soon enough or too early altogether?]
      ScrumMaster:
      Let's move this discussion to a working meeting right after the Scrum. Sam, now that
      you've bravely squiggled the whirlly wu-ma-bob, what are you going to do today?
    • William Wake
      ... I think your common sense is probably going to be ok. What I try to avoid is where it goes from point of clarification with the speaker to becoming
      Message 2 of 3 , Apr 10, 2004
        >From: "igoodrich" <igoodrich@...>

        >Even though the Daily Scrum is clear to me in structure, I'm a little iffy
        >on the subtleties of
        >the rules surrounding constraining speech and redirecting it to working
        >meetings. I'm
        >thinking here of the rules like Only the status reporter speaks, No
        >discussions of
        >problems, etc. What about questions of clarification? What about
        >discussions of problems
        >so that they can be understood (not solved) by the team? (*My* common sense
        >tells me to
        >allow questions of clarification (from team member to team member), but
        >does this violate
        >the rules?) How aggressively should everything be shunted into separate
        >working
        >meetings and/or truncated entirely?

        I think your common sense is probably going to be ok. What I try to avoid is
        where it goes from "point of clarification" with the speaker to becoming
        "conversation between multiple members".

        I like doing Scrums as "standups" (stand in a circle), and I tell people
        (but never enforce:) a "one-foot, two-foot rule" - you should be able to say
        your part while you stand on one foot, and the whole meeting should be done
        while everybody's on two feet. (And don't let anybody who tends to be
        long-winded go first.)

        >Below is an imagined exchange during an imagined Daily Scrum. I have no
        >experience of
        >an actual Daily Scrum, but the exchange should still suffice to set the
        >stage to ask, At what
        >point should the ScrumMaster constrain/redirect communication and move the
        >meeting
        >forward? I understand that there are fuzzy borders here, and the
        >excericise of (gasp!)
        >judgement, but what does *your* common sense tell you? What do you do?
        >What about
        >when the ScrumMaster moves the meeting along without understanding what's
        >been said?

        I'll omit a lot of dialog but critique it anyway. This is just my
        perspective, and every team needs to hit its own rhythm.

        The first few times with a team new to Scrums, I'll start the circle by
        reminding everyone that we want to know what they did, what they're going to
        do, and what's in their way. Then I'll just let it flow person to person,
        prodding only if they get stuck.

        >[C. ScrumMaster asks for clarification] ScrumMaster: You what'ed the who?
        If I'd ask a question it would probably be one to shift the domain up -
        "what task is this for?". (If I didn't know what squiggling etc. meant and
        felt like I should know, I'd ask afterwards.) There might be a useful
        intermediate level between the low level they described and "what task". (I
        don't know this domain so it's hard to guess:)

        >[E. ScrumMaster pretends he understands to keep meeting going]
        I wouldn't pretend anything (owned ignorance is a weapon!). If nobody else
        questioned it, I'd get an explanation after the meeting. I think it's fair
        to nudge people toward a description that helps you know what's going on in
        general. But there will still be some description of low-level things you
        don't need the details on.

        >[G. Person giving status begins using props]
        Way more than I want at this point.

        >[I. Team Member questions decision]
        >[J. Just in time or not soon enough or too early altogether?]

        Not soon enough by me.


        I'm happy that the parties realize they have some design issues, too bad it
        wasn't during the day yesterday, but I definitely don't want the team to
        stand there and discuss it. If nothing else, it doesn't sound like the
        ScrumMaster knows enough to contribute, and I suspect one or more others
        don't care, so let's move the discussion to a meeting among those who do
        care.

        One thing I *do* like is a little more than "here's what I did", but a brief
        description of consequences or how it affects others ("I created a report
        class that might simplify the report Frodo is working on", "we got rid of
        empty constructors that were relying on static defaults", "we put a new
        column in but we think the proposed change in xxx will affect it.") I want
        enough that people walk away knowing who they ought to touch base with.

        --
        Bill Wake William.Wake@... www.xp123.com

        _________________________________________________________________
        Watch LIVE baseball games on your computer with MLB.TV, included with MSN
        Premium!
        http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/
      • Ian Goodrich
        William, This is excellent feedback and immensely helpful. Thank-you for responding so thoughtfully. The way you describe your scrums makes me realize
        Message 3 of 3 , Apr 11, 2004
          William,

          This is excellent feedback and immensely helpful. Thank-you for
          responding so thoughtfully.

          The way you describe your scrums makes me realize something about how I
          was imagining the Daily Scrum. Descriptions of the Daily Scrum always
          include something like "Each team member answers three questions." I
          think I always heard this as "Each team member is asked three
          questions," imagining that the ScrumMaster was doing the asking, moving
          from person to person in the proper order, etc. It seems better, and
          more in keeping with the spirit of scrum, to let the meeting flow from
          person to person instead of always coming back to the ScrumMaster. The
          ScrumMaster is not directing the meeting, but hosting it. Besides,
          before long everyone knows the questions and the order of reporting and
          so having the ScrumMaster intrude is just unnecessary, or so it
          suddenly seems to me now. We'll see how it goes!

          There was much else in your reply, but this had that "aha" flavor to it
          that we all know and love.

          Thanks again,

          Ian

          On Apr 10, 2004, at 8:41 AM, William Wake wrote:

          > >From: "igoodrich" <igoodrich@...>
          >
          > >Even though the Daily Scrum is clear to me in structure, I'm a
          > little iffy
          > >on the subtleties of
          > >the rules surrounding constraining speech and redirecting it to
          > working
          > >meetings. I'm
          > >thinking here of the rules like Only the status reporter speaks, No
          > >discussions of
          > >problems, etc.  What about questions of clarification?  What about
          > >discussions of problems
          > >so that they can be understood (not solved) by the team? (*My*
          > common sense
          > >tells me to
          > >allow questions of clarification (from team member to team member),
          > but
          > >does this violate
          > >the rules?)  How aggressively should everything be shunted into
          > separate
          > >working
          > >meetings and/or truncated entirely?
          >
          > I think your common sense is probably going to be ok. What I try to
          > avoid is
          > where it goes from "point of clarification" with the speaker to
          > becoming
          > "conversation between multiple members".
          >
          > I like doing Scrums as "standups" (stand in a circle), and I tell
          > people
          > (but never enforce:) a "one-foot, two-foot rule" - you should be able
          > to say
          > your part while you stand on one foot, and the whole meeting should
          > be done
          > while everybody's on two feet. (And don't let anybody who tends to be
          > long-winded go first.)
          >
          > >Below is an imagined exchange during an imagined Daily Scrum. I have
          > no
          > >experience of
          > >an actual Daily Scrum, but the exchange should still suffice to set
          > the
          > >stage to ask, At what
          > >point should the ScrumMaster constrain/redirect communication and
          > move the
          > >meeting
          > >forward? I understand that there are fuzzy  borders here, and the
          > >excericise of (gasp!)
          > >judgement, but what does *your* common sense tell you?  What do  you
          > do?
          > >What about
          > >when the ScrumMaster moves the meeting along  without understanding
          > what's
          > >been said?
          >
          > I'll omit a lot of dialog but critique it anyway. This is just my
          > perspective, and every team needs to hit its own rhythm.
          >
          > The first few times with a team new to Scrums, I'll start the circle
          > by
          > reminding everyone that we want to know what they did, what they're
          > going to
          > do, and what's in their way. Then I'll just let it flow person to
          > person,
          > prodding only if they get stuck.
          >
          > >[C. ScrumMaster asks for clarification] ScrumMaster: You what'ed the
          > who?
          > If I'd ask a question it would probably be one to shift the domain up
          > -
          > "what task is this for?". (If I didn't know what squiggling etc.
          > meant and
          > felt like I should know, I'd ask afterwards.) There might be a useful
          > intermediate level between the low level they described and "what
          > task". (I
          > don't know this domain so it's hard to guess:)
          >
          > >[E. ScrumMaster pretends he understands to keep meeting going]
          > I wouldn't pretend anything (owned ignorance is a weapon!). If nobody
          > else
          > questioned it, I'd get an explanation after the meeting. I think it's
          > fair
          > to nudge people toward a description that helps you know what's going
          > on in
          > general. But there will still be some description of low-level things
          > you
          > don't need the details on.
          >
          > >[G. Person giving status begins using props]
          > Way more than I want at this point.
          >
          > >[I.  Team Member questions decision]
          > >[J.  Just in time or not soon enough or too early altogether?]
          >
          > Not soon enough by me.
          >
          >
          > I'm happy that the parties realize they have some design issues, too
          > bad it
          > wasn't during the day yesterday, but I definitely don't want the team
          > to
          > stand there and discuss it. If nothing else, it doesn't sound like the
          > ScrumMaster knows enough to contribute, and I suspect one or more
          > others
          > don't care, so let's move the discussion to a meeting among those who
          > do
          > care.
          >
          > One thing I *do* like is a little more than "here's what I did", but
          > a brief
          > description of consequences or how it affects others ("I created a
          > report
          > class that might simplify the report Frodo is working on", "we got
          > rid of
          > empty constructors that were relying on static defaults", "we put a
          > new
          > column in but we think the proposed change in xxx will affect it.") I
          > want
          > enough that people walk away knowing who they ought to touch base
          > with.
          >
          > --
          >    Bill Wake  William.Wake@...  www.xp123.com
          >
          > _________________________________________________________________
          > Watch LIVE baseball games on your computer with MLB.TV, included with
          > MSN
          > Premium!
          > http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/
          > onm00200439ave/direct/01/
          >
          >
          >
          > To Post a message, send it to:   scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          >
          >
          >
          > Yahoo! Groups Links
          >
          > • To visit your group on the web, go to:
          > http://groups.yahoo.com/group/scrumdevelopment/
          >  
          > • To unsubscribe from this group, send an email to:
          > scrumdevelopment-unsubscribe@yahoogroups.com
          >  
          > • Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          > Service.
          >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.