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

Reorganizing / Scaling Scrum Teams

Expand Messages
  • robsherman_cfdev
    Hi, I helped introduce Scrum in my company and we originally decided that Scrum teams would be broken down into 3 areas: Operations, Development & Marketing.
    Message 1 of 11 , Sep 28, 2009
    • 0 Attachment
      Hi,
      I helped introduce Scrum in my company and we originally decided that Scrum teams would be broken down into 3 areas: Operations, Development & Marketing. Neither team had very many members and the logical report-to supervisor became the Product Owner of that team (all went to training).

      Since our Marketing person is no longer with our company, the business owner is trying to make a case to break up the scrum teams into specific project Scrum teams. So where we normally had a single development Scrum team (for example) of 7 people (largest group) all working on various projects (not all dependent on each developer), he would like to break that up into several (say 5 or 6) teams all specifically focused on a single project.

      I will say that since we implemented Scrum here, that we've employed probably 5 or 6 more people, so we're definitely growing.

      While I can admire the project based-model, it seems to only be useful to me if we had larger groups, of lengthy projects without a lot of cross-over from project-to-project. Am I off-base here? Is what he is proposing a good thing? How do we know what is the best way to compose a Scrum team?

      - Rob
    • Michael Vizdos
      Ask the team. Keep it simple. Keep it going! - mike vizdos www.implementingscrum.com On Mon, Sep 28, 2009 at 10:07 PM, robsherman_cfdev
      Message 2 of 11 , Sep 28, 2009
      • 0 Attachment
        Ask the team.

        Keep it simple.

        Keep it going!

        - mike vizdos

        On Mon, Sep 28, 2009 at 10:07 PM, robsherman_cfdev <rob.sherman@...> wrote:
         

        Hi,
        I helped introduce Scrum in my company and we originally decided that Scrum teams would be broken down into 3 areas: Operations, Development & Marketing. Neither team had very many members and the logical report-to supervisor became the Product Owner of that team (all went to training).

        Since our Marketing person is no longer with our company, the business owner is trying to make a case to break up the scrum teams into specific project Scrum teams. So where we normally had a single development Scrum team (for example) of 7 people (largest group) all working on various projects (not all dependent on each developer), he would like to break that up into several (say 5 or 6) teams all specifically focused on a single project.

        I will say that since we implemented Scrum here, that we've employed probably 5 or 6 more people, so we're definitely growing.

        While I can admire the project based-model, it seems to only be useful to me if we had larger groups, of lengthy projects without a lot of cross-over from project-to-project. Am I off-base here? Is what he is proposing a good thing? How do we know what is the best way to compose a Scrum team?

        - Rob


      • Michael James
        Too much we don t know here to *prescribe* a solution. A bunch of specialized teams with micromanaged interfaces probably isn t very agile. There s evidence
        Message 3 of 11 , Sep 28, 2009
        • 0 Attachment
          Too much we don't know here to *prescribe* a solution. A bunch of
          specialized teams with micromanaged interfaces probably isn't very
          agile.

          There's evidence it takes a year for a team to really hit its stride,
          so you might reexamine some of the legacy ideas about project-based
          resource management. A great team can handle a greater variety of
          work than people seem to realize.

          IMO the best scaling book is _Scaling Lean & Agile Development_ by
          Craig Larman and Bas Vodde.

          --mj


          On Sep 28, 2009, at 5:07 PM, robsherman_cfdev wrote:

          > Hi,
          > I helped introduce Scrum in my company and we originally decided
          > that Scrum teams would be broken down into 3 areas: Operations,
          > Development & Marketing. Neither team had very many members and the
          > logical report-to supervisor became the Product Owner of that team
          > (all went to training).
          >
          > Since our Marketing person is no longer with our company, the
          > business owner is trying to make a case to break up the scrum teams
          > into specific project Scrum teams. So where we normally had a
          > single development Scrum team (for example) of 7 people (largest
          > group) all working on various projects (not all dependent on each
          > developer), he would like to break that up into several (say 5 or 6)
          > teams all specifically focused on a single project.
          >
          > I will say that since we implemented Scrum here, that we've employed
          > probably 5 or 6 more people, so we're definitely growing.
          >
          > While I can admire the project based-model, it seems to only be
          > useful to me if we had larger groups, of lengthy projects without a
          > lot of cross-over from project-to-project. Am I off-base here? Is
          > what he is proposing a good thing? How do we know what is the best
          > way to compose a Scrum team?
          >
          > - Rob
          >
          >
          >
          > ------------------------------------
          >
          > To Post a message, send it to: scrumdevelopment@...
          > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
          > ! Groups Links
          >
          >
          >
        • robsherman_cfdev
          Thanks for the quick responses (both Michaels) I d love to give more info if it helps get feedback. One piece I m probably neglecting is that most of these
          Message 4 of 11 , Sep 28, 2009
          • 0 Attachment
            Thanks for the quick responses (both Michaels)

            I'd love to give more info if it helps get feedback. One piece I'm probably neglecting is that most of these projects to me are very small-scale able to be accomplished in a few weeks time. Not everyone that would comprise a Scrum team has had CSM training so one fear I have is that composing a team like this may mean an awful lot of 'storming' while people figure out who the PO and SM will be for that team.

            Another concern, I fear that the Business Owner is using this ploy as a means of having these project teams report up to him rather than use his management staff effectively. Our Business Owner is a micro-manager so this would feed that bad habit.

            I kind of feel like we're on the brink of breaking Scrum and trying to change it to meet some other need of the Business Owner - rather than do this the right way.

            I'm happy to admit I could be wrong but would love more feedback..

            - Rob
          • mike.dwyer1@comcast.net
            I am not sure how either approach addressed value. Perhaps an option can be found if you were to look at the straightest line your organization can provide to
            Message 5 of 11 , Sep 28, 2009
            • 0 Attachment
              I am not sure how either approach addressed value. Perhaps an option can be found if you were to look at the straightest line your organization can provide to link the customer to the value they want you to provide.

              Mike Dwyer

              Sent via BlackBerry by AT&T


              From: "robsherman_cfdev"
              Date: Mon, 28 Sep 2009 21:07:09 -0000
              To: <scrumdevelopment@yahoogroups.com>
              Subject: [scrumdevelopment] Reorganizing / Scaling Scrum Teams

               

              Hi,
              I helped introduce Scrum in my company and we originally decided that Scrum teams would be broken down into 3 areas: Operations, Development & Marketing. Neither team had very many members and the logical report-to supervisor became the Product Owner of that team (all went to training).

              Since our Marketing person is no longer with our company, the business owner is trying to make a case to break up the scrum teams into specific project Scrum teams. So where we normally had a single development Scrum team (for example) of 7 people (largest group) all working on various projects (not all dependent on each developer), he would like to break that up into several (say 5 or 6) teams all specifically focused on a single project.

              I will say that since we implemented Scrum here, that we've employed probably 5 or 6 more people, so we're definitely growing.

              While I can admire the project based-model, it seems to only be useful to me if we had larger groups, of lengthy projects without a lot of cross-over from project-to-project. Am I off-base here? Is what he is proposing a good thing? How do we know what is the best way to compose a Scrum team?

              - Rob

            • Michael James
              Do you want us to tell you what you already know? Sounds like you understand Scrum principles. As Mike Vizdos asked, what do the people *doing* the work
              Message 6 of 11 , Sep 28, 2009
              • 0 Attachment
                Do you want us to tell you what you already know? Sounds like you
                understand Scrum principles. As Mike Vizdos asked, what do the people
                *doing* the work think?

                It is possible for a company your size to have general purpose
                (learning) teams coordinating with each other rather than waiting for
                some authority to do it for them. This will give the business more
                value in the long run.

                So how can you create an environment fostering that, leaving room for
                leadership to emerge? Can you redirect the micromanager's attention
                to prioritizing work so the teams can work out the "how"?

                --mj


                On 9/28/09, robsherman_cfdev <rob.sherman@...> wrote:
                > Thanks for the quick responses (both Michaels)
                >
                > I'd love to give more info if it helps get feedback. One piece I'm probably
                > neglecting is that most of these projects to me are very small-scale able to
                > be accomplished in a few weeks time. Not everyone that would comprise a
                > Scrum team has had CSM training so one fear I have is that composing a team
                > like this may mean an awful lot of 'storming' while people figure out who
                > the PO and SM will be for that team.
                >
                > Another concern, I fear that the Business Owner is using this ploy as a
                > means of having these project teams report up to him rather than use his
                > management staff effectively. Our Business Owner is a micro-manager so this
                > would feed that bad habit.
                >
                > I kind of feel like we're on the brink of breaking Scrum and trying to
                > change it to meet some other need of the Business Owner - rather than do
                > this the right way.
                >
                > I'm happy to admit I could be wrong but would love more feedback..
                >
                > - Rob
                >
                >
                >
                > ------------------------------------
                >
                > To Post a message, send it to: scrumdevelopment@...
                > To Unsubscribe, send a blank message to:
                > scrumdevelopment-unsubscribe@...! Groups Links
                >
                >
                >
                >

                --
                Sent from my mobile device
              • Rob Sherman
                Hi Mike, I m not sure I understand that completely. Our company provides a phone service (monthly charge, per minute rates), with website add-ons I ll call
                Message 7 of 11 , Sep 28, 2009
                • 0 Attachment

                  Hi Mike,

                  I’m not sure I understand that completely.  Our company provides a phone service (monthly charge, per minute rates), with website “add-ons” I’ll call it, that are no additional cost to the customer – just more benefit of using the service.  I don’t think I know how to draw a line to link our customers to the value of the project (I’m assuming) that is being requested to a single specialized team. 

                   

                   

                  Sincerely,

                   

                  Rob

                   

                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of mike.dwyer1@...
                  Sent: Monday, September 28, 2009 2:52 PM
                  To: Scrumdevelopment
                  Subject: Re: [scrumdevelopment] Reorganizing / Scaling Scrum Teams

                   

                   

                  I am not sure how either approach addressed value. Perhaps an option can be found if you were to look at the straightest line your organization can provide to link the customer to the value they want you to provide.

                  Mike Dwyer

                  Sent via BlackBerry by AT&T

                • Rob Sherman
                  I will ask team members what they think - good idea, but, the Business Owner has already said that we may not have a voice here since this is the way he is
                  Message 8 of 11 , Sep 28, 2009
                  • 0 Attachment

                    I will ask team members what they think – good idea, but, the Business Owner has already said that we may not have a voice here since this is the way he is leaning.

                     

                    We have at most 20-25 employees total within our organization.  5 of those don’t really participate in Scrum, they are customer service reps / inside sales people.  With 20 people left what you would call general purpose teams we gave them purposes:  Dev, Ops and Marketing.  One problem we had, one team knowing what was going on with the other – we created a PO Team, taking each PO from the three teams and report up to the Business Owner.  Generally this has worked fairly well.

                     

                    I like the idea of general purpose teams:  Team A, B, C but then do we run the risk of having people in a team that don’t belong there if the ‘project’ of the team is outside certain members experience?  I can see how we can invite and have other team members, jumping teams, etc but this does sound closer to what our Business Owner wants as “project scrum teams”.

                     

                    The micromanager is self-admitted as such, there is no way in such a small company to redirect his attention away from the ‘how’ that things get done.  As Dev Manager, I certainly try..

                     

                     

                    Sincerely,

                     

                    Rob

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
                    Sent: Monday, September 28, 2009 2:57 PM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Reorganizing / Scaling Scrum Teams

                     

                     

                    Do you want us to tell you what you already know? Sounds like you
                    understand Scrum principles. As Mike Vizdos asked, what do the people
                    *doing* the work think?

                    It is possible for a company your size to have general purpose
                    (learning) teams coordinating with each other rather than waiting for
                    some authority to do it for them. This will give the business more
                    value in the long run.

                    So how can you create an environment fostering that, leaving room for
                    leadership to emerge? Can you redirect the micromanager's attention
                    to prioritizing work so the teams can work out the "how"?

                    --mj

                  • Michael Vizdos
                    Hey. It all looks good on paper. Ask. Facilitate the conversations. You should be surprised by the answers you get collaboratively either way! Remember if it
                    Message 9 of 11 , Sep 28, 2009
                    • 0 Attachment
                      Hey.

                      It all looks good on paper.

                      Ask.

                      Facilitate the conversations.

                      You should be surprised by the answers you get collaboratively either way!

                      Remember if it is not "right" -- the team can inspect and adapt.

                      Thank you,

                      - Mike Vizdos

                      On Mon, Sep 28, 2009 at 11:32 PM, Rob Sherman <rob.sherman@...> wrote:
                       

                      I will ask team members what they think – good idea, but, the Business Owner has already said that we may not have a voice here since this is the way he is leaning.

                       

                      We have at most 20-25 employees total within our organization.  5 of those don’t really participate in Scrum, they are customer service reps / inside sales people.  With 20 people left what you would call general purpose teams we gave them purposes:  Dev, Ops and Marketing.  One problem we had, one team knowing what was going on with the other – we created a PO Team, taking each PO from the three teams and report up to the Business Owner.  Generally this has worked fairly well.

                       

                      I like the idea of general purpose teams:  Team A, B, C but then do we run the risk of having people in a team that don’t belong there if the ‘project’ of the team is outside certain members experience?  I can see how we can invite and have other team members, jumping teams, etc but this does sound closer to what our Business Owner wants as “project scrum teams”.

                       

                      The micromanager is self-admitted as such, there is no way in such a small company to redirect his attention away from the ‘how’ that things get done.  As Dev Manager, I certainly try..

                       

                       

                      Sincerely,

                       

                      Rob

                       

                      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
                      Sent: Monday, September 28, 2009 2:57 PM
                      To: scrumdevelopment@yahoogroups.com


                      Subject: Re: [scrumdevelopment] Reorganizing / Scaling Scrum Teams

                       

                       

                      Do you want us to tell you what you already know? Sounds like you


                      understand Scrum principles. As Mike Vizdos asked, what do the people
                      *doing* the work think?

                      It is possible for a company your size to have general purpose
                      (learning) teams coordinating with each other rather than waiting for
                      some authority to do it for them. This will give the business more
                      value in the long run.

                      So how can you create an environment fostering that, leaving room for
                      leadership to emerge? Can you redirect the micromanager's attention
                      to prioritizing work so the teams can work out the "how"?

                      --mj


                    • Mauro Botelho
                      I just wrote a blog post about the subject :) http://www.e-botelho.com/ I think that the project based approach with floating team
                      Message 10 of 11 , Oct 4, 2009
                      • 0 Attachment
                        I just wrote a blog post about the subject :)


                        I think that the project based approach with floating team members is the wrong way to go. I'd strongly suggest keeping the teams together.

                        Mauro

                        On Mon, Sep 28, 2009 at 8:40 PM, Michael Vizdos <mvizdos@...> wrote:
                         

                        Hey.


                        It all looks good on paper.

                        Ask.

                        Facilitate the conversations.

                        You should be surprised by the answers you get collaboratively either way!

                        Remember if it is not "right" -- the team can inspect and adapt.

                        Thank you,

                        - Mike Vizdos

                        On Mon, Sep 28, 2009 at 11:32 PM, Rob Sherman <rob.sherman@...> wrote:
                         

                        I will ask team members what they think – good idea, but, the Business Owner has already said that we may not have a voice here since this is the way he is leaning.

                         

                        We have at most 20-25 employees total within our organization.  5 of those don’t really participate in Scrum, they are customer service reps / inside sales people.  With 20 people left what you would call general purpose teams we gave them purposes:  Dev, Ops and Marketing.  One problem we had, one team knowing what was going on with the other – we created a PO Team, taking each PO from the three teams and report up to the Business Owner.  Generally this has worked fairly well.

                         

                        I like the idea of general purpose teams:  Team A, B, C but then do we run the risk of having people in a team that don’t belong there if the ‘project’ of the team is outside certain members experience?  I can see how we can invite and have other team members, jumping teams, etc but this does sound closer to what our Business Owner wants as “project scrum teams”.

                         

                        The micromanager is self-admitted as such, there is no way in such a small company to redirect his attention away from the ‘how’ that things get done.  As Dev Manager, I certainly try..

                         

                         

                        Sincerely,

                         

                        Rob

                         

                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael James
                        Sent: Monday, September 28, 2009 2:57 PM
                        To: scrumdevelopment@yahoogroups.com


                        Subject: Re: [scrumdevelopment] Reorganizing / Scaling Scrum Teams

                         

                         

                        Do you want us to tell you what you already know? Sounds like you


                        understand Scrum principles. As Mike Vizdos asked, what do the people
                        *doing* the work think?

                        It is possible for a company your size to have general purpose
                        (learning) teams coordinating with each other rather than waiting for
                        some authority to do it for them. This will give the business more
                        value in the long run.

                        So how can you create an environment fostering that, leaving room for
                        leadership to emerge? Can you redirect the micromanager's attention
                        to prioritizing work so the teams can work out the "how"?

                        --mj



                      • Michael James
                        You re in good company then. Teams take time (like months or years) to reach their peak competence. They can handle a broader range of work than most people
                        Message 11 of 11 , Oct 4, 2009
                        • 0 Attachment
                          You're in good company then. Teams take time (like months or years)
                          to reach their peak competence. They can handle a broader range of
                          work than most people realize. "Resource managers" have been slow to
                          learn this.


                          On 10/4/09, Mauro Botelho <mabotelh@...> wrote:
                          > I just wrote a blog post about the subject :)
                          > http://www.e-botelho.com/
                          >
                          > <http://www.e-botelho.com/>I think that the project based approach with
                          > floating team members is the wrong way to go. I'd strongly suggest keeping
                          > the teams together.
                          >
                          > Mauro
                          >
                          > On Mon, Sep 28, 2009 at 8:40 PM, Michael Vizdos <mvizdos@...> wrote:
                          >
                          >>
                          >>
                          >> Hey.
                          >>
                          >> It all looks good on paper.
                          >>
                          >> Ask.
                          >>
                          >> Facilitate the conversations.
                          >>
                          >> You should be surprised by the answers you get collaboratively either way!
                          >>
                          >> Remember if it is not "right" -- the team can inspect and adapt.
                          >>
                          >> Thank you,
                          >>
                          >> - Mike Vizdos
                          >>
                          >> On Mon, Sep 28, 2009 at 11:32 PM, Rob Sherman <
                          >> rob.sherman@...> wrote:
                          >>
                          >>>
                          >>>
                          >>> I will ask team members what they think – good idea, but, the Business
                          >>> Owner has already said that we may not have a voice here since this is
                          >>> the
                          >>> way he is leaning.
                          >>>
                          >>>
                          >>>
                          >>> We have at most 20-25 employees total within our organization. 5 of
                          >>> those
                          >>> don’t really participate in Scrum, they are customer service reps /
                          >>> inside
                          >>> sales people. With 20 people left what you would call general purpose
                          >>> teams
                          >>> we gave them purposes: Dev, Ops and Marketing. One problem we had, one
                          >>> team knowing what was going on with the other – we created a PO Team,
                          >>> taking
                          >>> each PO from the three teams and report up to the Business Owner.
                          >>> Generally
                          >>> this has worked fairly well.
                          >>>
                          >>>
                          >>>
                          >>> I like the idea of general purpose teams: Team A, B, C but then do we
                          >>> run
                          >>> the risk of having people in a team that don’t belong there if the
                          >>> ‘project’
                          >>> of the team is outside certain members experience? I can see how we can
                          >>> invite and have other team members, jumping teams, etc but this does
                          >>> sound
                          >>> closer to what our Business Owner wants as “project scrum teams”.
                          >>>
                          >>>
                          >>>
                          >>> The micromanager is self-admitted as such, there is no way in such a
                          >>> small
                          >>> company to redirect his attention away from the ‘how’ that things get
                          >>> done.
                          >>> As Dev Manager, I certainly try..
                          >>>
                          >>>
                          >>>
                          >>>
                          >>>
                          >>> Sincerely,
                          >>>
                          >>>
                          >>>
                          >>> Rob
                          >>>
                          >>>
                          >>>
                          >>> *From:* scrumdevelopment@yahoogroups.com [mailto:
                          >>> scrumdevelopment@yahoogroups.com] *On Behalf Of *Michael James
                          >>> *Sent:* Monday, September 28, 2009 2:57 PM
                          >>> *To:* scrumdevelopment@yahoogroups.com
                          >>>
                          >>> *Subject:* Re: [scrumdevelopment] Reorganizing / Scaling Scrum Teams
                          >>>
                          >>>
                          >>>
                          >>>
                          >>>
                          >>> Do you want us to tell you what you already know? Sounds like you
                          >>>
                          >>> understand Scrum principles. As Mike Vizdos asked, what do the people
                          >>> *doing* the work think?
                          >>>
                          >>> It is possible for a company your size to have general purpose
                          >>> (learning) teams coordinating with each other rather than waiting for
                          >>> some authority to do it for them. This will give the business more
                          >>> value in the long run.
                          >>>
                          >>> So how can you create an environment fostering that, leaving room for
                          >>> leadership to emerge? Can you redirect the micromanager's attention
                          >>> to prioritizing work so the teams can work out the "how"?
                          >>>
                          >>> --mj
                          >>>
                          >>>
                          >>
                          >>
                          >

                          --
                          Sent from my mobile device
                        Your message has been successfully submitted and would be delivered to recipients shortly.