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

Scrummaster NOT part of the Team?

Expand Messages
  • Stefan Svensson
    We are currently in the process of implementing Scrum in the company where I work! There has been a lot of discussions about roles and a specific issue that
    Message 1 of 23 , Apr 23, 2007
    • 0 Attachment
      We are currently in the process of implementing Scrum in the company where  I work!

      There has been a lot of discussions about roles and a specific issue that has been raised recently is about the Scrummaster.

      Question:
      Is there any situation / project type / circumstances where it might be NEGATIVE for the Scrummaster to be part of the team?

      Comments?
    • Emiliano Heyns
      ... where I work! ... has been raised recently is about the Scrummaster. ... NEGATIVE for the Scrummaster to be part of the team? Yes -- ours. I am currently
      Message 2 of 23 , Apr 23, 2007
      • 0 Attachment
        On 4/23/07, Stefan Svensson <per_stefan_svensson@...> wrote:
        >
        > We are currently in the process of implementing Scrum in the company where  I work!
        >
        > There has been a lot of discussions about roles and a specific issue that has been raised recently is about the Scrummaster.
        >
        > Question:
        > Is there any situation / project type / circumstances where it might be NEGATIVE for the Scrummaster to be part of the team?

        Yes -- ours. I am currently both SM and TM, and one of the problems is one of authority. As TM, I am allowed an opinion on how the project should be handled, who might be best to handle a task from the board, etc. As a scrum master, I don't think I'm supposed to influence that. With both roles combined, people look to me for project leadership, assigning tasks, etc.

        Emile
      • David H.
        ... My answer has to be no. At least I have never experienced that case. When the ScrumMaster is part of the team, because he or she has to wear two hats
        Message 3 of 23 , Apr 23, 2007
        • 0 Attachment
          >
          >
          > We are currently in the process of implementing Scrum in the company where I work!
          >
          > There has been a lot of discussions about roles and a specific issue that has been raised recently is about the Scrummaster.
          >
          > Question:
          > Is there any situation / project type / circumstances where it might be NEGATIVE for the Scrummaster to be part of the team?
          >
          > Comments?

          My answer has to be no. At least I have never experienced that case.
          When the ScrumMaster is part of the team, because he or she has to
          wear two hats usually problems start to develop. Partly because the
          ScrumMaster has no direct commitments to delivery of a functional
          increment. His/her focus is on a completely different level. The Daily
          Scrum should make sure that information is passed back and forth from
          the team to the SM and vice versa.

          -d
          --
          Sent from gmail so do not trust this communication.
          Do not send me sensitive information here, ask for my none-gmail accounts.

          "Therefore the considerations of the intelligent always include both
          benefit and harm." - Sun Tzu
        • Stefan Svensson
          Hi again! Thanks for your answers! To put the qustion in a little different perspective I would like to re-formulate it a bit: Question re-formulated: In an
          Message 4 of 23 , Apr 23, 2007
          • 0 Attachment

            Hi again!

            Thanks for your answers!

            To put the qustion in a little different perspective I would like to re-formulate it a bit:

            Question re-formulated:
            In an "ideal Scrum-project", would you consider the Scrummaster  to be a Chicken or a Pig?

            Cheers
          • Mishkin Berteig
            Pig - the ScrumMaster is responsible for removing obstacles and shielding the rest of the team. The SM reports at the daily scrum on these things. Therefore
            Message 5 of 23 , Apr 23, 2007
            • 0 Attachment
              Pig - the ScrumMaster is responsible for removing obstacles and shielding the rest of the team.  The SM reports at the daily scrum on these things.  Therefore the SM is part of the team.
               
              Mishkin Berteig
              mishkin@...
              http://www.agileadvice.com/
              "Truthfulness is the foundation of all human virtues" - Baha'u'llah


              ----- Original Message ----
              From: Stefan Svensson <per_stefan_svensson@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Monday, April 23, 2007 7:23:42 AM
              Subject: [scrumdevelopment] Re: Scrummaster NOT part of the Team? (Is SM a Chicken Or a Pig?)


              Hi again!

              Thanks for your answers!

              To put the qustion in a little different perspective I would like to re-formulate it a bit:

              Question re-formulated:
              In an "ideal Scrum-project" , would you consider the Scrummaster  to be a Chicken or a Pig?

              Cheers




              Ahhh...imagining that irresistible "new car" smell?
              Check out new cars at Yahoo! Autos.
            • Spiridon Pappas
              Hi, According to my experience should
              Message 6 of 23 , Apr 23, 2007
              • 0 Attachment

                Hi,

                <Question re-formulated:>
                <In an "ideal Scrum-project", would you consider the Scrummaster  to be a Chicken or a Pig?>

                According to my experience should the scrummaster be a "pig" and part of the team.

                The reason for it is the special nature of work the scrum-master does from day to day, i.e the work identified as "removing obstacles".
                Reporting this kind of work back to the team in the same manner as all other work, gives the team the opportunity to plan and act with new knowledge and new possibilities at hand. This is crucial for projects with short spints.

                In the case of a larger projekt I tend to see project management as a scrum of scrums and the project leader as a scrummaster for the team of scrummasters. No project of any significance will succeed if not management become "pigs" and are part of the team.

                The special role of a scrummaster consists of not only work related to removing obstacles but also of work that helps the teams and the scrummaster(s) to grow and improve on the "finess" and effectiveness of the working process. He/she is the "observing eye" of any team with regard to the working process, at least initially. In time and within experienced Scrum teams this kind of "observing eye" role is played by any member of the team.

                Being a "pig" and part of the team shows commitment on a level equal with what is expected from any other member of the team. So why should it be any different with the scrummaster?

                Seing the role of the classical project leader as a scrummaster only differs in the kind of problems that are addressed. That might not be tehcnical obstacles but organisational or scope or external deliveries. The horizon might not be day to day but it still has to be in accordance to the scope and timeline of the project with the same commitment to obstacle reduction and delivery as any other member of the project.

                Otherwise a project leader /scrummaster tends to become an administrator/manager not part of the work being done.

                ----------------------------------------------------------------------------------
                Spiros Pappas
                e-post: spiridon.pappas@...
                Tel: 08-764 81 95
                ----------------------------------------------------------------------------------
              • David A Koontz
                ... I say the ScrumMaster is a Picken - part Pig part Chicken, and he/she should know the difference. If the SM is a pig - then there is a conflict of
                Message 7 of 23 , Apr 23, 2007
                • 0 Attachment
                  --- In scrumdevelopment@yahoogroups.com, "Stefan Svensson"
                  <per_stefan_svensson@...> wrote:

                  > To put the qustion in a little different perspective I would like to
                  > re-formulate it a bit:
                  >
                  > Question re-formulated:
                  > In an "ideal Scrum-project", would you consider the Scrummaster to be a
                  > Chicken or a Pig?


                  I say the ScrumMaster is a "Picken" - part Pig part Chicken, and
                  he/she should know the difference.

                  If the SM is a pig - then there is a conflict of interests. However
                  the SM is with the team so much that the team may start to see the SM
                  as one of them. If the SM is not a team member, they are a Chicken,
                  they will not be effective (by the rules of all chicken they can not
                  speak - that would be stupidly ineffective).

                  The analogy of the sheep dog comes to mind. A sheep dog is not a
                  sheep - however the sheep may appear to except the sheep dog as one of
                  their own, the sheep dog is a protector, they guard the sheep's
                  perimeter (the team containment field).

                  The problem with the Pig/Chicken analogy is it breaks down when we
                  talk of the SM - every analogy is only an analogy! Use your reason to
                  pick a new one when the old one breaks down.

                  David
                • Nicholas Cancelliere
                  The Scrummaster is one of the three roles on a Scrum team: Scrummaster, Product Owner and the Team. He is a pig as he is committed to the sprint (as is the
                  Message 8 of 23 , Apr 23, 2007
                  • 0 Attachment
                     
                    The Scrummaster is one of the three roles on a Scrum team:  Scrummaster, Product Owner and the Team. 
                     
                    He is a pig as he is committed to the sprint (as is the rest of the team), if he wasn't then what would the motivation be in unblocking team members?

                    Nicholas
                     

                     
                    On 4/23/07, Stefan Svensson <per_stefan_svensson@...> wrote:


                    Hi again!

                    Thanks for your answers!

                    To put the qustion in a little different perspective I would like to re-formulate it a bit:

                    Question re-formulated:
                    In an "ideal Scrum-project", would you consider the Scrummaster  to be a Chicken or a Pig?

                    Cheers




                    --
                    Nicholas Cancelliere, Austin TX
                    "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                  • dnicolet99
                    I don t think it s quite so cut-and-dried as that. Depending on the maturity of the team, and possibly on other organizational considerations, the role of the
                    Message 9 of 23 , Apr 23, 2007
                    • 0 Attachment
                      I don't think it's quite so cut-and-dried as that. Depending on the
                      maturity of the team, and possibly on other organizational
                      considerations, the role of the ScrumMaster may be a bit different
                      from one case to the next.

                      Have a look at this chart by David Geller:
                      http://www.davidgeller.net/blog/authority_delineation.htm

                      I think it's a pretty realistic summary of how pig-like or
                      chicken-like the ScrumMaster needs to be based on circumstances.

                      Dave

                      --- In scrumdevelopment@yahoogroups.com, "David A Koontz" <David@...>
                      wrote:
                      >
                      > --- In scrumdevelopment@yahoogroups.com, "Stefan Svensson"
                      > <per_stefan_svensson@> wrote:
                      >
                      > > To put the qustion in a little different perspective I would like to
                      > > re-formulate it a bit:
                      > >
                      > > Question re-formulated:
                      > > In an "ideal Scrum-project", would you consider the Scrummaster
                      to be a
                      > > Chicken or a Pig?
                      >
                      >
                      > I say the ScrumMaster is a "Picken" - part Pig part Chicken, and
                      > he/she should know the difference.
                      >
                      > If the SM is a pig - then there is a conflict of interests. However
                      > the SM is with the team so much that the team may start to see the SM
                      > as one of them. If the SM is not a team member, they are a Chicken,
                      > they will not be effective (by the rules of all chicken they can not
                      > speak - that would be stupidly ineffective).
                      >
                      > The analogy of the sheep dog comes to mind. A sheep dog is not a
                      > sheep - however the sheep may appear to except the sheep dog as one of
                      > their own, the sheep dog is a protector, they guard the sheep's
                      > perimeter (the team containment field).
                      >
                      > The problem with the Pig/Chicken analogy is it breaks down when we
                      > talk of the SM - every analogy is only an analogy! Use your reason to
                      > pick a new one when the old one breaks down.
                      >
                      > David
                      >
                    • Fred Montaseri
                      The question here is whether SM is a Pig (committed) or a Chicken (involved). And the answer is SM is committed ! SM is committed to the Scrum 100% and has
                      Message 10 of 23 , Apr 23, 2007
                      • 0 Attachment

                        The question here is whether SM is a Pig (committed) or a Chicken (involved). And the answer is SM is “committed”! SM is committed to the Scrum 100% and has the responsibility to protect the team and remove obstacles.

                         

                        Cheers,

                         

                        Kind Regards,

                        Fred Montaseri   
                        Email:  fmontaseri@...


                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of David A Koontz
                        Sent: April-23-07 1:24 PM
                        To: scrumdevelopment@yahoogroups.com
                        Subject: [scrumdevelopment] Re: Scrummaster NOT part of the Team? (Is SM a Chicken Or a Pig?)

                         

                        --- In scrumdevelopment@ yahoogroups. com, "Stefan Svensson"
                        <per_stefan_ svensson@ ...> wrote:

                        > To put the qustion in a little different perspective I would like to
                        > re-formulate it a bit:
                        >
                        > Question re-formulated:
                        > In an "ideal Scrum-project" , would you consider the
                        Scrummaster to be a
                        > Chicken or a Pig?

                        I say the ScrumMaster is a "Picken" - part Pig part Chicken, and
                        he/she should know the difference.

                        If the SM is a pig - then there is a conflict of interests. However
                        the SM is with the team so much that the team may start to see the SM
                        as one of them. If the SM is not a team member, they are a Chicken,
                        they will not be effective (by the rules of all chicken they can not
                        speak - that would be stupidly ineffective) .

                        The analogy of the sheep dog comes to mind. A sheep dog is not a
                        sheep - however the sheep may appear to except the sheep dog as one of
                        their own, the sheep dog is a protector, they guard the sheep's
                        perimeter (the team containment field).

                        The problem with the Pig/Chicken analogy is it breaks down when we
                        talk of the SM - every analogy is only an analogy! Use your reason to
                        pick a new one when the old one breaks down.

                        David

                      • Mark Smeltzer
                        The ScrumMaster should ALWAYS be part of the team. If they aren t a team member, then they are a chicken and have no voice in the daily scrum meetings. That
                        Message 11 of 23 , Apr 23, 2007
                        • 0 Attachment
                          The ScrumMaster should ALWAYS be part of the team. If they aren't a team member, then they are a chicken and have no voice in the daily scrum meetings. That would be absurd.
                           
                          Emilie seems to be using "team member" as synonymous with "developer", but since Scrum teams work best when they are cross functional, this definition is too restrictive. Team members are those with a voice in the Scrum meetings. It is quite possible for a SM to be a full time responsibility. It is also quite possible to assign the role of SM to a lower ranking developer so that the responsibility lines are not as blurred. With a more junior developer taking on the role of SM, the team will be less likely to look to this individual for project leadership.

                           
                          On 4/23/07, Emiliano Heyns <emiliano.heyns@...> wrote:

                          On 4/23/07, Stefan Svensson <per_stefan_svensson@...> wrote:
                          >
                          > We are currently in the process of implementing Scrum in the company where  I work!
                          >
                          > There has been a lot of discussions about roles and a specific issue that has been raised recently is about the Scrummaster.
                          >
                          > Question:
                          > Is there any situation / project type / circumstances where it might be NEGATIVE for the Scrummaster to be part of the team?

                          Yes -- ours. I am currently both SM and TM, and one of the problems is one of authority. As TM, I am allowed an opinion on how the project should be handled, who might be best to handle a task from the board, etc. As a scrum master, I don't think I'm supposed to influence that. With both roles combined, people look to me for project leadership, assigning tasks, etc.

                          Emile




                          --
                          ________________________________
                          Mark Smeltzer
                          Living Agile Consulting Services
                          http://www.livingagile.com/consulting
                        • David H.
                          ... It quite explicitly states in the official literature that the Scrum Master is not part of the team. Simply because he is not interested in delivering a
                          Message 12 of 23 , Apr 23, 2007
                          • 0 Attachment
                            On 23/04/07, Mark Smeltzer <mark.smeltzer@...> wrote:
                            >
                            >
                            >
                            >
                            >
                            >
                            >
                            > The ScrumMaster should ALWAYS be part of the team. If they aren't a team member, then they are a chicken and have no voice in the daily scrum meetings. That would be absurd.
                            >
                            It quite explicitly states in the official literature that the Scrum
                            Master is not part of the team. Simply because he is not interested in
                            delivering a functional increment of software. Which is true. A Scrum
                            Master does not pick up tasks from a Sprint Backlog. At least not the
                            ones I know?

                            -d

                            --
                            Sent from gmail so do not trust this communication.
                            Do not send me sensitive information here, ask for my none-gmail accounts.

                            "Therefore the considerations of the intelligent always include both
                            benefit and harm." - Sun Tzu
                          • Emiliano Heyns
                            ... Emile, please ... No, I m using team member as I understood the roles involved -- PO, SM and The Team. I m not saying the SM should not be committed,
                            Message 13 of 23 , Apr 23, 2007
                            • 0 Attachment
                              On 4/23/07, Mark Smeltzer <mark.smeltzer@...> wrote:

                              > Emilie

                              Emile, please

                              > seems to be using "team member" as synonymous with "developer",

                              No, I'm using "team member" as I understood the roles involved -- PO,
                              SM and The Team. I'm not saying the SM should not be committed, just
                              that his or her role will be different than the TMs.

                              > but since Scrum teams work best when they are cross functional, this definition is too
                              > restrictive. Team members are those with a voice in the Scrum meetings. It is quite
                              > possible for a SM to be a full time responsibility. It is also quite possible to assign the
                              > role of SM to a lower ranking developer so that the responsibility lines are not as blurred.
                              > With a more junior developer taking on the role of SM, the team will be less likely to look
                              > to this individual for project leadership.

                              That might be a good way to handle things. Another way could be to use
                              SMs across teams -- I see no issue in the SM being a TM on another
                              team (Team, sorry).

                              I see no inherent problem with the SM also being a TM on the same
                              team, or I would not have accepted those roles. I just don't think
                              it's ideal.

                              Emile
                            • Mark Smeltzer
                              Sorry about the name mix up! ... -- ________________________________ Mark Smeltzer Living Agile Consulting Services http://www.livingagile.com/consulting
                              Message 14 of 23 , Apr 23, 2007
                              • 0 Attachment
                                Sorry about the name mix up!

                                On 4/23/07, Emiliano Heyns <emiliano.heyns@...> wrote:

                                On 4/23/07, Mark Smeltzer <mark.smeltzer@...> wrote:

                                > Emilie

                                Emile, please

                                > seems to be using "team member" as synonymous with "developer",

                                No, I'm using "team member" as I understood the roles involved -- PO,
                                SM and The Team. I'm not saying the SM should not be committed, just
                                that his or her role will be different than the TMs.

                                > but since Scrum teams work best when they are cross functional, this definition is too
                                > restrictive. Team members are those with a voice in the Scrum meetings. It is quite
                                > possible for a SM to be a full time responsibility. It is also quite possible to assign the
                                > role of SM to a lower ranking developer so that the responsibility lines are not as blurred.
                                > With a more junior developer taking on the role of SM, the team will be less likely to look
                                > to this individual for project leadership.

                                That might be a good way to handle things. Another way could be to use
                                SMs across teams -- I see no issue in the SM being a TM on another
                                team (Team, sorry).

                                I see no inherent problem with the SM also being a TM on the same
                                team, or I would not have accepted those roles. I just don't think
                                it's ideal.

                                Emile




                                --
                                ________________________________
                                Mark Smeltzer
                                Living Agile Consulting Services
                                http://www.livingagile.com/consulting
                              • Mark Smeltzer
                                Emile, You and David seem to be using the term team member in the same way, and as far as roles are concerned, we re on the same page. In practice, however,
                                Message 15 of 23 , Apr 23, 2007
                                • 0 Attachment
                                  Emile,
                                   
                                  You and David seem to be using the term "team member" in the same way, and as far as roles are concerned, we're on the same page.
                                   
                                  In practice, however, it is common for one person to have multiple Scrum roles, and in this context I am just calling all of the people who aren't "Chickens" part of the "team". As David said, as far as the SM role goes, the SM does not have any functional responsibilities, but if the person with the SM role also has a TM role, this person will have functional responsibilities in the context of the TM role even though they have the SM role. Anyway, that should all be clear enough.
                                   
                                  Regarding the original questions, the ideal circumstance is to have a dedicated SM. A dedicated SM could fill this role on multiple teams (though I have no personal experience with this, it seems feasible). What I have seen work well in practice is for the one of the more senior people to elect one of the more junior people to the SM role. I have also seen some teams have rotating SMs so that the burden of the extra responsibilities are distributed across the team and so that everyone on the team gains insight into world of the SM. I've also seen teams bring in an HR type facilitator to function as the SM for a conflicted team, and since these people are typically trained in conflict resolution and are more sensitive to diplomatic issues, it can have a calming effect and get the team back on track. Regardless, excellent communication and diplomatic skills are inherent to the ideal SM.
                                   
                                  Best of luck,
                                   
                                   
                                  On 4/23/07, Emiliano Heyns <emiliano.heyns@...> wrote:

                                  On 4/23/07, Mark Smeltzer <mark.smeltzer@...> wrote:

                                  > Emilie

                                  Emile, please

                                  > seems to be using "team member" as synonymous with "developer",

                                  No, I'm using "team member" as I understood the roles involved -- PO,
                                  SM and The Team. I'm not saying the SM should not be committed, just
                                  that his or her role will be different than the TMs.

                                  > but since Scrum teams work best when they are cross functional, this definition is too
                                  > restrictive. Team members are those with a voice in the Scrum meetings. It is quite
                                  > possible for a SM to be a full time responsibility. It is also quite possible to assign the
                                  > role of SM to a lower ranking developer so that the responsibility lines are not as blurred.
                                  > With a more junior developer taking on the role of SM, the team will be less likely to look
                                  > to this individual for project leadership.

                                  That might be a good way to handle things. Another way could be to use
                                  SMs across teams -- I see no issue in the SM being a TM on another
                                  team (Team, sorry).

                                  I see no inherent problem with the SM also being a TM on the same
                                  team, or I would not have accepted those roles. I just don't think
                                  it's ideal.

                                  Emile




                                  --
                                  ________________________________
                                  Mark Smeltzer
                                  Living Agile Consulting Services
                                  http://www.livingagile.com/consulting
                                • jay_conne
                                  Emile, David, Mark, I think this discussion needs a step back to examine the essentials and full context. The key to sorting out the questions is to understand
                                  Message 16 of 23 , Apr 23, 2007
                                  • 0 Attachment
                                    Emile, David, Mark,

                                    I think this discussion needs a step back to examine the essentials
                                    and full context.

                                    The key to sorting out the questions is to understand the roles and
                                    responsibilities clearly. If management doesn't support a clear
                                    division of responsibilities to balance conflicts of interest, they
                                    can't get the benefits of it. If that's the case there's only a few
                                    choices:
                                    1. make the case better, perhaps with consulting help, if you think
                                    that's appropriate; or
                                    2. see if a non-scrum approach is doable for this project of course
                                    informed by the agile insights as much as possible; or
                                    3. find a winning environment for yourself :-).

                                    It helps to get beyond the superficiality of the chicken/pig lore.
                                    I use it only with humor and to make a narrow point about commitment.
                                    Mary and Tom Poppendieck emphasize that all need to be really
                                    committed to the project's success - every level of management,
                                    customers and of course the x-f dev. team. In that sense all are
                                    pigs. But thaat misses the intended distinction and different
                                    responsibilities.

                                    The key division is between a committed buyer and a seller - a
                                    healthy, win-win relationship:
                                    - the sponsor/management/customer axis is the buyer - wanting to
                                    pay for some specific business value - this axis is represented by a
                                    focused single voice through the PO
                                    - the cross functional development team is the seller - wanting to
                                    deliver business value for pay
                                    - the SM is a coach and facilitator - like on a sports team,
                                    watching and mirroring the interactions back to the players, i.e.
                                    while the players focus on the detail the SM/coach can see the larger
                                    context and mirror that back to the players. They have a different
                                    focus. In adition, the SM needs own the impediments
                                    resolution/negotiation.

                                    IMO, Scrum is best understood as a simple interaction model that wraps
                                    good business and engineering discipline ala XP.

                                    It demands team members accept the responsibility for independent
                                    thinking and responsibility. This is an act of integrity for
                                    themselves, their team and their employer. You won't find this issue
                                    discussed in the literature or much on the group lists, but I think
                                    it's essential - Scrum requires integrity.

                                    As the TM, you are responsible for the engineering discipline and you
                                    can be part of the team if that fits in your situation. At the very
                                    least, you or your CTO need to have a role in accepting the work too.
                                    It has to meet a level of maintainability and operability before
                                    shipping to internal or external customers.

                                    I have seen very 'piggy' POs who add technical value to the delivery.
                                    But then they or a sponsor needs to take responsibility for accepting
                                    the work. But is it their work?

                                    As a SM, I have been willing to jump in and lend a hand when it was
                                    needed on the team - but that's not my responsibility as I play my role.

                                    I have seen a PO forced to also play SM - and then run away from the
                                    pressure by leaving the company - a big loss in this case, but best
                                    for the individual.

                                    I know of a project where the TM is the SM and the CTO is the PO. The
                                    former is worrysome for me but the latter is not. CTO as PO mkes
                                    sense for an internal product with a strong technical center. The TM
                                    as SM is a harder balance and I'll be watching to see how they do with
                                    it.

                                    I hope this helps,

                                    Jay Conne
                                    www.jconne.com
                                    Lean/Agile Coach, Trainer and
                                    ScrumMaster-Practicing.

                                    --- In scrumdevelopment@yahoogroups.com, "Mark Smeltzer"
                                    <mark.smeltzer@...> wrote:
                                    >
                                    > Emile,
                                    >
                                    > You and David seem to be using the term "team member" in the same
                                    way, and
                                    > as far as roles are concerned, we're on the same page.
                                    >
                                    > In practice, however, it is common for one person to have multiple Scrum
                                    > roles, and in this context I am just calling all of the people who
                                    > aren't "Chickens" part of the "team". As David said, as far as the
                                    SM role
                                    > goes, the SM does not have any functional responsibilities, but if the *
                                    > person* with the SM role also has a TM role, this person will have
                                    > functional responsibilities in the context of the TM role even
                                    though they
                                    > have the SM role. Anyway, that should all be clear enough.
                                    >
                                    > Regarding the original questions, the ideal circumstance is to have a
                                    > dedicated SM. A dedicated SM could fill this role on multiple teams
                                    (though
                                    > I have no personal experience with this, it seems feasible). What I have
                                    > seen work well in practice is for the one of the more senior people
                                    to elect
                                    > one of the more junior people to the SM role. I have also seen some
                                    teams
                                    > have rotating SMs so that the burden of the extra responsibilities are
                                    > distributed across the team and so that everyone on the team gains
                                    insight
                                    > into world of the SM. I've also seen teams bring in an HR type
                                    facilitator
                                    > to function as the SM for a conflicted team, and since these people are
                                    > typically trained in conflict resolution and are more sensitive to
                                    > diplomatic issues, it can have a calming effect and get the team back on
                                    > track. Regardless, excellent communication and diplomatic skills are
                                    > inherent to the ideal SM.
                                    >
                                    > Best of luck,
                                    >
                                    >
                                    > On 4/23/07, Emiliano Heyns <emiliano.heyns@...> wrote:
                                    > >
                                    > > On 4/23/07, Mark Smeltzer
                                    <mark.smeltzer@...<mark.smeltzer%40gmail.com>>
                                    > > wrote:
                                    > >
                                    > > > Emilie
                                    > >
                                    > > Emile, please
                                    > >
                                    > > > seems to be using "team member" as synonymous with "developer",
                                    > >
                                    > > No, I'm using "team member" as I understood the roles involved -- PO,
                                    > > SM and The Team. I'm not saying the SM should not be committed, just
                                    > > that his or her role will be different than the TMs.
                                    > >
                                    > > > but since Scrum teams work best when they are cross functional, this
                                    > > definition is too
                                    > > > restrictive. Team members are those with a voice in the Scrum
                                    meetings.
                                    > > It is quite
                                    > > > possible for a SM to be a full time responsibility. It is also quite
                                    > > possible to assign the
                                    > > > role of SM to a lower ranking developer so that the
                                    responsibility lines
                                    > > are not as blurred.
                                    > > > With a more junior developer taking on the role of SM, the team
                                    will be
                                    > > less likely to look
                                    > > > to this individual for project leadership.
                                    > >
                                    > > That might be a good way to handle things. Another way could be to use
                                    > > SMs across teams -- I see no issue in the SM being a TM on another
                                    > > team (Team, sorry).
                                    > >
                                    > > I see no inherent problem with the SM also being a TM on the same
                                    > > team, or I would not have accepted those roles. I just don't think
                                    > > it's ideal.
                                    > >
                                    > > Emile
                                    > --
                                    > ________________________________
                                    > Mark Smeltzer
                                    > Living Agile Consulting Services
                                    > http://www.livingagile.com/consulting
                                    >
                                  • Nicholas Cancelliere
                                    I disagree, and I hate this chart (for the record). That chart expresses moving from a command and control organization to one that s self-managing. It might
                                    Message 17 of 23 , Apr 24, 2007
                                    • 0 Attachment
                                      I disagree, and I hate this chart (for the record).  That chart expresses moving from a command and control organization to one that's self-managing.  It might be the job of a Scrummaster to lead the team in this journey - but at the point in "R1" where the Scrummaster is directing and making a decision, he's simply a project manager by another name.

                                      The reason Ken gave the title "Scrummaster" and not "Project Manager" is because the Scrummaster is not a project manager.  We do not use command and control to organize teams.  We instead coach and use servant leadership tactics to organize teams.  In the example you cited I'd argue that in R1 you don't have a Scrum team or a Scrummaster.  R1 describes the state of any software team Agile or not.  Now saying the team's goal is to get to R4 or beyond then you have a waterfall team trying to become Agile.  At some point the project manager has to make the transition into the Scrummaster role (just as the team has to make the transition to being self-organizing and directing).  I wouldn't say that a Scrummaster is a chicken.

                                      Again, if a Scrummaster is a chicken - not committed to the sprint - what is his motivation to protect the team and remove impediments?

                                      As a chicken you're an outsider "laying eggs" (dropping issues, advice, etc).  Typically you see this as a Marketing VP, SME, Project Management Office, domain consultant, or something to this effect.  In the descriptions on the chart the "Scrummaster" is not acting as a chicken -- he's acting as the boss.  You can invite them in at different points of your planning meeting for their special knowledge, but generally dismiss them after you're done.  In the stand-ups they're invited to attend, but cannot speak.  Chicken's have no real commitment to the sprint - no tasks to perform.  They attend stand-ups only to obtain status for themselves.




                                      On 4/23/07, dnicolet99 <dnicolet@...> wrote:

                                      I don't think it's quite so cut-and-dried as that. Depending on the
                                      maturity of the team, and possibly on other organizational
                                      considerations, the role of the ScrumMaster may be a bit different
                                      from one case to the next.

                                      Have a look at this chart by David Geller:
                                      http://www.davidgeller.net/blog/authority_delineation.htm

                                      I think it's a pretty realistic summary of how pig-like or
                                      chicken-like the ScrumMaster needs to be based on circumstances.

                                      Dave

                                      --- In scrumdevelopment@yahoogroups.com, "David A Koontz" <David@...>


                                      wrote:
                                      >
                                      > --- In scrumdevelopment@yahoogroups.com, "Stefan Svensson"
                                      > <per_stefan_svensson@> wrote:
                                      >
                                      > > To put the qustion in a little different perspective I would like to
                                      > > re-formulate it a bit:
                                      > >
                                      > > Question re-formulated:
                                      > > In an "ideal Scrum-project", would you consider the Scrummaster
                                      to be a
                                      > > Chicken or a Pig?
                                      >
                                      >
                                      > I say the ScrumMaster is a "Picken" - part Pig part Chicken, and
                                      > he/she should know the difference.
                                      >
                                      > If the SM is a pig - then there is a conflict of interests. However
                                      > the SM is with the team so much that the team may start to see the SM
                                      > as one of them. If the SM is not a team member, they are a Chicken,
                                      > they will not be effective (by the rules of all chicken they can not
                                      > speak - that would be stupidly ineffective).
                                      >
                                      > The analogy of the sheep dog comes to mind. A sheep dog is not a
                                      > sheep - however the sheep may appear to except the sheep dog as one of
                                      > their own, the sheep dog is a protector, they guard the sheep's
                                      > perimeter (the team containment field).
                                      >
                                      > The problem with the Pig/Chicken analogy is it breaks down when we
                                      > talk of the SM - every analogy is only an analogy! Use your reason to
                                      > pick a new one when the old one breaks down.
                                      >
                                      > David
                                      >




                                      --
                                      Nicholas Cancelliere, Austin TX
                                      "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
                                    • dnicolet99
                                      ... in R1 ... state of any ... R4 or ... Can you imagine any ways in which you might be able to guide the development of such a team if you found yourself in
                                      Message 18 of 23 , Apr 24, 2007
                                      • 0 Attachment
                                        --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                        <nickaustin74@...> wrote:

                                        > We do not use command and
                                        > control to organize teams. We instead coach and use servant leadership
                                        > tactics to organize teams. In the example you cited I'd argue that
                                        in R1
                                        > you don't have a Scrum team or a Scrummaster. R1 describes the
                                        state of any
                                        > software team Agile or not. Now saying the team's goal is to get to
                                        R4 or
                                        > beyond then you have a waterfall team trying to become Agile.

                                        Can you imagine any ways in which you might be able to guide the
                                        development of such a team if you found yourself in the position of
                                        ScrumMaster in an R1 situation?

                                        Dave
                                      • Nicholas Cancelliere
                                        On a team unable or unwilling to use Scrum ... then I m not a Scrummaster, not for that team. Why are you implementing Scrum for a team that s unwilling or
                                        Message 19 of 23 , May 1, 2007
                                        • 0 Attachment

                                          On a team unable or unwilling to use Scrum ... then I'm not a Scrummaster, not for that team.  Why are you implementing Scrum for a team that's unwilling or unable to manage or direct themselves?  If the team doesn't want to use Scrum then you can't be a Scrummaster for them.

                                          At that stage you have a bigger problem -- that is just getting the team to recognize the benefits of Agile.  Why is the team unwilling or unable?

                                          Nicholas



                                          On Apr 24, 2007, at 6:24 PM, dnicolet99 wrote:

                                          --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                          <nickaustin74@...> wrote:

                                          > We do not use command and
                                          > control to organize teams. We instead coach and use servant leadership
                                          > tactics to organize teams. In the example you cited I'd argue that
                                          in R1
                                          > you don't have a Scrum team or a Scrummaster. R1 describes the
                                          state of any
                                          > software team Agile or not. Now saying the team's goal is to get to
                                          R4 or
                                          > beyond then you have a waterfall team trying to become Agile.

                                          Can you imagine any ways in which you might be able to guide the
                                          development of such a team if you found yourself in the position of
                                          ScrumMaster in an R1 situation?

                                          Dave


                                        • dnicolet99
                                          Yes, in that case you have a bigger problem, but it s a common situation. So, I understand your answer to be as follows: If you were assigned to be a
                                          Message 20 of 23 , May 1, 2007
                                          • 0 Attachment
                                            Yes, in that case you have a bigger problem, but it's a common
                                            situation. So, I understand your answer to be as follows: If you were
                                            assigned to be a ScrumMaster on a team like that, your first order of
                                            business would be to help the team members understand the benefits of
                                            agile. Your comment suggests your first step would be to try and
                                            understand why they are unwilling or unable. Is that correct?

                                            As to "why are you implementing Scrum", that's a different issue. The
                                            world is full of teams that don't know how to self-manage. It's the
                                            status quo. In the context of the R1 scenario, the "why" is that
                                            "someone" (the company's management) has decided Scrum is the right
                                            way to go. In the context of my question, "someone" (you) has been
                                            hired for the ScrumMaster role. The situation on the ground on Day One
                                            is what it is. The question is what will the ScrumMaster do about it,
                                            above and beyond just saying that there's no way for him to "be" a
                                            ScrumMaster?

                                            Dave

                                            --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                            <nickaustin74@...> wrote:
                                            >
                                            >
                                            > On a team unable or unwilling to use Scrum ... then I'm not a
                                            > Scrummaster, not for that team. Why are you implementing Scrum for a
                                            > team that's unwilling or unable to manage or direct themselves? If
                                            > the team doesn't want to use Scrum then you can't be a Scrummaster
                                            > for them.
                                            >
                                            > At that stage you have a bigger problem -- that is just getting the
                                            > team to recognize the benefits of Agile. Why is the team unwilling
                                            > or unable?
                                            >
                                            > Nicholas
                                            >
                                            >
                                            >
                                            > On Apr 24, 2007, at 6:24 PM, dnicolet99 wrote:
                                            >
                                            > > --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                            > > <nickaustin74@> wrote:
                                            > >
                                            > > > We do not use command and
                                            > > > control to organize teams. We instead coach and use servant
                                            > > leadership
                                            > > > tactics to organize teams. In the example you cited I'd argue that
                                            > > in R1
                                            > > > you don't have a Scrum team or a Scrummaster. R1 describes the
                                            > > state of any
                                            > > > software team Agile or not. Now saying the team's goal is to get to
                                            > > R4 or
                                            > > > beyond then you have a waterfall team trying to become Agile.
                                            > >
                                            > > Can you imagine any ways in which you might be able to guide the
                                            > > development of such a team if you found yourself in the position of
                                            > > ScrumMaster in an R1 situation?
                                            > >
                                            > > Dave
                                            > >
                                            > >
                                            > >
                                            >
                                          • Nicholas Cancelliere
                                            I guess the reason I ask the question is I m trying to understand if the team is unwilling and unable because what they do right now is working. In other
                                            Message 21 of 23 , May 1, 2007
                                            • 0 Attachment

                                              I guess the reason I ask the question is I'm trying to understand if the team is unwilling and unable because what they do right now is working.  In other words I wouldn't want to get into a situation where the team was performing fine, but the management wanted to force them to use Scrum because it's the hot thing to do right now in software development.  I would lead the team into understanding what Agile methods are and why they're beneficial, and then suggest that Scrum is a way to implement (along with some XP practices).

                                              I honestly would avoid the above scenario if possible (just because someone wants to hire me doesn't me I have to work for them), that or want a lot of money - because that is going to be a big headache.  If the team was not performing well, then that gives me something to work with - because I believe people in general want do do a good job and perform, and I assume such a team was looking for help (willing, but not yet able).

                                              In the R1 scenario where the team is unwilling and unable ... my first order of business would be to discover the root cause for being unwilling, then work on education and coaching.  Maybe I convince them to adopt a product backlog and gross estimates and start tracking a burndown on completed features.  Then next I might have them plan their own release.  Then later get them to plan iterations inside that release, etc.  These are only examples, I don't think there is a set prescription for any team.  I have coached 4 teams over the past 2 years and they were all different in their adoption.  All teams start at different levels of experience and have different organizational pressures, etc.  With any adoption you don't want to rush them, take baby steps and let them come to their own conclusions.  Be there as a coach and help offer advice, best practices, challenge their thinking - get them to open up to different perspectives.  I know I've done my job when I'm no longer needed and the team is essentially running itself, that means I did a good job.

                                              At no point though do I act as a project manager or their boss, that'd be setting a bad example.

                                              Nicholas



                                              On May 1, 2007, at 8:55 AM, dnicolet99 wrote:

                                              Yes, in that case you have a bigger problem, but it's a common
                                              situation. So, I understand your answer to be as follows: If you were
                                              assigned to be a ScrumMaster on a team like that, your first order of
                                              business would be to help the team members understand the benefits of
                                              agile. Your comment suggests your first step would be to try and
                                              understand why they are unwilling or unable. Is that correct?

                                              As to "why are you implementing Scrum", that's a different issue. The
                                              world is full of teams that don't know how to self-manage. It's the
                                              status quo. In the context of the R1 scenario, the "why" is that
                                              "someone" (the company's management) has decided Scrum is the right
                                              way to go. In the context of my question, "someone" (you) has been
                                              hired for the ScrumMaster role. The situation on the ground on Day One
                                              is what it is. The question is what will the ScrumMaster do about it,
                                              above and beyond just saying that there's no way for him to "be" a
                                              ScrumMaster?

                                              Dave

                                              --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                              <nickaustin74@...> wrote:
                                              >
                                              >
                                              > On a team unable or unwilling to use Scrum ... then I'm not a
                                              > Scrummaster, not for that team. Why are you implementing Scrum for a
                                              > team that's unwilling or unable to manage or direct themselves? If
                                              > the team doesn't want to use Scrum then you can't be a Scrummaster
                                              > for them.
                                              >
                                              > At that stage you have a bigger problem -- that is just getting the
                                              > team to recognize the benefits of Agile. Why is the team unwilling
                                              > or unable?
                                              >
                                              > Nicholas
                                              >
                                              >
                                              >
                                              > On Apr 24, 2007, at 6:24 PM, dnicolet99 wrote:
                                              >
                                              > > --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                              > > <nickaustin74@> wrote:
                                              > >
                                              > > > We do not use command and
                                              > > > control to organize teams. We instead coach and use servant
                                              > > leadership
                                              > > > tactics to organize teams. In the example you cited I'd argue that
                                              > > in R1
                                              > > > you don't have a Scrum team or a Scrummaster. R1 describes the
                                              > > state of any
                                              > > > software team Agile or not. Now saying the team's goal is to get to
                                              > > R4 or
                                              > > > beyond then you have a waterfall team trying to become Agile.
                                              > >
                                              > > Can you imagine any ways in which you might be able to guide the
                                              > > development of such a team if you found yourself in the position of
                                              > > ScrumMaster in an R1 situation?
                                              > >
                                              > > Dave
                                              > >
                                              > >
                                              > >
                                              >


                                            • dnicolet99
                                              ... That makes a lot of sense to me. There s always the question of what they mean by working. There s always room for improvement. ... True. Some people are
                                              Message 22 of 23 , May 1, 2007
                                              • 0 Attachment
                                                --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                                <nickaustin74@...> wrote:
                                                >
                                                >
                                                > I guess the reason I ask the question is I'm trying to understand if
                                                > the team is unwilling and unable because what they do right now is
                                                > working. In other words I wouldn't want to get into a situation
                                                > where the team was performing fine, but the management wanted to
                                                > force them to use Scrum because it's the hot thing to do right now in
                                                > software development. I would lead the team into understanding what
                                                > Agile methods are and why they're beneficial, and then suggest that
                                                > Scrum is a way to implement (along with some XP practices).

                                                That makes a lot of sense to me. There's always the question of what
                                                they mean by "working." There's always room for improvement.


                                                >
                                                > I honestly would avoid the above scenario if possible (just because
                                                > someone wants to hire me doesn't me I have to work for them), that or
                                                > want a lot of money - because that is going to be a big headache.

                                                True. Some people are interested in bringing agile into non-agile
                                                organizations, and others are interested in putting agile practices to
                                                work in organizations that already understand the benefits.



                                                > If
                                                > the team was not performing well, then that gives me something to
                                                > work with - because I believe people in general want do do a good job
                                                > and perform, and I assume such a team was looking for help (willing,
                                                > but not yet able).
                                                >
                                                > In the R1 scenario where the team is unwilling and unable ... my
                                                > first order of business would be to discover the root cause for being
                                                > unwilling, then work on education and coaching. Maybe I convince
                                                > them to adopt a product backlog and gross estimates and start
                                                > tracking a burndown on completed features. Then next I might have
                                                > them plan their own release. Then later get them to plan iterations
                                                > inside that release, etc. These are only examples, I don't think
                                                > there is a set prescription for any team. I have coached 4 teams
                                                > over the past 2 years and they were all different in their adoption.
                                                > All teams start at different levels of experience and have different
                                                > organizational pressures, etc. With any adoption you don't want to
                                                > rush them, take baby steps and let them come to their own
                                                > conclusions. Be there as a coach and help offer advice, best
                                                > practices, challenge their thinking - get them to open up to
                                                > different perspectives. I know I've done my job when I'm no longer
                                                > needed and the team is essentially running itself, that means I did a
                                                > good job.
                                                >
                                                > At no point though do I act as a project manager or their boss,
                                                > that'd be setting a bad example.
                                                >
                                                > Nicholas
                                                >
                                                >
                                                >
                                                > On May 1, 2007, at 8:55 AM, dnicolet99 wrote:
                                                >
                                                > > Yes, in that case you have a bigger problem, but it's a common
                                                > > situation. So, I understand your answer to be as follows: If you were
                                                > > assigned to be a ScrumMaster on a team like that, your first order of
                                                > > business would be to help the team members understand the benefits of
                                                > > agile. Your comment suggests your first step would be to try and
                                                > > understand why they are unwilling or unable. Is that correct?
                                                > >
                                                > > As to "why are you implementing Scrum", that's a different issue. The
                                                > > world is full of teams that don't know how to self-manage. It's the
                                                > > status quo. In the context of the R1 scenario, the "why" is that
                                                > > "someone" (the company's management) has decided Scrum is the right
                                                > > way to go. In the context of my question, "someone" (you) has been
                                                > > hired for the ScrumMaster role. The situation on the ground on Day One
                                                > > is what it is. The question is what will the ScrumMaster do about it,
                                                > > above and beyond just saying that there's no way for him to "be" a
                                                > > ScrumMaster?
                                                > >
                                                > > Dave
                                                > >
                                                > > --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                                > > <nickaustin74@> wrote:
                                                > > >
                                                > > >
                                                > > > On a team unable or unwilling to use Scrum ... then I'm not a
                                                > > > Scrummaster, not for that team. Why are you implementing Scrum for a
                                                > > > team that's unwilling or unable to manage or direct themselves? If
                                                > > > the team doesn't want to use Scrum then you can't be a Scrummaster
                                                > > > for them.
                                                > > >
                                                > > > At that stage you have a bigger problem -- that is just getting the
                                                > > > team to recognize the benefits of Agile. Why is the team unwilling
                                                > > > or unable?
                                                > > >
                                                > > > Nicholas
                                                > > >
                                                > > >
                                                > > >
                                                > > > On Apr 24, 2007, at 6:24 PM, dnicolet99 wrote:
                                                > > >
                                                > > > > --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                                > > > > <nickaustin74@> wrote:
                                                > > > >
                                                > > > > > We do not use command and
                                                > > > > > control to organize teams. We instead coach and use servant
                                                > > > > leadership
                                                > > > > > tactics to organize teams. In the example you cited I'd argue
                                                > > that
                                                > > > > in R1
                                                > > > > > you don't have a Scrum team or a Scrummaster. R1 describes the
                                                > > > > state of any
                                                > > > > > software team Agile or not. Now saying the team's goal is to
                                                > > get to
                                                > > > > R4 or
                                                > > > > > beyond then you have a waterfall team trying to become Agile.
                                                > > > >
                                                > > > > Can you imagine any ways in which you might be able to guide the
                                                > > > > development of such a team if you found yourself in the
                                                > > position of
                                                > > > > ScrumMaster in an R1 situation?
                                                > > > >
                                                > > > > Dave
                                                > > > >
                                                > > > >
                                                > > > >
                                                > > >
                                                > >
                                                > >
                                                > >
                                                >
                                              • Nicholas Cancelliere
                                                To me that chart shows a potential growth plan for someone who is a project manager and is transitioning into the scurmmaster role - as the team itself is
                                                Message 23 of 23 , May 1, 2007
                                                • 0 Attachment

                                                  To me that chart shows a potential growth plan for someone who is a project manager and is transitioning into the scurmmaster role - as the team itself is evolving to be more Agile.  Keep in mind though that the PM isn't always the place a scrummaster is born.  Sometimes they come out of QA.  Sometimes they're hired from the outside.

                                                  I couldn't say though at in R1 or even R2 you have a "scrummaster" - you really have a project manager, by another name.  It isn't until you get to the point where their is more coaching, facilitation and less command and control that you're moving out of the project manager role and into the scrummaster role.

                                                  Nicholas


                                                  On May 1, 2007, at 10:52 AM, dnicolet99 wrote:

                                                  --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                                  <nickaustin74@...> wrote:
                                                  >
                                                  >
                                                  > I guess the reason I ask the question is I'm trying to understand if
                                                  > the team is unwilling and unable because what they do right now is
                                                  > working. In other words I wouldn't want to get into a situation
                                                  > where the team was performing fine, but the management wanted to
                                                  > force them to use Scrum because it's the hot thing to do right now in
                                                  > software development. I would lead the team into understanding what
                                                  > Agile methods are and why they're beneficial, and then suggest that
                                                  > Scrum is a way to implement (along with some XP practices).

                                                  That makes a lot of sense to me. There's always the question of what
                                                  they mean by "working." There's always room for improvement.

                                                  >
                                                  > I honestly would avoid the above scenario if possible (just because
                                                  > someone wants to hire me doesn't me I have to work for them), that or
                                                  > want a lot of money - because that is going to be a big headache.

                                                  True. Some people are interested in bringing agile into non-agile
                                                  organizations, and others are interested in putting agile practices to
                                                  work in organizations that already understand the benefits.

                                                  > If
                                                  > the team was not performing well, then that gives me something to
                                                  > work with - because I believe people in general want do do a good job
                                                  > and perform, and I assume such a team was looking for help (willing,
                                                  > but not yet able).
                                                  >
                                                  > In the R1 scenario where the team is unwilling and unable ... my
                                                  > first order of business would be to discover the root cause for being
                                                  > unwilling, then work on education and coaching. Maybe I convince
                                                  > them to adopt a product backlog and gross estimates and start
                                                  > tracking a burndown on completed features. Then next I might have
                                                  > them plan their own release. Then later get them to plan iterations
                                                  > inside that release, etc. These are only examples, I don't think
                                                  > there is a set prescription for any team. I have coached 4 teams
                                                  > over the past 2 years and they were all different in their adoption.
                                                  > All teams start at different levels of experience and have different
                                                  > organizational pressures, etc. With any adoption you don't want to
                                                  > rush them, take baby steps and let them come to their own
                                                  > conclusions. Be there as a coach and help offer advice, best
                                                  > practices, challenge their thinking - get them to open up to
                                                  > different perspectives. I know I've done my job when I'm no longer
                                                  > needed and the team is essentially running itself, that means I did a
                                                  > good job.
                                                  >
                                                  > At no point though do I act as a project manager or their boss,
                                                  > that'd be setting a bad example.
                                                  >
                                                  > Nicholas
                                                  >
                                                  >
                                                  >
                                                  > On May 1, 2007, at 8:55 AM, dnicolet99 wrote:
                                                  >
                                                  > > Yes, in that case you have a bigger problem, but it's a common
                                                  > > situation. So, I understand your answer to be as follows: If you were
                                                  > > assigned to be a ScrumMaster on a team like that, your first order of
                                                  > > business would be to help the team members understand the benefits of
                                                  > > agile. Your comment suggests your first step would be to try and
                                                  > > understand why they are unwilling or unable. Is that correct?
                                                  > >
                                                  > > As to "why are you implementing Scrum", that's a different issue. The
                                                  > > world is full of teams that don't know how to self-manage. It's the
                                                  > > status quo. In the context of the R1 scenario, the "why" is that
                                                  > > "someone" (the company's management) has decided Scrum is the right
                                                  > > way to go. In the context of my question, "someone" (you) has been
                                                  > > hired for the ScrumMaster role. The situation on the ground on Day One
                                                  > > is what it is. The question is what will the ScrumMaster do about it,
                                                  > > above and beyond just saying that there's no way for him to "be" a
                                                  > > ScrumMaster?
                                                  > >
                                                  > > Dave
                                                  > >
                                                  > > --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
                                                  > > <nickaustin74@> wrote:
                                                  > > >
                                                  > > >
                                                  > > > On a team unable or unwilling to use Scrum ... then I'm not a
                                                  > > > Scrummaster, not for that team. Why are you implementing Scrum for a
                                                  > > > team that's unwilling or unable to manage or direct themselves? If
                                                  > > > the team doesn't want to use Scrum then you can't be a Scrummaster
                                                  > > > for them.
                                                  > > >
                                                  > > > At that stage you have a bigger problem -- that is just getting the
                                                  > > > team to recognize the benefits of Agile. Why is the team unwilling
                                                  > > > or unable?
                                                  > > >
                                                  > > > Nicholas
                                                  > > >
                                                  > > >
                                                  > > >
                                                  > > > On Apr 24, 2007, at 6:24 PM, dnicolet99 wrote:
                                                  > > >
                                                  > > > > --- In scrumdevelopment@yahoogroups.com, "Nicholas Cancelliere"
                                                  > > > > <nickaustin74@> wrote:
                                                  > > > >
                                                  > > > > > We do not use command and
                                                  > > > > > control to organize teams. We instead coach and use servant
                                                  > > > > leadership
                                                  > > > > > tactics to organize teams. In the example you cited I'd argue
                                                  > > that
                                                  > > > > in R1
                                                  > > > > > you don't have a Scrum team or a Scrummaster. R1 describes the
                                                  > > > > state of any
                                                  > > > > > software team Agile or not. Now saying the team's goal is to
                                                  > > get to
                                                  > > > > R4 or
                                                  > > > > > beyond then you have a waterfall team trying to become Agile.
                                                  > > > >
                                                  > > > > Can you imagine any ways in which you might be able to guide the
                                                  > > > > development of such a team if you found yourself in the
                                                  > > position of
                                                  > > > > ScrumMaster in an R1 situation?
                                                  > > > >
                                                  > > > > Dave
                                                  > > > >
                                                  > > > >
                                                  > > > >
                                                  > > >
                                                  > >
                                                  > >
                                                  > >
                                                  >


                                                Your message has been successfully submitted and would be delivered to recipients shortly.