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

Deviating from Scrum: The standup meeting

Expand Messages
  • peterskeide
    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.
    Message 1 of 15 , Mar 2, 2011
    • 0 Attachment
      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?
    • Malcolm Anderson
      Hi Peter I ve run into this phenomena also. I ve handled it by documenting those items, that only showed up in the stand up meeting, and having that inventory
      Message 2 of 15 , Mar 2, 2011
      • 0 Attachment
        Hi Peter

        I've run into this phenomena also.

        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"

        Malcolm
        Scrum Coach & Agile Engineer




        On Wed, Mar 2, 2011 at 8: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.

        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?


      • 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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 14 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 15 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.