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

Who chooses the team?

Expand Messages
  • james pullicino
    Who chooses the team? How much of a say should the scrum master have in things like team size and team members? A bit of an open ended question, but maybe
    Message 1 of 4 , Mar 7 5:08 AM
      Who chooses the team? How much of a say should the scrum master have in things like team size and team members?

      A bit of an open ended question, but maybe someone can share some experiences?

      cheers,
      James Pullicino
      BBC


      To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.
    • Schiel, James (MED US)
      James, my organization considered a number of different methods in the selection and building of teams. There s a whole spectrum of possibilities. I ll outline
      Message 2 of 4 , Mar 7 6:40 PM
        James,
         
        my organization considered a number of different methods in the selection and building of teams. There's a whole spectrum of possibilities. I'll outline a few:
         
        1) Manager's Choice - the management decides what teams they need, who's going to be on it, and who's going to be the Scrum Master on each team. Frankly, there's nothing terrible about this option. Management often has a good handle on how many teams they need and who has what skills and aspirations. In many instances, this is an acceptible way to get a lot of new teams created simultaneously. The arrangement of teams can then be adjusted over time.
         
        2) The Draft - the Product Owners, already identified, pick their teams from the available employee pool.  As for the Scrum Master, this can be decided by the team or by the Product Owner -- but hopefully they are selecting properly trained employees to be the Scrum Master. The upside of this method is that, as each team is formed, the new members of the team help the Product Owner select the next team member. You often get a well balanced team of individuals that will work well together. The downside is that you often get teams of people that simply like to work together rather than having the right balance of skills. You also have the problem of having employees picked "last" and the morale problems that this entails.
         
        3) The Sign-Up - management and product owners decide what teams they need and then post the team's charters and backlog. Employees are invited to a meeting where each team's charter and backlog are explained. Then, the employees are allowed an opportunity to sign up for the team that they want to be a part of. This has the advantage of turning more of the control of the project over to the employees, but does have the downside of having the "cool" teams and the "blah" teams. Everyone wants to get on the cool teams, but knowing they have to sign up for something, some of the late deciders end up on the "blah" teams -- unhappy and unmotivated.
         
        4) Chaos (not necessarily a bad thing) - similar to "the sign-up," but instead of having management and product owners decide what teams they need, the project requirements are explained and the employees are charged with self-organizing around the requirements. They determine what teams they need and how they staff the teams. This is a very motivating method, but not good for large and/or complex projects.
         
        From the standpoint of team size -- I generally hold teams to 5-9 members. Teams with larger potential backlogs get the upper end. Teams with smaller backlogs and/or lower priority items get the smaller sizes.
         
        All that said, if you're just starting with Scrum, I'd recommend going with "Manager's Choice" for two reasons. First, if you have a good management team, they will know which employees have the necessary skills (interpersonal, professional, and technical) to work in specific teams. Second, the shift from command-and-control to truly agile, Scrum-driven teams is often a a difficult transition for employees to make on day one. They need support while the reins of empowerment are carefully moved from management to them.
         
        Others on this list will add to my scenarios and even make different suggestions.  Pay attention to all of them, because each scenario will come with the environmental characteristics that will make a specific scenario either fail or succeed.
         
        Good luck!
         
        Jim Schiel
        Siemens Medical Solutions


        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of james pullicino
        Sent: Tuesday, March 07, 2006 8:09 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: [scrumdevelopment] Who chooses the team?

        Who chooses the team? How much of a say should the scrum master have in things like team size and team members?

        A bit of an open ended question, but maybe someone can share some experiences?

        cheers,
        James Pullicino
        BBC


        To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre.

        -------------------------------------------------------------------------------
        This message and any included attachments are from Siemens Medical Solutions
        USA, Inc. and are intended only for the addressee(s).
        The information contained herein may include trade secrets or privileged or
        otherwise confidential information. Unauthorized review, forwarding, printing,
        copying, distributing, or using such information is strictly prohibited and may
        be unlawful. If you received this message in error, or have reason to believe
        you are not authorized to receive it, please promptly delete this message and
        notify the sender by e-mail with a copy to Central.SecurityOffice@...

        Thank you
      • icmbnar
        An approach that I have found useful is to begin interviewing the product owner and ask who they have worked with and who they think would make good team
        Message 3 of 4 , Mar 7 6:50 PM
          An approach that I have found useful is to begin interviewing the
          product owner and ask who they have worked with and who they think
          would make good team members. The next step is to interview those
          folks and ask who they have worked with, feel they need on the
          project, and feel would make good team members. This process of
          interviewing and self selection typicall emerges a solid core of
          folks who have "called each other's numbers". The Scrum Master's
          job is to look balance the technical needs of the project with
          overall team size and "fit" of various team members.

          Once the team has moved out of the storming phase, I find it usefule
          to hand over the reigns to the team and step into a servant role.
          Teams will typically morph for both the right and wrong reasons and
          having the folks doing the work 'self organize' seems to be the best
          way to handle those changes.

          Mark Pushinsky

          --- In scrumdevelopment@yahoogroups.com, "Schiel, James (MED US)"
          <james.schiel@...> wrote:
          >
          >
          > James,
          >
          > my organization considered a number of different methods in the
          > selection and building of teams. There's a whole spectrum of
          > possibilities. I'll outline a few:
          >
          > 1) Manager's Choice - the management decides what teams they need,
          who's
          > going to be on it, and who's going to be the Scrum Master on each
          team.
          > Frankly, there's nothing terrible about this option. Management
          often
          > has a good handle on how many teams they need and who has what
          skills
          > and aspirations. In many instances, this is an acceptible way to
          get a
          > lot of new teams created simultaneously. The arrangement of teams
          can
          > then be adjusted over time.
          >
          > 2) The Draft - the Product Owners, already identified, pick their
          teams
          > from the available employee pool. As for the Scrum Master, this
          can be
          > decided by the team or by the Product Owner -- but hopefully they
          are
          > selecting properly trained employees to be the Scrum Master. The
          upside
          > of this method is that, as each team is formed, the new members of
          the
          > team help the Product Owner select the next team member. You often
          get a
          > well balanced team of individuals that will work well together. The
          > downside is that you often get teams of people that simply like to
          work
          > together rather than having the right balance of skills. You also
          have
          > the problem of having employees picked "last" and the morale
          problems
          > that this entails.
          >
          > 3) The Sign-Up - management and product owners decide what teams
          they
          > need and then post the team's charters and backlog. Employees are
          > invited to a meeting where each team's charter and backlog are
          > explained. Then, the employees are allowed an opportunity to sign
          up for
          > the team that they want to be a part of. This has the advantage of
          > turning more of the control of the project over to the employees,
          but
          > does have the downside of having the "cool" teams and the "blah"
          teams.
          > Everyone wants to get on the cool teams, but knowing they have to
          sign
          > up for something, some of the late deciders end up on the "blah"
          teams
          > -- unhappy and unmotivated.
          >
          > 4) Chaos (not necessarily a bad thing) - similar to "the sign-up,"
          but
          > instead of having management and product owners decide what teams
          they
          > need, the project requirements are explained and the employees are
          > charged with self-organizing around the requirements. They
          determine
          > what teams they need and how they staff the teams. This is a very
          > motivating method, but not good for large and/or complex projects.
          >
          > From the standpoint of team size -- I generally hold teams to 5-9
          > members. Teams with larger potential backlogs get the upper end.
          Teams
          > with smaller backlogs and/or lower priority items get the smaller
          sizes.
          >
          > All that said, if you're just starting with Scrum, I'd recommend
          going
          > with "Manager's Choice" for two reasons. First, if you have a good
          > management team, they will know which employees have the necessary
          > skills (interpersonal, professional, and technical) to work in
          specific
          > teams. Second, the shift from command-and-control to truly agile,
          > Scrum-driven teams is often a a difficult transition for employees
          to
          > make on day one. They need support while the reins of empowerment
          are
          > carefully moved from management to them.
          >
          > Others on this list will add to my scenarios and even make
          different
          > suggestions. Pay attention to all of them, because each scenario
          will
          > come with the environmental characteristics that will make a
          specific
          > scenario either fail or succeed.
          >
          > Good luck!
          >
          > Jim Schiel
          > Siemens Medical Solutions
          >
          > ________________________________
          >
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of james
          pullicino
          > Sent: Tuesday, March 07, 2006 8:09 AM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: [scrumdevelopment] Who chooses the team?
          >
          >
          > Who chooses the team? How much of a say should the scrum master
          have in
          > things like team size and team members?
          >
          > A bit of an open ended question, but maybe someone can share some
          > experiences?
          >
          > cheers,
          > James Pullicino
          > BBC
          >
          > ________________________________
          >
          > To help you stay safe and secure online, we've developed the all
          new
          > Yahoo! Security Centre
          >
          <http://us.rd.yahoo.com/mail/uk/taglines/default/security_centre/*htt
          p:/
          > /uk.security.yahoo.com/> .
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to:
          > scrumdevelopment-unsubscribe@...
          >
          >
          >
          > ________________________________
          >
          > YAHOO! GROUPS LINKS
          >
          >
          >
          > * Visit your group "scrumdevelopment
          > <http://groups.yahoo.com/group/scrumdevelopment> " on the web.
          >
          > * To unsubscribe from this group, send an email to:
          > scrumdevelopment-unsubscribe@yahoogroups.com
          > <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?
          subject=Unsubscribe
          > >
          >
          > * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
          > Service <http://docs.yahoo.com/info/terms/> .
          >
          >
          > ________________________________
          >
          >
          >
          >
          > -------------------------------------------------------------------
          ------------
          > This message and any included attachments are from Siemens Medical
          Solutions
          > USA, Inc. and are intended only for the addressee(s).
          > The information contained herein may include trade secrets or
          privileged or
          > otherwise confidential information. Unauthorized review,
          forwarding, printing,
          > copying, distributing, or using such information is strictly
          prohibited and may
          > be unlawful. If you received this message in error, or have
          reason to believe
          > you are not authorized to receive it, please promptly delete this
          message and
          > notify the sender by e-mail with a copy to
          Central.SecurityOffice@...
          >
          > Thank you
          >
        • Doug Swartz
          ... We often use a variant of the sign up , we call the stickies . After management and product owners decide what teams are needed for the next period, we
          Message 4 of 4 , Mar 7 8:46 PM
            Tuesday, March 07, 2006, 8:40:15 PM, Schiel, James (MED US) wrote:

            > 3) The Sign-Up - management and product owners decide what teams they
            > need and then post the team's charters and backlog. Employees are
            > invited to a meeting where each team's charter and backlog are
            > explained. Then, the employees are allowed an opportunity to sign up for
            > the team that they want to be a part of. This has the advantage of
            > turning more of the control of the project over to the employees, but
            > does have the downside of having the "cool" teams and the "blah" teams.
            > Everyone wants to get on the cool teams, but knowing they have to sign
            > up for something, some of the late deciders end up on the "blah" teams
            > -- unhappy and unmotivated.


            We often use a variant of "the sign up", we call "the
            stickies". After management and product owners decide what
            teams are needed for the next period, we put up a large sheet
            of paper on the wall for each team. On the top part of the
            sheet, we place a post-it note for each of the people
            currently on the team (a newly forming team would be empty).

            We draw a line across the middle of the sheet. On the bottom
            of the sheet we write the number of people we need going
            forward on that team by role e.g. (8 developers, 2 testers, 1
            project manager).

            We ask each person to:
            1. Write your name on two post-it notes.
            2. On one of the notes add the number 1, on the other write the
            number 2.
            3. Place the post-it note with the number one on your first
            choice of team.
            3. Place the post-it note with the number 2 on your second
            choice of team.

            We always discuss the need to maintain a level of continuity
            on ongoing teams, and our need to optimize the performance of
            the whole organization as opposed to any particular team. We
            promise to absolutely do our best to get each person on either
            their first or second choice of teams. If we are unable to do
            so because we feel we need a particular person's skills on a
            team they didn't select, we promise to talk with that person
            before making the decision.

            We usually allow a 24 to 48 hour period for people to indicate
            their passion. (An early iteration of this exercise used
            purple post-it notes to indicate passion for a team).

            Management and senior technical leadership take the sheets and
            figure out how we think we can best meet both the
            organization's needs and the individuals' desires. It's
            amazing how we seldom need to talk to more than one or two
            people about working on a team which wasn't choice one or
            two.

            We do this exercise between two and four times a year. Our
            organization has about 60 people.


            --

            Doug Swartz
            daswartz@...
          Your message has been successfully submitted and would be delivered to recipients shortly.