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

Re: [scrumdevelopment] Deviating from Scrum: The standup meeting

Expand Messages
  • George Dinwiddie
    Peter, ... Have you done a root cause analysis on why the team receives no value from the daily standup? A common situation I ve seen is that the team isn t
    Message 1 of 15 , Mar 2, 2011
    • 0 Attachment
      Peter,

      On 3/2/11 9:05 AM, peterskeide wrote:
      > Hi everyone,
      >
      >
      > During the last couple of years I have been a member of several small
      > teams (3-4 people) that have started out using Scrum or some
      > variation. After a while, I started noticing a trend: The teammembers
      > see little or no value in the daily scrum meeting. Sometimes the team
      > decides to drop it.

      Have you done a root cause analysis on why the team receives no value
      from the daily standup?

      A common situation I've seen is that the "team" isn't a team at all, but
      a group of people working individually on things that happen to be
      lumped together into the same time charge code. Of course, there are
      many other possibilities.

      I wonder about such a small team not being able to afford 5 minutes or
      less per day to synchronize with each other. Why is that?

      [snip]
      > Any thoughts about this? Similar experiences? Anybody know a format
      > for the standup meeting that is a good fit for a small team?

      I'd say a format that is chosen by the team to give them value is a good
      fit.

      - George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • Charles Bradley - Scrum Coach CSM PSM I
      peterskeide, I was wondering if you could share some more context with us about your question. How big is your Scrum team? Is the PO collocated with the dev
      Message 2 of 15 , Mar 2, 2011
      • 0 Attachment
        peterskeide,

        I was wondering if you could share some more context with us about your question.

        How big is your Scrum team? 
        Is the PO collocated with the dev team?
        What % of the PO's time does the PO spend working with the dev team?
        As the ScrumMaster, are you also a developer on the team?
        Does the PO wear more than one hat as well?
        When does your dev team update the sprint backlog and sprint burndown?
         
        -------
        Charles Bradley, CSM, PSM I
        Experienced Scrum Coach
        My blog: http://scrumcrazy.wordpress.com/



        From: peterskeide <peterskeide@...>
        To: scrumdevelopment@yahoogroups.com
        Sent: Wed, March 2, 2011 7:05:38 AM
        Subject: [scrumdevelopment] Deviating from Scrum: The standup meeting

        Hi everyone,


        During the last couple of years I have been a member of several small teams (3-4 people) that have started out using Scrum or some variation. After a while, I started noticing a trend: The teammembers see little or no value in the daily scrum meeting. Sometimes the team decides to drop it.

        I'm currently Scrum Master for a team where we have made significant changes to the format for the standup meeting based on feedback from the retrospectives: we focus solely on impediments (a bit like the Kanban style standups). At present time, I get the feeling that some members of the team see no point in keeping even this part of the standup. This sprint I'm running an experiment where I've relied entierly on the team to self-organize the standup meeting. The result has been almost no standup meetings so far.

        The best argument I have heard so far in favor of dropping the standup is that it can be redundant in a small, colocated team. When you sit around the same table all day, pair program often and generally talk to each other a lot, it's a bit like gilding the lily.

        There are obvious downsides to dropping the standup: the visibility aspect of it lost. Granted, this only matters if people outside the team actually bothers to attend the meeting. Still, if there are no standup meetings, there will be nothing for potentially interested stakeholders to start attending.

        Another problem I've experienced on teams who don't do standups is that important issues will sometimes escape the attention of people who can do anything about them before it is too late, despite colocation. Keeping the daily scrum will perhaps help teams catch some of these issues.

        Standup meetings also have a commitment aspect that will be lost without them. Perhaps this can be offset by a collective feeling of responsibility for getting things done. When almost the entire team will work on a User Story, having each team member commit to get something done in front of the rest of the team doesn't always feel quite natural. A bit like going through the motions, perhaps.

        Any thoughts about this? Similar experiences? Anybody know a format for the standup meeting that is a good fit for a small team?



        ------------------------------------

        To Post a message, send it to:  scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
            http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
            Individual Email | Traditional

        <*> To change settings online go to:
            http://groups.yahoo.com/group/scrumdevelopment/join
            (Yahoo! ID required)

        <*> To change settings via email:
            scrumdevelopment-digest@yahoogroups.com
            scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
            scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
            http://docs.yahoo.com/info/terms/

      • peterskeide
        ... Nice suggestion, I ll put that one in my toolbox. Thanks!
        Message 3 of 15 , Mar 2, 2011
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, Malcolm Anderson <malcolm.b.anderson@...> wrote:
          >
          > I've handled it by documenting those items, that only showed up in the stand
          > up meeting, and having that inventory ready for when the team wants to do
          > away with the standup.
          >
          > Then you can just feel-felt-found your way through the value of the daily
          > standup as reality check, ritual focusing break, and insurance policy
          > against deadline busting moments that sound like "I didn't fix it, I thought
          > you were fixing it"
          >

          Nice suggestion, I'll put that one in my toolbox. Thanks!

          > Malcolm
          > Scrum Coach & Agile Engineer
          >
        • peterskeide
          ... We have talked about it at length at retrospective meetings, and also during each sprint. Basically, people feel they know what every other team member did
          Message 4 of 15 , Mar 2, 2011
          • 0 Attachment
            --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...> wrote:
            >
            > Peter,
            >
            > On 3/2/11 9:05 AM, peterskeide wrote:
            > > Hi everyone,
            > >
            > >
            > > During the last couple of years I have been a member of several small
            > > teams (3-4 people) that have started out using Scrum or some
            > > variation. After a while, I started noticing a trend: The teammembers
            > > see little or no value in the daily scrum meeting. Sometimes the team
            > > decides to drop it.
            >
            > Have you done a root cause analysis on why the team receives no value
            > from the daily standup?
            >

            We have talked about it at length at retrospective meetings, and also during each sprint. Basically, people feel they know what every other team member did yesterday, and what they will do today (as a result of working colocated and also cooperating on many of the stories). Impediments are a different matter, but I do try to ferret those out as soon as possible, rather than having people "save up" for the standup.

            I have suggested to the team that they should lower their barrier for reporting impediments in general. E.g someone not being able to make any progress on a user story for a couple of hours should be raised as an impediment immediately, so that the whole team can pitch in if required. It's hard to make this stick though. People often thrive on the satisfaction of solving problems by themselves, and can be reluctant to ask for help. That said, my current team has made great progress in this area. Practices like pair programming is used at lot more now than when we started out.

            > A common situation I've seen is that the "team" isn't a team at all, but
            > a group of people working individually on things that happen to be
            > lumped together into the same time charge code. Of course, there are
            > many other possibilities.
            >

            I see what you mean. I won't say that we are a collaborating team yet. Cooperating team is more like it (don't quite 'gel' yet'), but I don't think that is quite the problem here. The sprints have a common goal everone is working towards. No "ownership" of backlog issues etc.

            > I wonder about such a small team not being able to afford 5 minutes or
            > less per day to synchronize with each other. Why is that?
            >

            Oh, it is easily afforded. It's just that they don't see the point. 5 minutes x enough number of times of doing something you don't quite see the value of will eventually become a nuisance.

            > [snip]
            > > Any thoughts about this? Similar experiences? Anybody know a format
            > > for the standup meeting that is a good fit for a small team?
            >
            > I'd say a format that is chosen by the team to give them value is a good
            > fit.
            >

            There's no arguing that :-)

            > - George
            >
            > --
            > ----------------------------------------------------------------------
            > * George Dinwiddie * http://blog.gdinwiddie.com
            > Software Development http://www.idiacomputing.com
            > Consultant and Coach http://www.agilemaryland.org
            > ----------------------------------------------------------------------
            >
          • peterskeide
            ... 4, including me. ... More or less (next door). ... He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule
            Message 5 of 15 , Mar 2, 2011
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
              >
              > peterskeide,
              >
              > I was wondering if you could share some more context with us about your
              > question.
              >
              > How big is your Scrum team?

              4, including me.

              > Is the PO collocated with the dev team?

              More or less (next door).

              > What % of the PO's time does the PO spend working with the dev team?

              He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule regular backlog grooming sessions (working with him to get these sessions running smoothly).

              > As the ScrumMaster, are you also a developer on the team?

              Yes. And this can be a bit of a problem. Generally, I would prefer not to mix these two roles. As it is, one of our greates impediments is lack of capacity, and I feel I have to devote some time to development, sometimes more than I'm comfortable with while wearing both hats. The issue has been flagged and people are being hired, but this takes time. As it is, we have had to make the organization face some 'brutal' truths about what we are able to deliver.

              > Does the PO wear more than one hat as well?

              Yes. I'm working with him to help him understand what is required of a PO. As a Scrum Master, getting this role working well is a high priority. He is very motivated, skilled in the domain, and I have hopes :-). I'm also trying to ensure that upper management gives him the mandate he needs to fulfill this role. Changing his other responsibilities is a natural part of this as I see it.

              > When does your dev team update the sprint backlog and sprint burndown?
              >

              Burndown at the end or beginning of each day. Sprint Backlog (story board) is updated continuously as people start and finish stories.

              > -------
              > Charles Bradley, CSM, PSM I
              > Experienced Scrum Coach
              > My blog: http://scrumcrazy.wordpress.com/
              >
              >
            • Adam Sroka
              ... It s not so much that it is redundant as that the information is arriving at the wrong time. It is too late to for me to help you with what you were doing
              Message 6 of 15 , Mar 2, 2011
              • 0 Attachment
                On Wed, Mar 2, 2011 at 6:05 AM, peterskeide <peterskeide@...> wrote:
                >
                >
                >
                > Hi everyone,
                >
                > During the last couple of years I have been a member of several small teams (3-4 people) that have started out using Scrum or some variation. After a while, I started noticing a trend: The teammembers see little or no value in the daily scrum meeting. Sometimes the team decides to drop it.
                >
                > I'm currently Scrum Master for a team where we have made significant changes to the format for the standup meeting based on feedback from the retrospectives: we focus solely on impediments (a bit like the Kanban style standups). At present time, I get the feeling that some members of the team see no point in keeping even this part of the standup. This sprint I'm running an experiment where I've relied entierly on the team to self-organize the standup meeting. The result has been almost no standup meetings so far.
                >
                > The best argument I have heard so far in favor of dropping the standup is that it can be redundant in a small, colocated team. When you sit around the same table all day, pair program often and generally talk to each other a lot, it's a bit like gilding the lily.
                >

                It's not so much that it is redundant as that the information is
                arriving at the wrong time. It is too late to for me to help you with
                what you were doing yesterday, and I am less interested in what you
                are doing now - while I am busy with something else - than I will be
                in what you are doing when I finish.

                > There are obvious downsides to dropping the standup: the visibility aspect of it lost. Granted, this only matters if people outside the team actually bothers to attend the meeting. Still, if there are no standup meetings, there will be nothing for potentially interested stakeholders to start attending.
                >

                I don't think so. What I like to do is open the room up to anyone who
                wants to be a fly on the wall, but if you want to ask questions you
                have to participate in whatever it is we are doing. That way customers
                can show up at whatever time is convenient for them, but their ability
                to interfere and "break the flow" is limited by their
                willingness/desire to directly contribute.

                > Another problem I've experienced on teams who don't do standups is that important issues will sometimes escape the attention of people who can do anything about them before it is too late, despite colocation. Keeping the daily scrum will perhaps help teams catch some of these issues.
                >

                Late is better than never. That's why stand-ups are so important to
                brand new teams. Once you get used to talking throughout the day the
                risk of this diminishes considerably.

                > Standup meetings also have a commitment aspect that will be lost without them. Perhaps this can be offset by a collective feeling of responsibility for getting things done. When almost the entire team will work on a User Story, having each team member commit to get something done in front of the rest of the team doesn't always feel quite natural. A bit like going through the motions, perhaps.
                >

                Work items going for a day or more without discernible progress is
                always a problem when it happens. The stand-up meeting tends to make
                this easy to detect, but if it is already easy to detect then the
                stand-up meeting doesn't add anything.

                > Any thoughts about this? Similar experiences? Anybody know a format for the standup meeting that is a good fit for a small team?
                >

                Some folks suggest switching up the format of the stand-up meeting to
                keep it fresh. Personally, I would say that if the team is not getting
                any value out of it then consider not holding the meeting for a Sprint
                or two to see what happens.
              • Charles Bradley - Scrum Coach CSM PSM I
                peterskeide, I think I understand now more why your team wants to ditch the Daily Scrum. The Scrum Guide says that Scrum is for teams of 5-9 developers. I
                Message 7 of 15 , Mar 2, 2011
                • 0 Attachment

                  peterskeide,

                  I think I understand now more why your team wants to ditch the Daily Scrum.  The Scrum Guide says that Scrum is for teams of 5-9 developers.  I count about 3.5 on your team.  This *may* be an example of where the process overhead of a Daily Scrum is worthwhile for a team of 5-9 devs, but may not be worthwhile for a team of 3.5. 

                  So, before we continue let's realize that we're operating outside of the recommended boundaries for Scrum, which may be some of the source of your pain.  You may also experience other similar pains with other Scrum ceremony/rules for this reason as well.

                  Does your PO attend the Daily Scrum?  I think it's generally a good practice. (Technically the PO would be attending as a Chicken, though, so while they would not be be allowed to talk in the meeting, they would certainly be allowed to follup with dev team members just after the meeting)  If your PO has other duties and is located in a different room, I think they might benefit from the Daily Scrum, and in turn, the team would benefit.

                  Another thing most of my teams do right after the Daily Scrum is analyze the burndown a bit for possible scoping/workload issues.  I generally coach them to use an "ideal (capacity=hrs capacity remaining) line", and we generally don't worry too much about a burndown number (hrs work remaining) that is within 20% of the ideal(capacity) number until the last 3 days of the (2 week)sprint or so.  During the last 3 days, we generally always had a discussion(again, just after the Scrum) like "Do we need to take any action now that will help us have a more successful end of sprint?"  Sometimes people would identify the burndown numbers as an obstacle in the Scrum, sometimes we wouldn't really notice or discuss until after the Scrum.

                  Technically, though, the person who ensures that the Daily Scrum happens is the ScrumMaster.  So, since the SM, "owns the process", the SM can mandate the Daily Scrum regardless of what the team says.  That may not be a fun position to be in, but it's justified IMO.  I'd hope the SM would focus more on improving the Daily Scrum(like you are) than having to mandate it.
                   
                  -------
                  Charles Bradley, CSM, PSM I
                  Experienced Scrum Coach
                  My blog: http://scrumcrazy.wordpress.com/



                  From: peterskeide <peterskeide@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Wed, March 2, 2011 11:59:08 AM
                  Subject: [scrumdevelopment] Re: Deviating from Scrum: The standup meeting


                  --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                  >
                  > peterskeide,
                  >
                  > I was wondering if you could share some more context with us about your
                  > question.
                  >
                  > How big is your Scrum team? 

                  4, including me.

                  > Is the PO collocated with the dev team?

                  More or less (next door).

                  > What % of the PO's time does the PO spend working with the dev team?

                  He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule regular backlog grooming sessions (working with him to get these sessions running smoothly).

                  > As the ScrumMaster, are you also a developer on the team?

                  Yes. And this can be a bit of a problem. Generally, I would prefer not to mix these two roles. As it is, one of our greates impediments is lack of capacity, and I feel I have to devote some time to development, sometimes more than I'm comfortable with while wearing both hats. The issue has been flagged and people are being hired, but this takes time. As it is, we have had to make the organization face some 'brutal' truths about what we are able to deliver.

                  > Does the PO wear more than one hat as well?

                  Yes. I'm working with him to help him understand what is required of a PO. As a Scrum Master, getting this role working well is a high priority. He is very motivated, skilled in the domain, and I have hopes :-). I'm also trying to ensure that upper management gives him the mandate he needs to fulfill this role. Changing his other responsibilities is a natural part of this as I see it.

                  > When does your dev team update the sprint backlog and sprint burndown?
                  >

                  Burndown at the end or beginning of each day. Sprint Backlog (story board) is updated continuously as people start and finish stories.

                  >  -------
                  > Charles Bradley, CSM, PSM I
                  > Experienced Scrum Coach
                  > My blog: http://scrumcrazy.wordpress.com/
                  >
                  >

                • Chuck B
                  ... George/Peter, I don t know about this. What if the team chooses the no standup format? What if they choose to just say what they are working on and
                  Message 8 of 15 , Mar 2, 2011
                  • 0 Attachment
                    > > Any thoughts about this? Similar experiences? Anybody know a format
                    > > for the standup meeting that is a good fit for a small team?

                    > I'd say a format that is chosen by the team to give them value is a good
                    > fit.

                    >   - George

                    George/Peter,

                    I don't know about this.  What if the team chooses the "no standup" format?  What if they choose to just say what they are working on and that's it?  I just don't know about entrusting the team to choose whatever format they want, especially not a team that is well versed in Scrum.  You did say "chosen by the team to give them value "  Who determines whether the format gives them value or not?

                    Some material from the Scrum Guide(bold emphasis from me):
                    "The ScrumMaster ensures that the Team has the meeting. The Team is
                    responsible for conducting the Daily Scrum. The ScrumMaster teaches
                    the Team to keep the Daily Scrum short by enforcing the rules and
                    making sure that people speak briefly. The ScrumMaster also enforces
                    the rule that chickens are not allowed to talk or in anyway interfere
                    with the Daily Scrum.
                    The Daily Scrum is not a status meeting. It is not for anyone but the
                    people transforming the Product Backlog items into an increment (the
                    Team). The Team has committed to a Sprint Goal, and to these
                    Product Backlog items. The Daily Scrum is an inspection of the
                    progress toward that Sprint Goal (the three questions). Follow-on
                    meetings usually occur to make adaptations to the upcoming work in
                    the Sprint. The intent is to optimize the probability that the Team will
                    meet its Goal. This is a key inspect and adapt meeting in the Scrum
                    empirical process. "

                    Note that last sentence.  (Mostly to Peter)I'd be VERY wary of removing the Daily Scrum since it's a "...key inspect and adapt meeting..."


                    -------
                    Charles Bradley, CSM, PSM I
                    Experienced Scrum Coach
                    My blog: http://scrumcrazy.wordpress.com/

                  • Charles Bradley - Scrum Coach CSM PSM I
                    ... should read ... Charles Bradley, CSM, PSM I Experienced Scrum Coach My blog: http://scrumcrazy.wordpress.com/
                    Message 9 of 15 , Mar 2, 2011
                    • 0 Attachment
                      Correction:
                      > especially not a team that is well versed in Scrum
                      should read
                      > especially not a team that is less than well versed in Scrum
                       
                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/


                    • Peter Stevens (cal)
                      Hi Peter, I believe the most fundamental principles of Scrum are Inspect and Adapt and Emergence. So when you have a problem and don t know what the best
                      Message 10 of 15 , Mar 3, 2011
                      • 0 Attachment
                        Hi Peter,

                        I believe the most fundamental principles of Scrum are 'Inspect and Adapt' and Emergence. So when you have a problem and don't know what the best solution is, you can propose alternative, try them out, and then reflect on them in the Retrospective.

                        What is the essential that you need to need to preserve on the daily scrum? Perhaps in your case, it's sufficient to move the daily scrum to the coffee machine and talk about the third question. Another alternative is dropping the Daily Scrum all together. So try it out for a sprint. The look at your results in the retro. Maybe try a different alternative in the next sprint. Maybe go back to doing the Daily Scrum in the third. Then make a more definitive decision.

                        I think by being open to the issues raised by your team that you will gain their respect.

                        Inspect and Adapt - keep true to this principle and you'll do fine!

                        Cheers,

                        Peter (S)

                        On 02.03.11 21:19, Charles Bradley - Scrum Coach CSM PSM I wrote:
                         

                        peterskeide,

                        I think I understand now more why your team wants to ditch the Daily Scrum.  The Scrum Guide says that Scrum is for teams of 5-9 developers.  I count about 3.5 on your team.  This *may* be an example of where the process overhead of a Daily Scrum is worthwhile for a team of 5-9 devs, but may not be worthwhile for a team of 3.5. 

                        So, before we continue let's realize that we're operating outside of the recommended boundaries for Scrum, which may be some of the source of your pain.  You may also experience other similar pains with other Scrum ceremony/rules for this reason as well.

                        Does your PO attend the Daily Scrum?  I think it's generally a good practice. (Technically the PO would be attending as a Chicken, though, so while they would not be be allowed to talk in the meeting, they would certainly be allowed to follup with dev team members just after the meeting)  If your PO has other duties and is located in a different room, I think they might benefit from the Daily Scrum, and in turn, the team would benefit.

                        Another thing most of my teams do right after the Daily Scrum is analyze the burndown a bit for possible scoping/workload issues.  I generally coach them to use an "ideal (capacity=hrs capacity remaining) line", and we generally don't worry too much about a burndown number (hrs work remaining) that is within 20% of the ideal(capacity) number until the last 3 days of the (2 week)sprint or so.  During the last 3 days, we generally always had a discussion(again, just after the Scrum) like "Do we need to take any action now that will help us have a more successful end of sprint?"  Sometimes people would identify the burndown numbers as an obstacle in the Scrum, sometimes we wouldn't really notice or discuss until after the Scrum.

                        Technically, though, the person who ensures that the Daily Scrum happens is the ScrumMaster.  So, since the SM, "owns the process", the SM can mandate the Daily Scrum regardless of what the team says.  That may not be a fun position to be in, but it's justified IMO.  I'd hope the SM would focus more on improving the Daily Scrum(like you are) than having to mandate it.
                         
                        -------
                        Charles Bradley, CSM, PSM I
                        Experienced Scrum Coach
                        My blog: http://scrumcrazy.wordpress.com/



                        From: peterskeide <peterskeide@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Wed, March 2, 2011 11:59:08 AM
                        Subject: [scrumdevelopment] Re: Deviating from Scrum: The standup meeting


                        --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                        >
                        > peterskeide,
                        >
                        > I was wondering if you could share some more context with us about your
                        > question.
                        >
                        > How big is your Scrum team? 

                        4, including me.

                        > Is the PO collocated with the dev team?

                        More or less (next door).

                        > What % of the PO's time does the PO spend working with the dev team?

                        He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule regular backlog grooming sessions (working with him to get these sessions running smoothly).

                        > As the ScrumMaster, are you also a developer on the team?

                        Yes. And this can be a bit of a problem. Generally, I would prefer not to mix these two roles. As it is, one of our greates impediments is lack of capacity, and I feel I have to devote some time to development, sometimes more than I'm comfortable with while wearing both hats. The issue has been flagged and people are being hired, but this takes time. As it is, we have had to make the organization face some 'brutal' truths about what we are able to deliver.

                        > Does the PO wear more than one hat as well?

                        Yes. I'm working with him to help him understand what is required of a PO. As a Scrum Master, getting this role working well is a high priority. He is very motivated, skilled in the domain, and I have hopes :-). I'm also trying to ensure that upper management gives him the mandate he needs to fulfill this role. Changing his other responsibilities is a natural part of this as I see it.

                        > When does your dev team update the sprint backlog and sprint burndown?
                        >

                        Burndown at the end or beginning of each day. Sprint Backlog (story board) is updated continuously as people start and finish stories.

                        >  -------
                        > Charles Bradley, CSM, PSM I
                        > Experienced Scrum Coach
                        > My blog: http://scrumcrazy.wordpress.com/
                        >
                        >



                        -- 
                        Peter Stevens, Partner 
                        DasScrumTeam GmbH 
                        
                        direct: +41 44 586 6450 
                        cell:   +41 79 422 6722
                        skype:  peterstev
                        
                        blog:   http://scrum-breakfast.com
                        
                        My New Email Address: peter.stevens@...
                        Please update your address book. Thanks!
                        
                      • Hariprakash Agrawal
                        I tend to agree with Peter (S) here on Inspect and Adapt . Also, I have faced this scenario and I do consult teams of 3-4 members or usually start with bigger
                        Message 11 of 15 , Mar 3, 2011
                        • 0 Attachment
                          I tend to agree with Peter (S) here on 'Inspect and Adapt'. Also, I have faced this scenario and I do consult teams of 3-4 members or usually start with bigger team size, say, 7 to 10 and than slowly gets to smaller team size depending on the context.

                          In one case, team said exactly what peterskeide wrote in his initial post. Some of the characteristics of this team were:

                          Team never used to skip updating burn-down chart otherwise they may miss the
                          overall picture.
                          Team was updating sprint backlog as and when the story/task was completed.
                          Many times, whole team used to go for lunch together hence it can be considered that they had some kind of work related discussion during lunch itself and a separate meeting was quite redundant.
                          Some of the stories were also taking 3-4 days hence there were days when there was no progress with respect to done definition.

                          As an agile coach, my recommendation to team was that they may skip stand-up meeting on a day but not to skip for 2 consecutive days. This team tried the option of stand-up meetings on alternate day for some time and it worked in that context.


                          Regards,
                          Hariprakash Agrawal (Hari),
                          Managing Director | Agile Coach | http://opcord.com | http://www.linkedin.com/in/hariprakash
                          Software Testing (QTP, Selenium, JMeter, AutoIT, Sahi, NUnit, VB/Java Script, Manual) || Consulting / Trainings (Agile, CMMi, Six Sigma, Project Management, Software Testing
                          )


                          On Thu, Mar 3, 2011 at 2:50 PM, Peter Stevens (cal) <peterstev@...> wrote:
                           

                          Hi Peter,

                          I believe the most fundamental principles of Scrum are 'Inspect and Adapt' and Emergence. So when you have a problem and don't know what the best solution is, you can propose alternative, try them out, and then reflect on them in the Retrospective.

                          What is the essential that you need to need to preserve on the daily scrum? Perhaps in your case, it's sufficient to move the daily scrum to the coffee machine and talk about the third question. Another alternative is dropping the Daily Scrum all together. So try it out for a sprint. The look at your results in the retro. Maybe try a different alternative in the next sprint. Maybe go back to doing the Daily Scrum in the third. Then make a more definitive decision.

                          I think by being open to the issues raised by your team that you will gain their respect.

                          Inspect and Adapt - keep true to this principle and you'll do fine!

                          Cheers,

                          Peter (S)



                          On 02.03.11 21:19, Charles Bradley - Scrum Coach CSM PSM I wrote:
                           

                          peterskeide,

                          I think I understand now more why your team wants to ditch the Daily Scrum.  The Scrum Guide says that Scrum is for teams of 5-9 developers.  I count about 3.5 on your team.  This *may* be an example of where the process overhead of a Daily Scrum is worthwhile for a team of 5-9 devs, but may not be worthwhile for a team of 3.5. 

                          So, before we continue let's realize that we're operating outside of the recommended boundaries for Scrum, which may be some of the source of your pain.  You may also experience other similar pains with other Scrum ceremony/rules for this reason as well.

                          Does your PO attend the Daily Scrum?  I think it's generally a good practice. (Technically the PO would be attending as a Chicken, though, so while they would not be be allowed to talk in the meeting, they would certainly be allowed to follup with dev team members just after the meeting)  If your PO has other duties and is located in a different room, I think they might benefit from the Daily Scrum, and in turn, the team would benefit.

                          Another thing most of my teams do right after the Daily Scrum is analyze the burndown a bit for possible scoping/workload issues.  I generally coach them to use an "ideal (capacity=hrs capacity remaining) line", and we generally don't worry too much about a burndown number (hrs work remaining) that is within 20% of the ideal(capacity) number until the last 3 days of the (2 week)sprint or so.  During the last 3 days, we generally always had a discussion(again, just after the Scrum) like "Do we need to take any action now that will help us have a more successful end of sprint?"  Sometimes people would identify the burndown numbers as an obstacle in the Scrum, sometimes we wouldn't really notice or discuss until after the Scrum.

                          Technically, though, the person who ensures that the Daily Scrum happens is the ScrumMaster.  So, since the SM, "owns the process", the SM can mandate the Daily Scrum regardless of what the team says.  That may not be a fun position to be in, but it's justified IMO.  I'd hope the SM would focus more on improving the Daily Scrum(like you are) than having to mandate it.
                           
                          -------
                          Charles Bradley, CSM, PSM I
                          Experienced Scrum Coach
                          My blog: http://scrumcrazy.wordpress.com/



                          From: peterskeide <peterskeide@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Wed, March 2, 2011 11:59:08 AM
                          Subject: [scrumdevelopment] Re: Deviating from Scrum: The standup meeting


                          --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
                          >
                          > peterskeide,
                          >
                          > I was wondering if you could share some more context with us about your
                          > question.
                          >
                          > How big is your Scrum team? 

                          4, including me.

                          > Is the PO collocated with the dev team?

                          More or less (next door).

                          > What % of the PO's time does the PO spend working with the dev team?

                          He is available to us pretty much when we need it. He attends all the usual meetings, and we schedule regular backlog grooming sessions (working with him to get these sessions running smoothly).

                          > As the ScrumMaster, are you also a developer on the team?

                          Yes. And this can be a bit of a problem. Generally, I would prefer not to mix these two roles. As it is, one of our greates impediments is lack of capacity, and I feel I have to devote some time to development, sometimes more than I'm comfortable with while wearing both hats. The issue has been flagged and people are being hired, but this takes time. As it is, we have had to make the organization face some 'brutal' truths about what we are able to deliver.

                          > Does the PO wear more than one hat as well?

                          Yes. I'm working with him to help him understand what is required of a PO. As a Scrum Master, getting this role working well is a high priority. He is very motivated, skilled in the domain, and I have hopes :-). I'm also trying to ensure that upper management gives him the mandate he needs to fulfill this role. Changing his other responsibilities is a natural part of this as I see it.

                          > When does your dev team update the sprint backlog and sprint burndown?
                          >

                          Burndown at the end or beginning of each day. Sprint Backlog (story board) is updated continuously as people start and finish stories.

                          >  -------
                          > Charles Bradley, CSM, PSM I
                          > Experienced Scrum Coach
                          > My blog: http://scrumcrazy.wordpress.com/
                          >
                          >



                          -- 
                          Peter Stevens, Partner 
                          DasScrumTeam GmbH 
                          
                          direct: +41 44 586 6450 
                          cell:   +41 79 422 6722
                          skype:  peterstev
                          
                          blog:   http://scrum-breakfast.com
                          
                          My New Email Address: peter.stevens@...
                          Please update your address book. Thanks!
                          

                        • peterskeide
                          ... I interpreted the above as the team uses standup meetings, but modified . I agree with you about teams that do not know Scrum well. For my current team, I
                          Message 12 of 15 , Mar 3, 2011
                          • 0 Attachment
                            --- In scrumdevelopment@yahoogroups.com, Chuck B <chuck-lists2@...> wrote:

                            > > I'd say a format that is chosen by the team to give them value is a good
                            > > fit.
                            >
                            > > - George
                            >
                            > George/Peter,
                            >
                            > I don't know about this. What if the team chooses the "no standup" format?
                            > What if they choose to just say what they are working on and that's it? I just
                            > don't know about entrusting the team to choose whatever format they want,
                            > especially not a team that is well versed in Scrum. You did say "chosen by the
                            > team to give them value " Who determines whether the format gives them value or
                            > not?
                            >

                            I interpreted the above as "the team uses standup meetings, but modified". I agree with you about teams that do not know Scrum well. For my current team, I made sure we ran several sprints as close to Scrum as we could manage before opening up for change. The standup was at that point a recurring theme in the retrospective meetings. We have not dropped or modified the other artifacts/ceremonies/roles.


                            > The Daily Scrum is not a status meeting. It is not for anyone but the
                            > people transforming the Product Backlog items into an increment (the
                            > Team). The Team has committed to a Sprint Goal, and to these
                            > Product Backlog items. The Daily Scrum is an inspection of the
                            > progress toward that Sprint Goal (the three questions). Follow-on
                            > meetings usually occur to make adaptations to the upcoming work in
                            > the Sprint. The intent is to optimize the probability that the Team will
                            > meet its Goal. This is a key inspect and adapt meeting in the Scrum
                            > empirical process. "
                            >
                            >
                            > Note that last sentence. (Mostly to Peter)I'd be VERY wary of removing the
                            > Daily Scrum since it's a "...key inspect and adapt meeting..."
                            >
                            >

                            I'm definitely wary of removing it, but I'm also wary of disregarding context. On my previous project I worked for a customer where we as a team agreed to drop the standup meeting after a couple of sprints. We were a small team of 4 (colocated). We delivered a solid product on time and budget to a happy customer and with very little technical debt. We did it, by and large, without standup meetings.

                            >
                            > -------
                            > Charles Bradley, CSM, PSM I
                            > Experienced Scrum Coach
                            > My blog: http://scrumcrazy.wordpress.com/
                            >
                          • peterskeide
                            ... This clicked with me. Yes, I think this is definitely a part of it. ... I encourage stakeholders to come down to where we sit and have a look at how we
                            Message 13 of 15 , Mar 3, 2011
                            • 0 Attachment
                              --- In scrumdevelopment@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
                              >
                              > On Wed, Mar 2, 2011 at 6:05 AM, peterskeide <peterskeide@...> wrote:
                              > >
                              > > The best argument I have heard so far in favor of dropping the standup is that it can be redundant in a small, colocated team. When you sit around the same table all day, pair program often and generally talk to each other a lot, it's a bit like gilding the lily.
                              > >
                              >
                              > It's not so much that it is redundant as that the information is
                              > arriving at the wrong time. It is too late to for me to help you with
                              > what you were doing yesterday, and I am less interested in what you
                              > are doing now - while I am busy with something else - than I will be
                              > in what you are doing when I finish.
                              >

                              This clicked with me. Yes, I think this is definitely a part of it.

                              > > There are obvious downsides to dropping the standup: the visibility aspect of it lost. Granted, this only matters if people outside the team actually bothers to attend the meeting. Still, if there are no standup meetings, there will be nothing for potentially interested stakeholders to start attending.
                              > >
                              >
                              > I don't think so. What I like to do is open the room up to anyone who
                              > wants to be a fly on the wall, but if you want to ask questions you
                              > have to participate in whatever it is we are doing. That way customers
                              > can show up at whatever time is convenient for them, but their ability
                              > to interfere and "break the flow" is limited by their
                              > willingness/desire to directly contribute.
                              >

                              I encourage stakeholders to come down to where we sit and have a look at how we work. That way, they are exposed to our information radiators, and can easily view the progress of the current sprint. These radiators tell the truth about the current situation, because we update them continuously. I also feel that this is a great way of spreading information about Scrum to the organization. I don't mandate a strict "contribute or be silent" regime, but welcome questions. I have a feeling the team likes answering some questions about how they work, as it also gives them opportunities to reflect on what they do. I step in if someone appears at a bad time.


                              >
                              > Some folks suggest switching up the format of the stand-up meeting to
                              > keep it fresh. Personally, I would say that if the team is not getting
                              > any value out of it then consider not holding the meeting for a Sprint
                              > or two to see what happens.
                              >

                              I'm in favor of the inspect and adapt approach too, and I will discuss this option with team in next retrospective. However, if there is some way to keep the standup but in a way that adds value, I'd rather we do that.
                            Your message has been successfully submitted and would be delivered to recipients shortly.