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

Re: [scrumdevelopment] Re: scrum master with a non technical background

Expand Messages
  • Adam Sroka
    I have always been suspicious of Scrummasters. If there are a lot of organizational obstacles and they are effective in removing them then they are worth their
    Message 1 of 10 , Jun 10, 2010
    • 0 Attachment
      I have always been suspicious of Scrummasters. If there are a lot of
      organizational obstacles and they are effective in removing them then
      they are worth their weight in gold. However, there is a tendency to
      devolve in one of two directions:

      1) The team is highly effective and therefore the scrummaster role is
      superfluous.

      2) The obstacles that the team encounters are not of a kind that the
      scrummaster can effectively remove because of lack of skill,
      direction, or resources.

      In the first case I wish that Scrum teams more often had the courage
      to realize that scrummaster need not be a permanent role for an
      individual on a team. At some point I would expect a mature Agile team
      to realize that everyone is a facilitator/obstacle-remover and
      therefore it isn't special.

      For the second problem I think it is necessary to coach scrummasters
      to more effectively identify where they can provide help and when to
      ask for it themselves. It also behooves an organization that wants to
      reap the benefits of Agile teams to make available resources (Such as
      coaching or other expertise) for the scrummaster to turn to.

      On Thu, Jun 10, 2010 at 2:37 PM, John Goodsen <jgoodsen@...> wrote:
      >
      >
      >
      > On Thu, Jun 10, 2010 at 5:17 PM, woynam <woyna@...> wrote:
      >>
      >> Huh? The team is responsible for the technical practices, not the SM. The SM's role is to ensure that the *process* is being followed, not that the product is technically sound. If the process is being followed, it will be rather apparent if the technical foundation is getting the job done.
      >>
      >> Whether it's a full time job really depends on the team, and the impediments. If the team is well-versed in the process, then less time will be required coaching. However, a large number of impediments may still take up a lot of time.
      >>
      >
      >>
      >> There are plenty of coaches that haven't played professionally, and yet manage to lead their teams to victory. I'm a golfer. How many tournaments have Butch Harmon, and Hank Haney won? Too few to count.
      >>
      > I didn't say they had to have a wall of trophies, but they damned well better know how to golf if I'm going to pay them to coach me.  A scrum master that doesn't know how to write software is of limited usefulness in my book.   I'll take a coach that knows how to code over a scrum master any day.  There aren't many around for everybody to have, so we've seen this role called Scrumaster become the crutch, and daree I say a ploy to sell certification training to people who often have no business being involved on a software project - at least the dozens of archealogically-challenged-just-got-my-certification-cuz-I-got-layed-off-managers that I've been running into the last couple years.
      >
      > ... and I realize I'm prolly trolling because this *is* a Scrum list ... and you know how I like to rile up the troops  :-)
      >
      > --
      > John Goodsen                 RADSoft / Better Software Faster
      > jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
      > http://www.radsoft.com          Ruby on Rails and Java Solutions
      >
      >
    • Adam Sroka
      I didn t really finish that thought: It is not necessary for scrummasters to be technical to be useful to a team if that team has obstacles that the
      Message 2 of 10 , Jun 10, 2010
      • 0 Attachment
        I didn't really finish that thought:

        It is not necessary for scrummasters to be technical to be useful to a
        team if that team has obstacles that the scrummaster can remove. It is
        necessary for teams that have newly adopted Agile to have technical
        advisers, because there are technical implications to working in
        smaller, faster increments.

        A technical coach is an important part of any successful Agile
        adoption, but other experts of various kinds are also useful, and a
        savvy scrummaster can be useful in identifying opportunities to direct
        those efforts to maximum effect. A scrummaster need not know too much
        about any particular aspect to do that, although being an effective
        leader (notice that I didn't say "manager") is vital.

        On Thu, Jun 10, 2010 at 2:47 PM, Adam Sroka <adam.sroka@...> wrote:
        > I have always been suspicious of Scrummasters. If there are a lot of
        > organizational obstacles and they are effective in removing them then
        > they are worth their weight in gold. However, there is a tendency to
        > devolve in one of two directions:
        >
        > 1) The team is highly effective and therefore the scrummaster role is
        > superfluous.
        >
        > 2) The obstacles that the team encounters are not of a kind that the
        > scrummaster can effectively remove because of lack of skill,
        > direction, or resources.
        >
        > In the first case I wish that Scrum teams more often had the courage
        > to realize that scrummaster need not be a permanent role for an
        > individual on a team. At some point I would expect a mature Agile team
        > to realize that everyone is a facilitator/obstacle-remover and
        > therefore it isn't special.
        >
        > For the second problem I think it is necessary to coach scrummasters
        > to more effectively identify where they can provide help and when to
        > ask for it themselves. It also behooves an organization that wants to
        > reap the benefits of Agile teams to make available resources (Such as
        > coaching or other expertise) for the scrummaster to turn to.
        >
        > On Thu, Jun 10, 2010 at 2:37 PM, John Goodsen <jgoodsen@...> wrote:
        >>
        >>
        >>
        >> On Thu, Jun 10, 2010 at 5:17 PM, woynam <woyna@...> wrote:
        >>>
        >>> Huh? The team is responsible for the technical practices, not the SM. The SM's role is to ensure that the *process* is being followed, not that the product is technically sound. If the process is being followed, it will be rather apparent if the technical foundation is getting the job done.
        >>>
        >>> Whether it's a full time job really depends on the team, and the impediments. If the team is well-versed in the process, then less time will be required coaching. However, a large number of impediments may still take up a lot of time.
        >>>
        >>
        >>>
        >>> There are plenty of coaches that haven't played professionally, and yet manage to lead their teams to victory. I'm a golfer. How many tournaments have Butch Harmon, and Hank Haney won? Too few to count.
        >>>
        >> I didn't say they had to have a wall of trophies, but they damned well better know how to golf if I'm going to pay them to coach me.  A scrum master that doesn't know how to write software is of limited usefulness in my book.   I'll take a coach that knows how to code over a scrum master any day.  There aren't many around for everybody to have, so we've seen this role called Scrumaster become the crutch, and daree I say a ploy to sell certification training to people who often have no business being involved on a software project - at least the dozens of archealogically-challenged-just-got-my-certification-cuz-I-got-layed-off-managers that I've been running into the last couple years.
        >>
        >> ... and I realize I'm prolly trolling because this *is* a Scrum list ... and you know how I like to rile up the troops  :-)
        >>
        >> --
        >> John Goodsen                 RADSoft / Better Software Faster
        >> jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
        >> http://www.radsoft.com          Ruby on Rails and Java Solutions
        >>
        >>
        >
      • Ron Jeffries
        ... Yes ... what I d ask is whether what you re doing is likely to get you what you want ... whatever that is. Ron Jeffries www.XProgramming.com
        Message 3 of 10 , Jun 10, 2010
        • 0 Attachment
          Hello, John. On Thursday, June 10, 2010, at 5:37:23 PM, you wrote:

          > ... and I realize I'm prolly trolling because this *is* a Scrum list ... and
          > you know how I like to rile up the troops :-)

          Yes ... what I'd ask is whether what you're doing is likely to get
          you what you want ... whatever that is.

          Ron Jeffries
          www.XProgramming.com
          www.xprogramming.com/blog
          I must create a system, or be enslaved by another man's;
          I will not reason and compare; my business is to create. --William Blake
        • John Goodsen
          yeah I think so. whatever it was ... :-) ... -- John Goodsen RADSoft / Better Software Faster jgoodsen@radsoft.com
          Message 4 of 10 , Jun 10, 2010
          • 0 Attachment
            yeah I think so. whatever it was ... :-)

            On Thu, Jun 10, 2010 at 6:15 PM, Ron Jeffries <ronjeffries@...> wrote:
            Hello, John.  On Thursday, June 10, 2010, at 5:37:23 PM, you wrote:

            > ... and I realize I'm prolly trolling because this *is* a Scrum list ... and
            > you know how I like to rile up the troops  :-)

            Yes ... what I'd ask is whether what you're doing is likely to get
            you what you want ... whatever that is.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            I must create a system, or be enslaved by another man's;
            I will not reason and compare; my business is to create. --William Blake



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

            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/




            --
            John Goodsen                 RADSoft / Better Software Faster
            jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
            http://www.radsoft.com          Ruby on Rails and Java Solutions
          • Hariprakash Agrawal
            Hi Pooja / All, I agree with John but same time, its very person dependent. If team is already in to agile or scrum (not scum) for some time and there is not
            Message 5 of 10 , Jun 10, 2010
            • 0 Attachment
              Hi Pooja / All,

              I agree with John but same time, its very person dependent. If team is already in to agile or scrum (not scum) for some time and there is not much impediments than its better to have person technically sound and if person is good technically and helps others, its highly likely that person will have good respect among team members which is essential for such roles.

              In my opinion, any day, soft skills wins over technical skills when it comes to leadership roles, like, SMs, coaches, managers etc. Hence if person is only good technically but does not share/help others than it would be a bad idea to have such member in team itself, forget about scrum master.

              I am currently coaching 2 teams on agile (it is mix of Scrum and XP practices plus our collective experience) and for initial role-out, we have identified SMs who are good in both (soft + hard skills) but we are not always lucky to get such individuals. When I am coaching these new things, team has lots of suspicious/doubts/queries and sometimes, my life is easier if SM pitches in to explain things and there are 2 influential votes on one side.

              --
              Regards,
              Hariprakash Agrawal (Hari),
              http://opcord.com - OpCord provides process consulting, trainings and testing services for organizations. For individuals and corporate trainings/certifications on Agile, CMMi, Risk Management, Software Engineering, Six Sigma, Testing etc, please check our schedule at http://opcord.com/index.php/calendar.html.
              About me: http://www.linkedin.com/in/hariprakash


              On Fri, Jun 11, 2010 at 3:28 AM, Adam Sroka <adam.sroka@...> wrote:
              I didn't really finish that thought:

              It is not necessary for scrummasters to be technical to be useful to a
              team if that team has obstacles that the scrummaster can remove. It is
              necessary for teams that have newly adopted Agile to have technical
              advisers, because there are technical implications to working in
              smaller, faster increments.

              A technical coach is an important part of any successful Agile
              adoption, but other experts of various kinds are also useful, and a
              savvy scrummaster can be useful in identifying opportunities to direct
              those efforts to maximum effect. A scrummaster need not know too much
              about any particular aspect to do that, although being an effective
              leader (notice that I didn't say "manager") is vital.

              On Thu, Jun 10, 2010 at 2:47 PM, Adam Sroka <adam.sroka@...> wrote:
              > I have always been suspicious of Scrummasters. If there are a lot of
              > organizational obstacles and they are effective in removing them then
              > they are worth their weight in gold. However, there is a tendency to
              > devolve in one of two directions:
              >
              > 1) The team is highly effective and therefore the scrummaster role is
              > superfluous.
              >
              > 2) The obstacles that the team encounters are not of a kind that the
              > scrummaster can effectively remove because of lack of skill,
              > direction, or resources.
              >
              > In the first case I wish that Scrum teams more often had the courage
              > to realize that scrummaster need not be a permanent role for an
              > individual on a team. At some point I would expect a mature Agile team
              > to realize that everyone is a facilitator/obstacle-remover and
              > therefore it isn't special.
              >
              > For the second problem I think it is necessary to coach scrummasters
              > to more effectively identify where they can provide help and when to
              > ask for it themselves. It also behooves an organization that wants to
              > reap the benefits of Agile teams to make available resources (Such as
              > coaching or other expertise) for the scrummaster to turn to.
              >
              > On Thu, Jun 10, 2010 at 2:37 PM, John Goodsen <jgoodsen@...> wrote:
              >>
              >>
              >>
              >> On Thu, Jun 10, 2010 at 5:17 PM, woynam <woyna@...> wrote:
              >>>
              >>> Huh? The team is responsible for the technical practices, not the SM. The SM's role is to ensure that the *process* is being followed, not that the product is technically sound. If the process is being followed, it will be rather apparent if the technical foundation is getting the job done.
              >>>
              >>> Whether it's a full time job really depends on the team, and the impediments. If the team is well-versed in the process, then less time will be required coaching. However, a large number of impediments may still take up a lot of time.
              >>>
              >>
              >>>
              >>> There are plenty of coaches that haven't played professionally, and yet manage to lead their teams to victory. I'm a golfer. How many tournaments have Butch Harmon, and Hank Haney won? Too few to count.
              >>>
              >> I didn't say they had to have a wall of trophies, but they damned well better know how to golf if I'm going to pay them to coach me.  A scrum master that doesn't know how to write software is of limited usefulness in my book.   I'll take a coach that knows how to code over a scrum master any day.  There aren't many around for everybody to have, so we've seen this role called Scrumaster become the crutch, and daree I say a ploy to sell certification training to people who often have no business being involved on a software project - at least the dozens of archealogically-challenged-just-got-my-certification-cuz-I-got-layed-off-managers that I've been running into the last couple years.
              >>
              >> ... and I realize I'm prolly trolling because this *is* a Scrum list ... and you know how I like to rile up the troops  :-)
              >>
              >> --
              >> John Goodsen                 RADSoft / Better Software Faster
              >> jgoodsen@...            Lean/Agile/XP/Scrum Coaching and Training
              >> http://www.radsoft.com          Ruby on Rails and Java Solutions
              >>
              >>
              >


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

              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/



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