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

Re: [Scrum] Code scrum - development team size

Expand Messages
  • Michael Mallete
    I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it
    Message 1 of 16 , Aug 17, 2013
    • 0 Attachment
      I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

      Regards,
      Mike Mallete

      http://odd-e.ph



      On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

      I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf


      I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

      I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

      Ram


      --
      You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
      To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
      To post to this group, send email to scrumalliance@....
      Visit this group at http://groups.google.com/group/scrumalliance.
      For more options, visit https://groups.google.com/groups/opt_out.
       
       

    • Tathagat Varma
      W hen we want self-organizing teams, when we want teams that inspect and adapt, teams that can retrospect their process and identify their improvement
      Message 2 of 16 , Aug 17, 2013
      • 0 Attachment
        W
        hen we want self-organizing teams, when we want teams that inspect and adapt, teams that can retrospect their process and identify their improvement opportunities, who are we to tell them what size they should be?

        regards,
        Tathagat


        Blog RSS Twitter LinkedIn Google Plus SlideShare


        On Sat, Aug 17, 2013 at 6:23 PM, Michael Mallete <mrmallete@...> wrote:
         

        I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

        Regards,
        Mike Mallete




        On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

        I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf


        I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

        I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

        Ram


        --
        You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
        To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
        To post to this group, send email to scrumalliance@....
        Visit this group at http://groups.google.com/group/scrumalliance.
        For more options, visit https://groups.google.com/groups/opt_out.
         
         


      • Ron Jeffries
        Hi Tathagat, ... I ll pretend that was a question. We are people with decades of experience, who understand deeply the various forces that act on a team for
        Message 3 of 16 , Aug 17, 2013
        • 0 Attachment
          Hi Tathagat,

          On Aug 17, 2013, at 9:42 AM, Tathagat Varma <tathagat.varma@...> wrote:

          W
          hen we want self-organizing teams, when we want teams that inspect and adapt, teams that can retrospect their process and identify their improvement opportunities, who are we to tell them what size they should be?

          I'll pretend that was a question. We are people with decades of experience, who understand deeply the various forces that act on a team for good and for bad, and who can provide them with guidelines within which they are safe to operate until they gain the experience and skill that we have.

          That's who we are. No one has to listen. No one has to do what we say. But when you jump out of an airplane, it's a good idea to listen to the jump master.

          Ron Jeffries
          www.XProgramming.com 
          Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana

        • Ram Srinivasan
          Hi Tathagat, I have a different perspective on this. Self-organization does not happen in vacuum. It needs a
          Message 4 of 16 , Aug 17, 2013
          • 0 Attachment
            Hi Tathagat,

            I have a different perspective on this. Self-organization does not happen in vacuum. It needs a container, and IMHO, the size of the team is one of the boundaries of the container (there might be others, depending on the context of the team/organization. e.g. language/platform of choice of development, etc).

            Thanks
            Ram


            On Sat, Aug 17, 2013 at 9:42 AM, Tathagat Varma <tathagat.varma@...> wrote:
             

            W
            hen we want self-organizing teams, when we want teams that inspect and adapt, teams that can retrospect their process and identify their improvement opportunities, who are we to tell them what size they should be?

            regards,
            Tathagat


            Blog RSS Twitter LinkedIn Google Plus SlideShare


            On Sat, Aug 17, 2013 at 6:23 PM, Michael Mallete <mrmallete@...> wrote:
             

            I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

            Regards,
            Mike Mallete




            On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

            I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf


            I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

            I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

            Ram


            --
            You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
            To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
            To post to this group, send email to scrumalliance@....
            Visit this group at http://groups.google.com/group/scrumalliance.
            For more options, visit https://groups.google.com/groups/opt_out.
             
             



          • Tathagat Varma
            Ron - that was not a question. It was my perspective. I agree on experience leading to guidance, but not to prescriptions. *regards,* *Tathagat *
            Message 5 of 16 , Aug 17, 2013
            • 0 Attachment
              Ron - that was not a question. It was my perspective. I agree on experience leading to guidance, but not to prescriptions. 

              regards,
              Tathagat


              Blog RSS Twitter LinkedIn Google Plus SlideShare


              On Sat, Aug 17, 2013 at 10:28 PM, Ron Jeffries <ronjeffries@...> wrote:
               

              Hi Tathagat,


              On Aug 17, 2013, at 9:42 AM, Tathagat Varma <tathagat.varma@...> wrote:

              W
              hen we want self-organizing teams, when we want teams that inspect and adapt, teams that can retrospect their process and identify their improvement opportunities, who are we to tell them what size they should be?

              I'll pretend that was a question. We are people with decades of experience, who understand deeply the various forces that act on a team for good and for bad, and who can provide them with guidelines within which they are safe to operate until they gain the experience and skill that we have.

              That's who we are. No one has to listen. No one has to do what we say. But when you jump out of an airplane, it's a good idea to listen to the jump master.

              Ron Jeffries
              www.XProgramming.com 
              Before you contradict an old man, my fair friend, you should endeavor to understand him. - George Santayana


            • Ajithesh Hegde
              Ram, Have you taken a look at the Scrum Guide doc maintained by Ken and Jeff who are the original inventors of Scrum? They have a section called Development
              Message 6 of 16 , Aug 17, 2013
              • 0 Attachment
                Ram,

                Have you taken a look at the Scrum Guide doc maintained by Ken and Jeff who are the original inventors of Scrum?  They have a section called "Development Team size" in their doc as follows:

                Development Team Size
                Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

                You can find this doc at: http://www.scrumguides.org/

                This section advocates a size of 3 to 9.  However, I have worked with teams of sizes such as 14 doing pretty well and hence I agree with Tathagat and Mike Malle.

                Rgds
                Ajithesh




                On Sat, Aug 17, 2013 at 6:23 PM, Michael Mallete <mrmallete@...> wrote:
                 

                I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

                Regards,
                Mike Mallete




                On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

                I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf


                I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

                I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

                Ram


                --
                You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
                To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
                To post to this group, send email to scrumalliance@....
                Visit this group at http://groups.google.com/group/scrumalliance.
                For more options, visit https://groups.google.com/groups/opt_out.
                 
                 


              • madhurgenius
                I would smhow disagree with the contention that 13 size teams are ok. The problem is not about they being qualified to do Scrum but rather of good
                Message 7 of 16 , Aug 18, 2013
                • 0 Attachment
                  I would smhow disagree with the contention that 13 size teams are ok. The problem is not about they being qualified to do Scrum but rather of good communication within the team and be able to form a cohesive unit through bonding and interpersonal relationships. Bigger teams take that much more time to get to a performing and they tend to lose advantage of responding to changes quickly over a shorter duration of time.

                  When I see bigger teams and I am told that we can't sub divide them , I see more of a problem of backlog management and skill balance rather than the theory itself.

                  Yes there may be exceptional teams but does that hold true at a broader level. May be not. IMHO, 6-8 member teams are far more agile than smaller or bigger teams than that
                  Sent from BlackBerry® on Airtel

                  From: Ajithesh Hegde <ajithesh.gh@...>
                  Sender: scrumdevelopment@yahoogroups.com
                  Date: Sun, 18 Aug 2013 12:21:58 +0530
                  To: <scrumdevelopment@yahoogroups.com>
                  ReplyTo: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Re: [Scrum] Code scrum - development team size

                   

                  Ram,

                  Have you taken a look at the Scrum Guide doc maintained by Ken and Jeff who are the original inventors of Scrum?  They have a section called "Development Team size" in their doc as follows:

                  Development Team Size
                  Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

                  You can find this doc at: http://www.scrumguides.org/

                  This section advocates a size of 3 to 9.  However, I have worked with teams of sizes such as 14 doing pretty well and hence I agree with Tathagat and Mike Malle.

                  Rgds
                  Ajithesh




                  On Sat, Aug 17, 2013 at 6:23 PM, Michael Mallete <mrmallete@...> wrote:
                   

                  I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

                  Regards,
                  Mike Mallete




                  On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

                  I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf


                  I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

                  I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

                  Ram


                  --
                  You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
                  To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
                  To post to this group, send email to scrumalliance@....
                  Visit this group at http://groups.google.com/group/scrumalliance.
                  For more options, visit https://groups.google.com/groups/opt_out.
                   
                   


                • Joshua Partogi
                  I agree that Scrum Guides does not prescribe but it suggests to have team size that is lower than 9 to prevent complexity in coordinating between team members.
                  Message 8 of 16 , Aug 18, 2013
                  • 0 Attachment
                    I agree that Scrum Guides does not prescribe but it suggests to have team size that is lower than 9 to prevent complexity in coordinating between team members. A team that has 14 team members and doing well, most probably are teams who has been doing Scrum for several Sprints. But how would a team who just started using Scrum know the ideal team size? This is where the Scrum Guides gives a guidance/hint. And from there they will keep inspecting and adapting what works best for them.


                    Kindest regards,
                    Joshua Partogi
                    http://www.leanagile.in



                    To: scrumdevelopment@yahoogroups.com
                    From: madhur.kathuria@...
                    Date: Sun, 18 Aug 2013 08:04:13 +0000
                    Subject: Re: [scrumdevelopment] Re: [Scrum] Code scrum - development team size

                     
                    I would smhow disagree with the contention that 13 size teams are ok. The problem is not about they being qualified to do Scrum but rather of good communication within the team and be able to form a cohesive unit through bonding and interpersonal relationships. Bigger teams take that much more time to get to a performing and they tend to lose advantage of responding to changes quickly over a shorter duration of time.

                    When I see bigger teams and I am told that we can't sub divide them , I see more of a problem of backlog management and skill balance rather than the theory itself.

                    Yes there may be exceptional teams but does that hold true at a broader level. May be not. IMHO, 6-8 member teams are far more agile than smaller or bigger teams than that
                    Sent from BlackBerry® on Airtel

                    From: Ajithesh Hegde <ajithesh.gh@...>
                    Sender: scrumdevelopment@yahoogroups.com
                    Date: Sun, 18 Aug 2013 12:21:58 +0530
                    To: <scrumdevelopment@yahoogroups.com>
                    ReplyTo: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Re: [Scrum] Code scrum - development team size

                     

                    Ram,

                    Have you taken a look at the Scrum Guide doc maintained by Ken and Jeff who are the original inventors of Scrum?  They have a section called "Development Team size" in their doc as follows:

                    Development Team Size
                    Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

                    You can find this doc at: http://www.scrumguides.org/

                    This section advocates a size of 3 to 9.  However, I have worked with teams of sizes such as 14 doing pretty well and hence I agree with Tathagat and Mike Malle.

                    Rgds
                    Ajithesh




                    On Sat, Aug 17, 2013 at 6:23 PM, Michael Mallete <mrmallete@...> wrote:
                     

                    I would agree on not setting a number. For all we know there are teams of 13 that works pretty well. I actually know of a team of 14 who insists they have it better that way than having a smaller number. Just because of this, they are not qualified to be doing Scrum is just silly. I would leave it at 'keep the team members as few as possible.'

                    Regards,
                    Mike Mallete




                    On Wed, Aug 14, 2013 at 10:08 PM, Ram Srinivasan <vasan.ram@...> wrote:

                    I am looking at core scrum, http://agileatlas.org/images/uploads/corescrum.pdf

                    I see that it does not mention the size of the development team. Or did I miss it? Or is it intentionally not mentioned?

                    I do see that MJ has an article http://agileatlas.org/articles/item/scrum-reference-card which mentions 7+-2.

                    Ram



                    --
                    You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
                    To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
                    To post to this group, send email to scrumalliance@....
                    Visit this group at http://groups.google.com/group/scrumalliance.
                    For more options, visit https://groups.google.com/groups/opt_out.
                     
                     





                  • Ron Jeffries
                    Hi Madhur, ... The original XP team was 14 devs plus three on the product owner side. We had a single team room, pair programmed always, had stand ups always,
                    Message 9 of 16 , Aug 18, 2013
                    • 0 Attachment
                      Hi Madhur,

                      On Aug 18, 2013, at 4:04 AM, madhur.kathuria@... wrote:

                      I would smhow disagree with the contention that 13 size teams are ok. The problem is not about they being qualified to do Scrum but rather of good communication within the team and be able to form a cohesive unit through bonding and interpersonal relationships. Bigger teams take that much more time to get to a performing and they tend to lose advantage of responding to changes quickly over a shorter duration of time.

                      The original XP team was 14 devs plus three on the product owner side. We had a single team room, pair programmed always, had stand ups always, and had good communication. Most everyone could do most everything. It was the one of the best teams I've seen in over a half-century of software development.

                      So … it can be done, and might not even be that hard ...

                      When I see bigger teams and I am told that we can't sub divide them , I see more of a problem of backlog management and skill balance rather than the theory itself. 

                      Yes, that is probably true. I don't know whether seven or nine of us could have done what the 14 did. I don't think that the 14 were likely twice as productive as the best seven would have been. Twice as productive as their average times seven? Don't really know. Doubt it on principle.

                      Yes there may be exceptional teams but does that hold true at a broader level. May be not. IMHO, 6-8 member teams are far more agile than smaller or bigger teams than that

                      I prefer smaller teams as well, and yet there have been notable exceptions. I'm not sure if the teams were special, or just their situation.
                      Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

                    • Madhur Kathuria
                      Guess we are on the same plane in that a process or guideline is based on a widely observed phenomenon and that exceptions would always be there ( and for
                      Message 10 of 16 , Aug 18, 2013
                      • 0 Attachment

                        Guess we are on the same plane in that a process or guideline is based on a widely observed phenomenon and that exceptions would always be there ( and for good) . No wonder the first manifest is " People and Interactions" are valued more over "process and tools"

                        On Aug 18, 2013 3:48 PM, "Ron Jeffries" <ronjeffries@...> wrote:
                         

                        Hi Madhur,


                        On Aug 18, 2013, at 4:04 AM, madhur.kathuria@... wrote:

                        I would smhow disagree with the contention that 13 size teams are ok. The problem is not about they being qualified to do Scrum but rather of good communication within the team and be able to form a cohesive unit through bonding and interpersonal relationships. Bigger teams take that much more time to get to a performing and they tend to lose advantage of responding to changes quickly over a shorter duration of time.

                        The original XP team was 14 devs plus three on the product owner side. We had a single team room, pair programmed always, had stand ups always, and had good communication. Most everyone could do most everything. It was the one of the best teams I've seen in over a half-century of software development.

                        So … it can be done, and might not even be that hard ...

                        When I see bigger teams and I am told that we can't sub divide them , I see more of a problem of backlog management and skill balance rather than the theory itself. 

                        Yes, that is probably true. I don't know whether seven or nine of us could have done what the 14 did. I don't think that the 14 were likely twice as productive as the best seven would have been. Twice as productive as their average times seven? Don't really know. Doubt it on principle.

                        Yes there may be exceptional teams but does that hold true at a broader level. May be not. IMHO, 6-8 member teams are far more agile than smaller or bigger teams than that

                        I prefer smaller teams as well, and yet there have been notable exceptions. I'm not sure if the teams were special, or just their situation.
                        Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand". -- Mary Doria Russell

                      • Jeff Sutherland
                        Everything in Scrum was based on rigorous evidence, testing and validation, before it was release to the public in 1995. Team size data showed that for
                        Message 11 of 16 , Aug 18, 2013
                        • 0 Attachment
                          Everything in Scrum was based on rigorous evidence, testing and validation, before it was release to the public in 1995.

                          Team size data showed that for hundreds of teams doing the same size project that takes 11 months for team of six, will take 17 months for a team of 10. These data were published by one of the top two productivity experts in the U.S.. We listened when we put together Scrum and verified this effect.

                          The reasons for this are documented in Fred Brooks classic, "The Mythical Man Month."

                          We have seen a team of 9 going at 60 points broken into two teams of 4 and 5 generating 180 points a few sprints later.

                          It is absolutely impossible to get a team of 13 to a hyperproductive state that generates 15 function points per developer per month, about 8 times the velocity of an average waterfall team. I'm ready to back up this statement with a case of good champagne for anyone who can prove me wrong.

                          Jeff Sutherland
                          Co-Creator of Scrum


                        • madhurgenius
                          Thanks for the wonderful insights Jeff. Sent from BlackBerry® on Airtel ... From: Jeff Sutherland Sender:
                          Message 12 of 16 , Aug 18, 2013
                          • 0 Attachment
                            Thanks for the wonderful insights Jeff.
                            Sent from BlackBerry® on Airtel

                            From: Jeff Sutherland <jeff.sutherland@...>
                            Sender: scrumdevelopment@yahoogroups.com
                            Date: Sun, 18 Aug 2013 11:29:45 -0400
                            To: scrumdevelopment@yahoogroups_com<scrumdevelopment@yahoogroups.com>
                            ReplyTo: scrumdevelopment@yahoogroups.com
                            Subject: [scrumdevelopment] Re: [Scrum] Code scrum - development team size

                             

                            Everything in Scrum was based on rigorous evidence, testing and validation, before it was release to the public in 1995.

                            Team size data showed that for hundreds of teams doing the same size project that takes 11 months for team of six, will take 17 months for a team of 10. These data were published by one of the top two productivity experts in the U.S.. We listened when we put together Scrum and verified this effect.

                            The reasons for this are documented in Fred Brooks classic, "The Mythical Man Month."

                            We have seen a team of 9 going at 60 points broken into two teams of 4 and 5 generating 180 points a few sprints later.

                            It is absolutely impossible to get a team of 13 to a hyperproductive state that generates 15 function points per developer per month, about 8 times the velocity of an average waterfall team. I'm ready to back up this statement with a case of good champagne for anyone who can prove me wrong.

                            Jeff Sutherland
                            Co-Creator of Scrum


                          • Adam Sroka
                            I don t have any formal data to back me up, but my anecdotal experience is this: 4-6 collocated members seems to be ideal if you are not pairing consistently.
                            Message 13 of 16 , Aug 18, 2013
                            • 0 Attachment
                              I don't have any formal data to back me up, but my anecdotal experience is this:

                              4-6 collocated members seems to be ideal if you are not pairing consistently. The number is even lower if you are distributed, perhaps only 2-3. Last year I managed a team of six in four locations and found it almost impossible to have any idea what was going on at any given time. On the other hand I have worked with a team of three in three separate locations with no problem. 

                              These numbers approximately double if you pair consistently and follow Arlo Belshee's rules: switch pairs roughly every 90 mins, tasks pulled by the least qualified implementer, no individual ownership. In fact, with a team of twelve that follows these rules consistently the management overhead needed to keep communication flowing is less than for the team of 4-6 that pairs ad hoc. However, following these rules while distributed is nearly impossible. I have only worked with one team that claimed to try, and I don't think that it was succeeding objectively (Not going to name any names.) 


                              On Sun, Aug 18, 2013 at 11:29 AM, Jeff Sutherland <jeff.sutherland@...> wrote:
                               

                              Everything in Scrum was based on rigorous evidence, testing and validation, before it was release to the public in 1995.

                              Team size data showed that for hundreds of teams doing the same size project that takes 11 months for team of six, will take 17 months for a team of 10. These data were published by one of the top two productivity experts in the U.S.. We listened when we put together Scrum and verified this effect.

                              The reasons for this are documented in Fred Brooks classic, "The Mythical Man Month."

                              We have seen a team of 9 going at 60 points broken into two teams of 4 and 5 generating 180 points a few sprints later.

                              It is absolutely impossible to get a team of 13 to a hyperproductive state that generates 15 function points per developer per month, about 8 times the velocity of an average waterfall team. I'm ready to back up this statement with a case of good champagne for anyone who can prove me wrong.

                              Jeff Sutherland
                              Co-Creator of Scrum



                            • George Dinwiddie
                              Hi, Jeff, ... Can you give me a pointer to this data? I m curious about the variability in duration for a nominal 11 month project. And also how they validate
                              Message 14 of 16 , Aug 18, 2013
                              • 0 Attachment
                                Hi, Jeff,

                                On 8/18/13 11:29 AM, Jeff Sutherland wrote:
                                >
                                >
                                > Everything in Scrum was based on rigorous evidence, testing and
                                > validation, before it was release to the public in 1995.
                                >
                                > Team size data showed that for hundreds of teams doing the same size
                                > project that takes 11 months for team of six, will take 17 months for a
                                > team of 10. These data were published by one of the top two productivity
                                > experts in the U.S.. We listened when we put together Scrum and verified
                                > this effect.

                                Can you give me a pointer to this data? I'm curious about the
                                variability in duration for a nominal 11 month project. And also how
                                they validate the "same sizeness" of the projects, and the contextual
                                differences between the various teams.

                                - George

                                >
                                > The reasons for this are documented in Fred Brooks classic, "The
                                > Mythical Man Month."
                                >
                                > We have seen a team of 9 going at 60 points broken into two teams of 4
                                > and 5 generating 180 points a few sprints later.
                                >
                                > It is absolutely impossible to get a team of 13 to a hyperproductive
                                > state that generates 15 function points per developer per month, about 8
                                > times the velocity of an average waterfall team. I'm ready to back up
                                > this statement with a case of good champagne for anyone who can prove me
                                > wrong.
                                >
                                > Jeff Sutherland
                                > Co-Creator of Scrum

                                --
                                ----------------------------------------------------------------------
                                * George Dinwiddie * http://blog.gdinwiddie.com
                                Software Development http://www.idiacomputing.com
                                Consultant and Coach http://www.agilemaryland.org
                                ----------------------------------------------------------------------
                              • Silvana Wasitova
                                Hi George, One reference re. team size of 7: http://www.sheilamargolis.com/2011/01/24/what-is-the-optimal-group-size-for-decision-making/    -- Silvana
                                Message 15 of 16 , Aug 21, 2013
                                • 0 Attachment
                                  Hi George,

                                   
                                  --
                                  Silvana Wasitova |  wasitova@... | Lausanne, Switzerland



                                  From: George Dinwiddie <lists@...>
                                  To: scrumdevelopment@yahoogroups.com
                                  Sent: Sunday, August 18, 2013 6:57 PM
                                  Subject: Re: [scrumdevelopment] Re: [Scrum] Code scrum - development team size

                                   
                                  Hi, Jeff,

                                  On 8/18/13 11:29 AM, Jeff Sutherland wrote:
                                  >
                                  >
                                  > Everything in Scrum was based on rigorous evidence, testing and
                                  > validation, before it was release to the public in 1995.
                                  >
                                  > Team size data showed that for hundreds of teams doing the same size
                                  > project that takes 11 months for team of six, will take 17 months for a
                                  > team of 10. These data were published by one of the top two productivity
                                  > experts in the U.S.. We listened when we put together Scrum and verified
                                  > this effect.

                                  Can you give me a pointer to this data? I'm curious about the
                                  variability in duration for a nominal 11 month project. And also how
                                  they validate the "same sizeness" of the projects, and the contextual
                                  differences between the various teams.

                                  - George

                                  >
                                  > The reasons for this are documented in Fred Brooks classic, "The
                                  > Mythical Man Month."
                                  >
                                  > We have seen a team of 9 going at 60 points broken into two teams of 4
                                  > and 5 generating 180 points a few sprints later.
                                  >
                                  > It is absolutely impossible to get a team of 13 to a hyperproductive
                                  > state that generates 15 function points per developer per month, about 8
                                  > times the velocity of an average waterfall team. I'm ready to back up
                                  > this statement with a case of good champagne for anyone who can prove me
                                  > wrong.
                                  >
                                  > Jeff Sutherland
                                  > Co-Creator of Scrum

                                  --
                                  ----------------------------------------------------------
                                  * George Dinwiddie * http://blog.gdinwiddie.com
                                  Software Development http://www.idiacomputing.com
                                  Consultant and Coach http://www.agilemaryland.org
                                  ----------------------------------------------------------



                                • George Dinwiddie
                                  Hi, Silvana, ... Not much data there. I guess I ll have to dig up Hackman and Vidmar (1970) to find the data. It s clear that you shouldn t marry a woman under
                                  Message 16 of 16 , Aug 21, 2013
                                  • 0 Attachment
                                    Hi, Silvana,

                                    On 8/21/13 11:14 AM, Silvana Wasitova wrote:
                                    >
                                    >
                                    > Hi George,
                                    >
                                    > One reference re. team size of 7:
                                    > http://www.sheilamargolis.com/2011/01/24/what-is-the-optimal-group-size-for-decision-making/

                                    Not much data there. I guess I'll have to dig up Hackman and Vidmar
                                    (1970) to find the data. It's clear that you shouldn't marry a woman
                                    under 25, though. (http://www.intuitor.com/statistics/SmallGroups.html)
                                    Or use "majority rules" in groups with an even number of members.

                                    Nothing there that supports "Team size data showed that for hundreds of
                                    teams doing the same size project that takes 11 months for team of six,
                                    will take 17 months for a team of 10." I like small teams, but I'm not
                                    so happy with data presented as scientifically proven without any
                                    experimental basis.

                                    Interesting statement: "So if you’re looking for the best size for a
                                    team, consider an odd number close to five. But remember the number is
                                    just one factor. Social sensitivity and being able to read emotions are
                                    attributes of successful team decision making. Consider the number and
                                    consider the members."

                                    - George

                                    --
                                    ----------------------------------------------------------------------
                                    * George Dinwiddie * http://blog.gdinwiddie.com
                                    Software Development http://www.idiacomputing.com
                                    Consultant and Coach http://www.agilemaryland.org
                                    ----------------------------------------------------------------------
                                  Your message has been successfully submitted and would be delivered to recipients shortly.