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

How many products in 1 team is too many?

Expand Messages
  • Derek M
    I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint.
    Message 1 of 16 , Aug 27 10:28 AM
      I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?
    • Cass Dalton
      Sounds to me like your organization has multi-tasking built into it, which is arguably anti-agile. It sounds like you are trying to make an agile team out of
      Message 2 of 16 , Aug 27 10:33 AM
        Sounds to me like your organization has multi-tasking built into it,
        which is arguably anti-agile. It sounds like you are trying to make
        an agile team out of a a matrix organization, which is going to have
        difficulties.

        Are these stories for 3-4 different products maintenance requests?
        (i.e. fix bug 27 in product 2, add small enhancement to product 3,
        etc) Or are there longer running projects for all 6 products, and
        those projects allocate some of their work to the matrixed resources
        on any given sprint?

        On 8/27/12, Derek M <dmahlitz@...> wrote:
        > I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team
        > supports 6 products and can be working stories for 3 - 5 of those any any
        > sprint. Anybody have experiences with this kind of team? Is this too many
        > products? should we split into 2 teams for better focus?
        >
        >
      • Flavius Ștef
        Hi Derek, I speculate that the context switching cost would be lower with two teams, and thus velocity higher. One possible counterargument would be that there
        Message 3 of 16 , Aug 27 11:05 AM
          Hi Derek,

          I speculate that the context switching cost would be lower with two teams, and thus velocity higher. One possible counterargument would be that there is only one person with a certain skill, so you'd have to address that in some way.

          But even after splitting, I would still try to reduce the number of products working on at the same time. Would it be possible to work on product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What about one sprint per product? What about one week sprints?

          Flavius

          On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
           

          I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?


        • Kevin Callahan
          How many product owners/managers are there? Who is prioritizing the work that the team is to do next? -kevin ... Kevin Callahan, CSP Scrum Master mobile:
          Message 4 of 16 , Aug 27 11:54 AM
            How many product owners/managers are there? Who is prioritizing the work that the team is to do next?

            -kevin

            On Aug 27, 2012, at 2:05 PM, Flavius Ștef wrote:

             

            Hi Derek,

            I speculate that the context switching cost would be lower with two teams, and thus velocity higher. One possible counterargument would be that there is only one person with a certain skill, so you'd have to address that in some way.

            But even after splitting, I would still try to reduce the number of products working on at the same time. Would it be possible to work on product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What about one sprint per product? What about one week sprints?

            Flavius

            On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
             

            I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?




            Kevin Callahan, CSP
            Scrum Master
            mobile: 207-691-2997
            AIM: kevmocal


          • Michael Vizdos
            What about working on the highest priority product at a time? And allow the team to figure out how to get it done and... Well... Try that? -mike Vizdos ... --
            Message 5 of 16 , Aug 27 1:45 PM
              What about working on the highest priority product at a time?

              And allow the team to figure out how to get it done and... Well... Try that?

              -mike Vizdos 

              On Monday, August 27, 2012, Flavius Ștef wrote:
               

              Hi Derek,

              I speculate that the context switching cost would be lower with two teams, and thus velocity higher. One possible counterargument would be that there is only one person with a certain skill, so you'd have to address that in some way.

              But even after splitting, I would still try to reduce the number of products working on at the same time. Would it be possible to work on product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What about one sprint per product? What about one week sprints?

              Flavius

              On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
               

              I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?




              --

              Thank you,

              - Mike Vizdos

              My site:      michaelvizdos.com
              Cartoons:   implementingscrum.com
              Twitter:       twitter.com/mvizdos
              Facebook:  facebook.com/vizdosenterprises
              Google+:    gplus.to/MichaelVizdos
              LinkedIn:    linkedin.com/in/mvizdos

              PS --> In my spare time I am also involved as the Executive Director with Gangplank Henrico.
                         
                          Learn more at:

                         www.GangPlankHenrico.org
                         facebook.com/GPHenrico
                         groups.google.com/group/gangplank-henrico
                         www.twitter.com/GPHenricoCty
                         www.meetup.com/GPHenrico
                 
                         www.whatisgangplank.com
                         www.gangplankhq.com
            • Adam Sroka
              Right, the ideal answer is one product for one team. That s how you actually get iteration happening in your iterative development. Product development is a
              Message 6 of 16 , Aug 27 2:44 PM
                Right, the ideal answer is one product for one team. That's how you actually get iteration happening in your iterative development. Product development is a very intensive process and it's not really a good idea to short change it. That said, it works well with really, really small teams of less than a handful. 

                Of course, the reality in your organization might not allow this, but you should recognize that spreading the team so thin is going to limit their effectiveness across all the products they touch. Mike's suggestion is a good stop gap. Do a Sprint (or two or three...) on one product, get to a comfortable stopping point, RELEASE, then switch to another one. Rinse, repeat. 

                On Mon, Aug 27, 2012 at 1:45 PM, Michael Vizdos <mvizdos@...> wrote:
                 

                What about working on the highest priority product at a time?


                And allow the team to figure out how to get it done and... Well... Try that?

                -mike Vizdos 


                On Monday, August 27, 2012, Flavius Ștef wrote:
                 

                Hi Derek,

                I speculate that the context switching cost would be lower with two teams, and thus velocity higher. One possible counterargument would be that there is only one person with a certain skill, so you'd have to address that in some way.

                But even after splitting, I would still try to reduce the number of products working on at the same time. Would it be possible to work on product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What about one sprint per product? What about one week sprints?

                Flavius

                On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
                 

                I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?




                --

                Thank you,

                - Mike Vizdos

                My site:      michaelvizdos.com
                Cartoons:   implementingscrum.com
                Twitter:       twitter.com/mvizdos
                Facebook:  facebook.com/vizdosenterprises
                Google+:    gplus.to/MichaelVizdos
                LinkedIn:    linkedin.com/in/mvizdos

                PS --> In my spare time I am also involved as the Executive Director with Gangplank Henrico.
                           
                            Learn more at:

                           www.GangPlankHenrico.org
                           facebook.com/GPHenrico
                           groups.google.com/group/gangplank-henrico
                           www.twitter.com/GPHenricoCty
                           www.meetup.com/GPHenrico
                   
                           www.whatisgangplank.com
                           www.gangplankhq.com


              • Derek M
                The products are all part of a suite that releases x times per year so we ve been working on priority order across all of them for the release. Another issue
                Message 7 of 16 , Aug 28 11:00 AM
                  The products are all part of a suite that releases x times per year so we've been working on priority order across all of them for the release. Another issue is that we have experts in each product and feet dragging to learn the whole suite as a team.

                  --- In scrumdevelopment@yahoogroups.com, Flavius Ștef <flavius.stef@...> wrote:
                  >
                  > Hi Derek,
                  >
                  > I speculate that the context switching cost would be lower with two teams,
                  > and thus velocity higher. One possible counterargument would be that there
                  > is only one person with a certain skill, so you'd have to address that in
                  > some way.
                  >
                  > But even after splitting, I would still try to reduce the number of
                  > products working on at the same time. Would it be possible to work on
                  > product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What
                  > about one sprint per product? What about one week sprints?
                  >
                  > Flavius
                  >
                  > On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
                  >
                  > > **
                  > >
                  > >
                  > > I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team
                  > > supports 6 products and can be working stories for 3 - 5 of those any any
                  > > sprint. Anybody have experiences with this kind of team? Is this too many
                  > > products? should we split into 2 teams for better focus?
                  > >
                  > >
                  > >
                  >
                • RonJeffries
                  Hi Derek, ... One approach I have used with people who don t want to branch out is to make it clear that I value versatility. Similarly with senior people who
                  Message 8 of 16 , Aug 28 11:03 AM
                    Hi Derek,

                    On Aug 28, 2012, at 2:00 PM, "Derek M" <dmahlitz@...> wrote:

                    The products are all part of a suite that releases x times per year so we've been working on priority order across all of them for the release.  Another issue is that we have experts in each product and feet dragging to learn the whole suite as a team.

                    One approach I have used with people who don't want to branch out is to make it clear that I value versatility. Similarly with senior people who don't want to help others, I make it clear that I am assessing them not just on their own productivity but on the group's productivity improvement.

                    When people know what the organization values, they will generally do what the organization values. When I see a team full of heroics, it tends to make me believe that no matter what management says, they actually value heroics.

                    Ron Jeffries
                    www.XProgramming.com
                    Sometimes I give myself admirable advice, but I am incapable of taking it.
                    -- Mary Wortley Montagu



                  • Adam Sroka
                    Hmmm... Do customers buy these products individually or do they buy the suite? Do they buy the suite and get different configurations based on how much they
                    Message 9 of 16 , Aug 28 11:11 AM
                      Hmmm... Do customers buy these products individually or do they buy the suite? Do they buy the suite and get different configurations based on how much they pay and/or their particular usage? Perhaps you actually have one product. This might be a Conway's Law problem. 

                      Could you elaborate on "experts... feet dragging..." Is this about turf or something else? You might want to ask those experts some questions to uncover their actual motivations. This is dysfunctional behavior. 

                      On Tue, Aug 28, 2012 at 11:00 AM, Derek M <dmahlitz@...> wrote:
                       

                      The products are all part of a suite that releases x times per year so we've been working on priority order across all of them for the release. Another issue is that we have experts in each product and feet dragging to learn the whole suite as a team.



                      --- In scrumdevelopment@yahoogroups.com, Flavius Ștef <flavius.stef@...> wrote:
                      >
                      > Hi Derek,
                      >
                      > I speculate that the context switching cost would be lower with two teams,
                      > and thus velocity higher. One possible counterargument would be that there
                      > is only one person with a certain skill, so you'd have to address that in
                      > some way.
                      >
                      > But even after splitting, I would still try to reduce the number of
                      > products working on at the same time. Would it be possible to work on
                      > product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What
                      > about one sprint per product? What about one week sprints?
                      >
                      > Flavius
                      >
                      > On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
                      >
                      > > **

                      > >
                      > >
                      > > I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team
                      > > supports 6 products and can be working stories for 3 - 5 of those any any
                      > > sprint. Anybody have experiences with this kind of team? Is this too many
                      > > products? should we split into 2 teams for better focus?
                      > >
                      > >
                      > >
                      >


                    • Michael Wollin
                      I have a related question. I have to make the case to management that trying to run stories for multiple products/projects/backlogs through one team
                      Message 10 of 16 , Aug 28 11:34 AM
                        Re: [scrumdevelopment] How many products in 1 team is too many? I have a related question.

                        I have to make the case to management that trying to run stories for multiple products/projects/backlogs through one team concurrently is suboptimal (i.e. wasteful). I’m supposing that they probably want to do this so they can tell the internal customer that progress is being made on all fronts. This is, admittedly, a benefit. But in the spirit of just plain common sense that there’s no free lunch, I still need to effectively argue that it’s best to
                        1. have the team complete one product at a time or
                        2. have a team complete a potentially shippable portion of a product (i.e., at least a sprint’s worth) before switching

                        So the argument is:
                        1. Context switching by itself has a cost in velocity and quality (retooling the cognitive line)
                        2. Having a team split in doing stories for different projects at the same time hinders idea cross-fertilization between the team members. It also is distracting to be overhearing conversations about other projects when one is focusing where as it’s less distracting or even beneficial to overhear conversations about stories on the project one is in engaged with.
                        3. There is a gestalt to a team. The whole is greater than the sum of its parts. Splitting loses more than just the resources.
                        4. It’s perhaps harder to focus on delivery of business value. The focus likely becomes getting credit for getting stories done.

                        I still think I need more than this to make the case. I have to “persuade up.” I am, after all, not king. Any hand waiving or sweeping generalizations may kill the initiative. So does anyone have any additions that will make the business case stronger?

                        Michael


                        On 8/27/12 5:44 PM, "Adam Sroka" <adam.sroka@...> wrote:

                        Of course, the reality in your organization might not allow this, but you should recognize that spreading the team so thin is going to limit their effectiveness across all the products they touch. Mike's suggestion is a good stop gap. Do a Sprint (or two or three...) on one product, get to a comfortable stopping point, RELEASE, then switch to another one. Rinse, repeat. 
                      • Cass Dalton
                        One way to facilitate cross functionality is to limit the work to be done in a Sprint to 1 or 2 products at a time. That way not only will you become more
                        Message 11 of 16 , Aug 28 11:46 AM

                          One way to facilitate cross functionality is to limit the work to be done in a Sprint to 1 or 2 products at a time.  That way not only will you become more productive as a team since you are limiting the WIP into the team, but the experts will have to learn another product for that iteration.  And they shouldn't be expected to become experts in another product overnight, but every project has tasks that require less institutional knowledge of the product (automate existing tests, get them a CI server, review code for common mistakes which will accelerate their spin up, etc.).  As an existing "expert" in a product, I know.how alluring it is to just sit in your comfort zone.  But people don't grow that way. 

                          On Aug 28, 2012 2:01 PM, "Derek M" <dmahlitz@...> wrote:
                           

                          The products are all part of a suite that releases x times per year so we've been working on priority order across all of them for the release. Another issue is that we have experts in each product and feet dragging to learn the whole suite as a team.

                          --- In scrumdevelopment@yahoogroups.com, Flavius Ștef <flavius.stef@...> wrote:
                          >
                          > Hi Derek,
                          >
                          > I speculate that the context switching cost would be lower with two teams,
                          > and thus velocity higher. One possible counterargument would be that there
                          > is only one person with a certain skill, so you'd have to address that in
                          > some way.
                          >
                          > But even after splitting, I would still try to reduce the number of
                          > products working on at the same time. Would it be possible to work on
                          > product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What
                          > about one sprint per product? What about one week sprints?
                          >
                          > Flavius
                          >
                          > On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
                          >
                          > > **
                          > >
                          > >
                          > > I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team
                          > > supports 6 products and can be working stories for 3 - 5 of those any any
                          > > sprint. Anybody have experiences with this kind of team? Is this too many
                          > > products? should we split into 2 teams for better focus?
                          > >
                          > >
                          > >
                          >

                        • Adam Sroka
                          ... I disagree. You are taking money from the customer and spending it on overhead in order to give the customer an inflated sense of progress. This may be par
                          Message 12 of 16 , Aug 28 12:35 PM
                            On Tue, Aug 28, 2012 at 11:34 AM, Michael Wollin <yahoo@...> wrote:
                            >
                            >
                            >
                            > I have a related question.
                            >
                            > I have to make the case to management that trying to run stories for
                            > multiple products/projects/backlogs through one team concurrently is
                            > suboptimal (i.e. wasteful). I’m supposing that they probably want to do this
                            > so they can tell the internal customer that progress is being made on all
                            > fronts. This is, admittedly, a benefit.


                            I disagree. You are taking money from the customer and spending it on
                            overhead in order to give the customer an inflated sense of progress.
                            This may be par for the course in corporate IT, but it is also
                            tantamount to theft, IMO.


                            But in the spirit of just plain
                            > common sense that there’s no free lunch, I still need to effectively argue
                            > that it’s best to
                            >
                            > have the team complete one product at a time or
                            > have a team complete a potentially shippable portion of a product (i.e.,
                            > at least a sprint’s worth) before switching
                            >

                            I'm not sure this is common sense, TANSTAAFL notwithstanding.

                            The core issue is that iterative development is about iteration. You
                            have to inspect the results of the most recent iteration and apply
                            those learnings to subsequent iterations. Context switching obfuscates
                            those learnings or at least delays their application long enough for
                            information to fall through the cracks.

                            >
                            > So the argument is:
                            >
                            > Context switching by itself has a cost in velocity and quality (retooling
                            > the cognitive line)

                            Yes, but moreover you are creating additional overhead in at least the
                            following ways:

                            1) more project plans
                            2) more marketing material
                            3) more costly and complex communication with the actual customer

                            Both the internal and external communication costs go up. It is
                            essentially the same problem as forking the codebase.

                            > Having a team split in doing stories for different projects at the same
                            > time hinders idea cross-fertilization between the team members. It also is
                            > distracting to be overhearing conversations about other projects when one is
                            > focusing where as it’s less distracting or even beneficial to overhear
                            > conversations about stories on the project one is in engaged with.

                            This is a relatively minor problem compared to the others. Some amount
                            of context switching comes with the territory when you work with
                            technology.

                            From a Lean perspective this is mura (unevenness,) some of which can
                            possibly be eliminated. The management overhead is muda (futility.)

                            > There is a gestalt to a team. The whole is greater than the sum of its
                            > parts. Splitting loses more than just the resources.

                            Of course.

                            > It’s perhaps harder to focus on delivery of business value. The focus
                            > likely becomes getting credit for getting stories done.
                            >

                            It is likely that your management is already focused on velocity and
                            it is what they are optimizing for.

                            >
                            > I still think I need more than this to make the case. I have to “persuade
                            > up.” I am, after all, not king. Any hand waiving or sweeping generalizations
                            > may kill the initiative. So does anyone have any additions that will make
                            > the business case stronger?
                            >

                            Coaching has to go all the way up. Staying focused on the team is like
                            adding horsepower to a car with bald tires. For Agile to work vision
                            must come down from the top and feedback must go back up. Middle
                            management is typically very good at keeping this information from
                            making it across their desks unaltered. So, often they need the most
                            coaching.

                            Good luck! If you need help I can refer you to some friends who
                            specialize in this in particular.
                          • Michael Vizdos
                            Michael, deilver. Keep delivering. Let the results make the case for the team. Mike Vizdos ... -- Thank you, - Mike Vizdos My site: michaelvizdos.com
                            Message 13 of 16 , Aug 28 3:07 PM
                              Michael,

                              deilver. 

                              Keep delivering. 

                              Let the results make the case for the team.

                              Mike Vizdos 

                              On Tuesday, August 28, 2012, Michael Wollin wrote:
                               

                              I have a related question.

                              I have to make the case to management that trying to run stories for multiple products/projects/backlogs through one team concurrently is suboptimal (i.e. wasteful). I’m supposing that they probably want to do this so they can tell the internal customer that progress is being made on all fronts. This is, admittedly, a benefit. But in the spirit of just plain common sense that there’s no free lunch, I still need to effectively argue that it’s best to

                              1. have the team complete one product at a time or
                              2. have a team complete a potentially shippable portion of a product (i.e., at least a sprint’s worth) before switching

                              So the argument is:
                              1. Context switching by itself has a cost in velocity and quality (retooling the cognitive line)
                              2. Having a team split in doing stories for different projects at the same time hinders idea cross-fertilization between the team members. It also is distracting to be overhearing conversations about other projects when one is focusing where as it’s less distracting or even beneficial to overhear conversations about stories on the project one is in engaged with.
                              3. There is a gestalt to a team. The whole is greater than the sum of its parts. Splitting loses more than just the resources.
                              4. It’s perhaps harder to focus on delivery of business value. The focus likely becomes getting credit for getting stories done.

                              I still think I need more than this to make the case. I have to “persuade up.” I am, after all, not king. Any hand waiving or sweeping generalizations may kill the initiative. So does anyone have any additions that will make the business case stronger?

                              Michael


                              On 8/27/12 5:44 PM, "Adam Sroka" <adam.sroka@...> wrote:

                              Of course, the reality in your organization might not allow this, but you should recognize that spreading the team so thin is going to limit their effectiveness across all the products they touch. Mike's suggestion is a good stop gap. Do a Sprint (or two or three...) on one product, get to a comfortable stopping point, RELEASE, then switch to another one. Rinse, repeat. 



                              --

                              Thank you,

                              - Mike Vizdos

                              My site:      michaelvizdos.com
                              Cartoons:   implementingscrum.com
                              Twitter:       twitter.com/mvizdos
                              Facebook:  facebook.com/vizdosenterprises
                              Google+:    gplus.to/MichaelVizdos
                              LinkedIn:    linkedin.com/in/mvizdos

                              PS --> In my spare time I am also involved as the Executive Director with Gangplank Henrico.
                                         
                                          Learn more at:

                                         www.GangPlankHenrico.org
                                         facebook.com/GPHenrico
                                         groups.google.com/group/gangplank-henrico
                                         www.twitter.com/GPHenricoCty
                                         www.meetup.com/GPHenrico
                                 
                                         www.whatisgangplank.com
                                         www.gangplankhq.com
                            • Derek Neighbors
                              How do you split a 5 developers? or 3 testers? What is a 1/3 of a person? Is lack of cross functionality a bigger issue than what products are being worked
                              Message 14 of 16 , Aug 28 3:40 PM
                                How do you split a 5 developers? or 3 testers?  What is a 1/3 of a person?  Is lack of cross functionality a bigger issue than what products are being worked on?  Functionally, what does 2 teams work on 3 projects buy you over 1 team and 6 projects?

                                --
                                Derek Neighbors
                                Integrum Technologies


                                On Mon, Aug 27, 2012 at 10:28 AM, Derek M <dmahlitz@...> wrote:
                                 

                                I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team supports 6 products and can be working stories for 3 - 5 of those any any sprint. Anybody have experiences with this kind of team? Is this too many products? should we split into 2 teams for better focus?


                              • Derek Neighbors
                                Do the products all have to release at the same time? Is the value of x greater than 6? Are infrequent releases contributing to the poor prioritization of
                                Message 15 of 16 , Aug 28 3:43 PM
                                  Do the products all have to release at the same time?  Is the value of x greater than 6?  Are infrequent releases contributing to the poor prioritization of the work?

                                  What is a product expert?  What is being done to eliminate experts?  Would splitting the experts up help or hurt the situation?  How many days until a developer can commit and deploy code to production on any part of the suite?  What is being done to get that number to under 7?

                                  Is the number of products really the teams biggest challenge?

                                  --
                                  Derek Neighbors
                                  Integrum Technologies


                                  On Tue, Aug 28, 2012 at 11:00 AM, Derek M <dmahlitz@...> wrote:
                                   

                                  The products are all part of a suite that releases x times per year so we've been working on priority order across all of them for the release. Another issue is that we have experts in each product and feet dragging to learn the whole suite as a team.



                                  --- In scrumdevelopment@yahoogroups.com, Flavius Ștef <flavius.stef@...> wrote:
                                  >
                                  > Hi Derek,
                                  >
                                  > I speculate that the context switching cost would be lower with two teams,
                                  > and thus velocity higher. One possible counterargument would be that there
                                  > is only one person with a certain skill, so you'd have to address that in
                                  > some way.
                                  >
                                  > But even after splitting, I would still try to reduce the number of
                                  > products working on at the same time. Would it be possible to work on
                                  > product 1 for 2-3 sprints, release, then switch to product 2 etc. ? What
                                  > about one sprint per product? What about one week sprints?
                                  >
                                  > Flavius
                                  >
                                  > On Mon, Aug 27, 2012 at 8:28 PM, Derek M <dmahlitz@...> wrote:
                                  >
                                  > > **

                                  > >
                                  > >
                                  > > I have a team of 5 developers, 3 testers and 1/3 of a doc person. The team
                                  > > supports 6 products and can be working stories for 3 - 5 of those any any
                                  > > sprint. Anybody have experiences with this kind of team? Is this too many
                                  > > products? should we split into 2 teams for better focus?
                                  > >
                                  > >
                                  > >
                                  >


                                • RonJeffries
                                  Hi Michael, To me, the strongest argument is the one made here:
                                  Message 16 of 16 , Aug 28 5:05 PM
                                    Hi Michael,

                                    To me, the strongest argument is the one made here:

                                    http://sameelephant.tumblr.com/post/27483263741/working-on-one-thing-at-a-time-gets-more-things, namely that even if we assume no slippage or friction, doing things one at a time delivers something sooner than working on them all.

                                    According to Chet, this is called a "Pareto-optimal" solution: some people are better off, no one is worse off.

                                    More below ...

                                    On Aug 28, 2012, at 2:34 PM, Michael Wollin <yahoo@...> wrote:

                                    I have to make the case to management that trying to run stories for multiple products/projects/backlogs through one team concurrently is suboptimal (i.e. wasteful). I’m supposing that they probably want to do this so they can tell the internal customer that progress is being made on all fronts. This is, admittedly, a benefit.

                                    It is. I think that often, doing this makes sense to management because the team has no decent record of delivering anything on time. So we can't say, "OK, C, you are third. A will finish this month, B will finish next month, you will finish the month after that." Instead, we mumble and say "Well with all we have going on, it looks like your stuff will be finished in three months if nothing bad happens and the moon is in Leo.

                                    But in the spirit of just plain common sense that there’s no free lunch, I still need to effectively argue that it’s best to
                                    1. have the team complete one product at a time or
                                    2. have a team complete a potentially shippable portion of a product (i.e., at least a sprint’s worth) before switching

                                    Yes. 

                                    So the argument is:
                                    1. Context switching by itself has a cost in velocity and quality (retooling the cognitive line)
                                    It does. Some studies indicate that the cost of task switching is as much as 40%. Think about that! Instead of getting three things done in three months, one month each, doing them interleaved might make it take more than four months!

                                    Multitasking increases defects. As we program, we carry a lot of stuff in our heads, and when we switch tasks, we dump all that stuff and have to rebuild it. This leads to errors. In addition, if we put the code down in the middle of the work, there will be a "seam" between where we left off and where we restarted. Imagine laying a concrete floor, half one day, half the next.  You'll get a crack.

                                    Joel on Software, not always my favorite guy, has a nice article about task switching, that you might find inspiring.
                                    1. Having a team split in doing stories for different projects at the same time hinders idea cross-fertilization between the team members. It also is distracting to be overhearing conversations about other projects when one is focusing where as it’s less distracting or even beneficial to overhear conversations about stories on the project one is in engaged with.
                                    Yes. Hearing the buzz when it's all your stuff is positive and people get to like it. When it's not your stuff it's just irritating. That way lies headphones and much lower communication.
                                    1. There is a gestalt to a team. The whole is greater than the sum of its parts. Splitting loses more than just the resources.
                                    It loses ideas. It loses camaraderie. It loses one person helping another. It loses opportunities to kick around an idea or get help finding a sticky problem or solving a tricky design issue.
                                    1. It’s perhaps harder to focus on delivery of business value. The focus likely becomes getting credit for getting stories done.
                                    No perhaps to it. The focus on value is destroyed. There is much less incentive to work to find some creative way to solve the real problem with a simpler solution, because the real problem is masked by being spread over more time, and by being mixed in with a bunch of other problems. We lose our understanding of the "point" and we just crank out code.


                                    I should mention that all these things are worse if the team does not pair program, if the team is not practicing TDD and refactoring, and if the team does not have strong automated acceptance tests. All these practices help keep your eye on the ball. And if you do those and do multitasking, you're still probably screwed. WIthout them, you're just about guaranteed to be screwed.

                                    If I were there, I'd ask what the organization's record is of delivering what is wanted, on time. I would be expecting to hear that it wasn't very good. Of course, if it is very good ... maybe we don't need to change. :)

                                    I still think I need more than this to make the case. I have to “persuade up.” I am, after all, not king. Any hand waiving or sweeping generalizations may kill the initiative. So does anyone have any additions that will make the business case stronger? 

                                    It may be worth looking at Theory of Constraints to see if there is help there that can be used. And I would be tempted to try a game of some kind that would bring it home. (Yes, even with the big guys. If I'm ever invited to sit with the President, I will pull my 3x5 cards out of my pocket and draw on them. He'll get it.)

                                    One game that Duncan Smith mentioned recently was the Detention Game. It's goofy but you might be able to turn it to your purpose.

                                    You're right. Make it happen!

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Sometimes I give myself admirable advice, but I am incapable of taking it.
                                    -- Mary Wortley Montagu



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