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

Maximum Size of Scrum Team

Expand Messages
  • berteigconsulting
    Typically, people talk about the ideal Scrum team size being 7+/-2. But what about the maximum workable size? Or, another way of asking, at what size does a
    Message 1 of 20 , Jun 27, 2005
    • 0 Attachment
      Typically, people talk about the ideal Scrum team size being 7+/-2.
      But what about the maximum workable size? Or, another way of asking,
      at what size does a different methodology become more effective (e.g.
      typical PMI-style project management)? I would love to hear some
      stories from people about large(-ish) teams that worked, and stories
      about teams that were just too big. Why did they fail? In
      retrospect, is there any way they could have succeeded, or was size
      the real limiting factor? Does it depend on the type of project? The
      team's experience? Their experience with each other? Corporate culture?

      What allows a large Scrum team to succeed if the whole team is working
      off of the same product backlog, does Scrum planning and daily Scrums
      together, sits all in the same room?

      If you would like to make a brief reply:

      Size of team? _________ (size > 9)
      Did it work? _________ (yes/no)

      Otherwise, feel free to expound upon one of the many questions I asked
      above!

      Thanks,
      Mishkin Berteig
      mishkin@...
      http://www.agileadvice.com/
    • Deb
      I know that Jutta Eckstein has written Agile Software Development in the Large: Diving Into the Deep which addresses the challenges of larger teams (waiting
      Message 2 of 20 , Jun 28, 2005
      • 0 Attachment
        I know that Jutta Eckstein has written "Agile Software Development in
        the Large: Diving Into the Deep" which addresses the challenges of
        larger teams (waiting for my copy to arrive).

        Jutta, are you here?

        deb
      • Simon Baker
        I ve worked in extreme programming and scrum teams comprising 3-20 people. When the team has been bigger, say an entire department, i have split it into
        Message 3 of 20 , Jun 29, 2005
        • 0 Attachment
          I've worked in extreme programming and scrum teams comprising 3-20
          people. When the team has been bigger, say an entire department, i
          have split it into multiple teams each comprising 4-8 people.
          However, it's difficult to state an absolute maximum because i
          believe the culture, social environment, circumstances, people and
          project influence the _optimum_ team size.

          I take into account:

          * The culture, social environment and organisation

          * People characteristics - do they behave as a team? do they
          collaborate and communicate effectively? do they utilise and
          leverage one anothers skillsets? do they learn from one another?

          * Developer skillsets and the team's ability to collaborate,
          communicate and self-organise, driving iterations while keeping an
          eye on the project big picture. I certainly favour smaller teams
          comprising 4-6 generalist or multi-disciplined programmers and i
          have always been more successful with this configuration.

          * The size of the project. How well is the project decomposed and
          organised into work units that facilitate concurrent development and
          feed multiple teams. Often, with a large project and many teams,
          integration can again become tricky. Obviously the practice of
          continuous integration is essential but i have found that
          development-by-contract, and developing using interfaces and mock
          objects helps iterate through inter-team dependencies.

          A large scrum team should be split into smaller scrum teams and the
          scrum masters need to interact effectively at a programme (as
          opposed to a project) level, to ensure everything moves together.
          The teams should operate individually and collectively as a larger
          team. I have found the Scrum of Scrums approach works well, but
          ultimately i think success depends on the decomposition and
          assignment of work amongst the teams. Like OOD you want maximum
          cohesion and minimum coupling.

          Simon Baker

          --- In scrumdevelopment@yahoogroups.com, "berteigconsulting"
          <mishkin@b...> wrote:
          > Typically, people talk about the ideal Scrum team size being 7+/-
          2.
          > But what about the maximum workable size? Or, another way of
          asking,
          > at what size does a different methodology become more effective
          (e.g.
          > typical PMI-style project management)? I would love to hear some
          > stories from people about large(-ish) teams that worked, and
          stories
          > about teams that were just too big. Why did they fail? In
          > retrospect, is there any way they could have succeeded, or was size
          > the real limiting factor? Does it depend on the type of project?
          The
          > team's experience? Their experience with each other? Corporate
          culture?
          >
          > What allows a large Scrum team to succeed if the whole team is
          working
          > off of the same product backlog, does Scrum planning and daily
          Scrums
          > together, sits all in the same room?
          >
          > If you would like to make a brief reply:
          >
          > Size of team? _________ (size > 9)
          > Did it work? _________ (yes/no)
          >
          > Otherwise, feel free to expound upon one of the many questions I
          asked
          > above!
          >
          > Thanks,
          > Mishkin Berteig
          > mishkin@b...
          > http://www.agileadvice.com/
        • David H.
          ... Does that mean that your dail scrum has been stretched to 20 minutes for the 20 people team?
          Message 4 of 20 , Jun 29, 2005
          • 0 Attachment
            On 6/29/05, Simon Baker <simonbaker@...> wrote:
            > I've worked in extreme programming and scrum teams comprising 3-20

            Does that mean that your dail scrum has been stretched to 20 minutes
            for the 20 people team?
          • Simon Baker
            ... Actually that team was an xp team and not scrum, but that doesn t matter. The stand-up meeting was never longer than 20 minutes and on average it was
            Message 5 of 20 , Jun 29, 2005
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@g...> wrote:
              > On 6/29/05, Simon Baker <simonbaker@t...> wrote:
              > > I've worked in extreme programming and scrum teams comprising 3-20
              >
              > Does that mean that your dail scrum has been stretched to 20 minutes
              > for the 20 people team?

              Actually that team was an xp team and not scrum, but that doesn't
              matter. The stand-up meeting was never longer than 20 minutes and on
              average it was completed within 15 minutes. I was tempted on a few
              occassions to split the team, but the team worked well, even at i
              grant you was an unusually large size for an agile team. I decided not
              to tinker for 2 reasons:
              1. The team had gelled during years past and was already an effective
              development unit. Consequently the management frowned on
              re-organisation of something that was seen to work.
              2. I didn't want to wreck a capable team just to comply with the agile
              rule-of-thumb on team size.

              Note that this was the only team of that size that i have seen adopt
              agile successfully. They were a team of highly experienced and
              multi-disciplined people. A rarety.

              Simon Baker.
            • Wayne Allen
              I had a similar experience with a team of 20. We did change our standup focus from the individual to the backlog items and typically had the meeting in under
              Message 6 of 20 , Jun 29, 2005
              • 0 Attachment
                I had a similar experience with a team of 20. We did change our standup
                focus from the individual to the backlog items and typically had the
                meeting in under 10 min.

                Wayne

                -----Original Message-----
                From: scrumdevelopment@yahoogroups.com
                [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Simon Baker
                Sent: Wednesday, June 29, 2005 6:19
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Re: Maximum Size of Scrum Team

                --- In scrumdevelopment@yahoogroups.com, "David H." <dmalloc@g...>
                wrote:
                > On 6/29/05, Simon Baker <simonbaker@t...> wrote:
                > > I've worked in extreme programming and scrum teams comprising 3-20
                >
                > Does that mean that your dail scrum has been stretched to 20 minutes
                > for the 20 people team?

                Actually that team was an xp team and not scrum, but that doesn't
                matter. The stand-up meeting was never longer than 20 minutes and on
                average it was completed within 15 minutes. I was tempted on a few
                occassions to split the team, but the team worked well, even at i grant
                you was an unusually large size for an agile team. I decided not to
                tinker for 2 reasons:
                1. The team had gelled during years past and was already an effective
                development unit. Consequently the management frowned on re-organisation
                of something that was seen to work.
                2. I didn't want to wreck a capable team just to comply with the agile
                rule-of-thumb on team size.

                Note that this was the only team of that size that i have seen adopt
                agile successfully. They were a team of highly experienced and
                multi-disciplined people. A rarety.

                Simon Baker.





                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...
                Yahoo! Groups Links
              • David H.
                ... Please do not think I am touchy, but as somone that studied communication sciences I would like to find out how you can translate viable information within
                Message 7 of 20 , Jun 30, 2005
                • 0 Attachment
                  On 6/30/05, Wayne Allen <wallen@...> wrote:
                  > I had a similar experience with a team of 20. We did change our standup
                  > focus from the individual to the backlog items and typically had the
                  > meeting in under 10 min.
                  >

                  Please do not think I am touchy, but as somone that studied
                  communication sciences I would like to find out how you can translate
                  viable information within 30 seconds?
                  What info did you pass on actually?
                  Was it anywhere close to the three questions of a daily scrum?

                  -d

                  --
                  Sent from gmail so do not trust this communication.
                  Do not send me sensitive information here, ask for my none-gmail accounts.
                • Wayne Allen
                  I guess I wasn t clear. We didn t ask each individual person the 3 questions, we asked the 3 questions about the active backlog items. Since we typically had
                  Message 8 of 20 , Jun 30, 2005
                  • 0 Attachment
                    I guess I wasn't clear. We didn't ask each individual person the 3 questions, we asked the 3 questions about the active backlog items. Since we typically had 3-5 active backlog items 10 min was plenty of time.

                    This was an optimization for this particular team as classic stand-ups were taking in excess of 20 min, yet there wasn't any real reason to break the team up.

                    Wayne

                    ________________________________

                    From: scrumdevelopment@yahoogroups.com on behalf of David H.
                    Sent: Thu 6/30/2005 2:58 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Re: Maximum Size of Scrum Team



                    On 6/30/05, Wayne Allen <wallen@...> wrote:
                    > I had a similar experience with a team of 20. We did change our standup
                    > focus from the individual to the backlog items and typically had the
                    > meeting in under 10 min.
                    >

                    Please do not think I am touchy, but as somone that studied
                    communication sciences I would like to find out how you can translate
                    viable information within 30 seconds?
                    What info did you pass on actually?
                    Was it anywhere close to the three questions of a daily scrum?

                    -d

                    --
                    Sent from gmail so do not trust this communication.
                    Do not send me sensitive information here, ask for my none-gmail accounts.


                    To Post a message, send it to: scrumdevelopment@...
                    To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                    Yahoo! Groups Links
                  • berteigconsulting
                    I m curious: what was going right that made breaking up the team a sub-optimal move? The Mythical Man-Month plus any number of other references all talk
                    Message 9 of 20 , Jun 30, 2005
                    • 0 Attachment
                      I'm curious: what was going right that made breaking up the team a
                      sub-optimal move?

                      "The Mythical Man-Month" plus any number of other references all talk
                      about communication overhead becoming excessive very quickly as teams
                      get larger... how did this team of 20 avoid this (in addition to the
                      modified daily standup)?

                      Mishkin Berteig
                      mishkin@...
                      http://www.agileadvice.com/

                      --- In scrumdevelopment@yahoogroups.com, "Wayne Allen" <wallen@c...>
                      wrote:
                      > I guess I wasn't clear. We didn't ask each individual person the 3
                      questions, we asked the 3 questions about the active backlog items.
                      Since we typically had 3-5 active backlog items 10 min was plenty of time.
                      >
                      > This was an optimization for this particular team as classic
                      stand-ups were taking in excess of 20 min, yet there wasn't any real
                      reason to break the team up.
                      >
                      > Wayne
                      >
                      > ________________________________
                      >
                      > From: scrumdevelopment@yahoogroups.com on behalf of David H.
                      > Sent: Thu 6/30/2005 2:58 AM
                      > To: scrumdevelopment@yahoogroups.com
                      > Subject: Re: [scrumdevelopment] Re: Maximum Size of Scrum Team
                      >
                      >
                      >
                      > On 6/30/05, Wayne Allen <wallen@c...> wrote:
                      > > I had a similar experience with a team of 20. We did change our
                      standup
                      > > focus from the individual to the backlog items and typically had the
                      > > meeting in under 10 min.
                      > >
                      >
                      > Please do not think I am touchy, but as somone that studied
                      > communication sciences I would like to find out how you can translate
                      > viable information within 30 seconds?
                      > What info did you pass on actually?
                      > Was it anywhere close to the three questions of a daily scrum?
                      >
                      > -d
                      >
                      > --
                      > Sent from gmail so do not trust this communication.
                      > Do not send me sensitive information here, ask for my none-gmail
                      accounts.
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@e...
                      > To Unsubscribe, send a blank message to:
                      scrumdevelopment-unsubscribe@e...
                      > Yahoo! Groups Links
                    • Ron Jeffries
                      ... The rationale behind the communication overhead theory is that there are N*(N-1) two-person communication paths, and this number grows like N-squared. On
                      Message 10 of 20 , Jun 30, 2005
                      • 0 Attachment
                        On Thursday, June 30, 2005, at 8:24:15 PM, berteigconsulting wrote:

                        > I'm curious: what was going right that made breaking up the team a
                        > sub-optimal move?

                        > "The Mythical Man-Month" plus any number of other references all talk
                        > about communication overhead becoming excessive very quickly as teams
                        > get larger... how did this team of 20 avoid this (in addition to the
                        > modified daily standup)?

                        The rationale behind the communication overhead theory is that there
                        are N*(N-1) two-person communication paths, and this number grows
                        like N-squared. On the one hand, Agile methods like Scrum use
                        standup meetings and open workspaces to cause more of these
                        communications to take place in broadcast mode. On the other, they
                        use hot methods of communication, like conversation, that work more
                        effectively, reducing communication overhead.

                        To the extent that the above model is accurate, it was perhaps not a
                        special characteristic of this team, but a general characteristic of
                        Agile methods that they operate somewhat outside the N-squared
                        limit.

                        Ron Jeffries
                        www.XProgramming.com
                        If you're not throwing some gravel once in a while,
                        you're not using the whole road.
                      • berteigconsulting
                        ... I agree that broadcast mode communication, conversation, information radiators, etc. all help Agile methods to overcome that N-squared limit. But if
                        Message 11 of 20 , Jun 30, 2005
                        • 0 Attachment
                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                          <ronjeffries@X...> wrote:
                          > The rationale behind the communication overhead theory is that there
                          > are N*(N-1) two-person communication paths, and this number grows
                          > like N-squared. On the one hand, Agile methods like Scrum use
                          > standup meetings and open workspaces to cause more of these
                          > communications to take place in broadcast mode. On the other, they
                          > use hot methods of communication, like conversation, that work more
                          > effectively, reducing communication overhead.
                          >
                          > To the extent that the above model is accurate, it was perhaps not a
                          > special characteristic of this team, but a general characteristic of
                          > Agile methods that they operate somewhat outside the N-squared
                          > limit.
                          >
                          I agree that broadcast mode communication, conversation, information
                          radiators, etc. all help Agile methods to overcome that N-squared
                          limit. But if that's the case, why do we the community assume that
                          7+/-2 is the ideal team size? I guess I started this thread because I
                          wanted to challenge that assumption, but I don't have much data.

                          So if Agile does all these great things with communication, what other
                          barriers prevent teams from (typically) being very effective if they
                          are larger than 9 people? What causes the big drop-off in
                          effectiveness when a team goes from 7 to 8 to 9 to 10 and beyond? Or
                          is this a rule of thumb that is based on limited anecdotal evidence?
                          Now I'm intensely curious :-)

                          Mishkin Berteig
                          mishkin@...
                          http://www.berteigconsulting.com
                        • Paul Hodgetts
                          ... I don t really have much more than my anecdotal experiences from working with single scrum teams of sizes larger than around 9, so no hard data. I
                          Message 12 of 20 , Jun 30, 2005
                          • 0 Attachment
                            Mishkin Berteig wrote:

                            > I agree that broadcast mode communication, conversation, information
                            > radiators, etc. all help Agile methods to overcome that N-squared
                            > limit. But if that's the case, why do we the community assume that
                            > 7+/-2 is the ideal team size? I guess I started this thread because I
                            > wanted to challenge that assumption, but I don't have much data.

                            I don't really have much more than my anecdotal experiences from
                            working with single scrum teams of sizes larger than around 9, so
                            no hard data. I emphasize I'm talking about the size of a /single/
                            scrum team, not multiple teams in a scrum of scrums.

                            My observation is that agile may reduce the N-squared effect, and
                            allow us to be more efficient with teams of 5-9 than usual, but
                            not overcome it. I still see the effects of greater communication
                            overhead in single Scrum teams that start getting to be 10 to 15
                            in size. I see it in all the meetings -- planning, daily scrums,
                            retrospectives. There are more people that have things to say,
                            and more people that need to receive it, and it just seems to
                            take longer and be harder to make sure all the messages are really
                            delivered and absorbed.

                            > So if Agile does all these great things with communication, what other
                            > barriers prevent teams from (typically) being very effective if they
                            > are larger than 9 people? What causes the big drop-off in
                            > effectiveness when a team goes from 7 to 8 to 9 to 10 and beyond? Or
                            > is this a rule of thumb that is based on limited anecdotal evidence?
                            > Now I'm intensely curious :-)

                            Here are some other things that I've observed happen when team
                            sizes get to be around 10 to 15:

                            - Planning for more people means the team takes on more backlog
                            items, and produces more tasks for a sprint. It starts taking
                            more time for sprint planning. A team of 8 can usually get
                            through sprint planning in 6-8 hours, sometimes less. I've
                            worked with around 8 teams over the past couple of years that
                            were 12-15 in size, and they all struggled to get through
                            sprint planning in a day. When sprint planning starts to
                            drag on past about 6 hours, team members get antsy and often
                            start to lose interest, and the quality of the planning starts
                            to deteriorate. A sprint plan for a larger team has more
                            tasks, and it seems to get much harder for everyone to grok
                            the sprint plan in its entirety.

                            - In a smaller team, it seems easier for those team members
                            with less outgoing or aggressive personalities to still become
                            involved. As the team size grows to 10 or more, it seems that
                            these folks begin to get drowned out. I observe more team
                            members with minimal participation (the quiet ones in the
                            meetings) in larger teams than in smaller teams. Not as much
                            in the daily scrum or retrospectives where they should always
                            have their turn, but more so in sprint planning where much of
                            the conversation is dynamic as backlog items are discussed.

                            - In addition to the added challenges of making sure the
                            messages in daily scrums and other meetings are delivered, my
                            observation is that the team members have greater difficulty
                            keeping track of everything that's going on with the project
                            in larger teams. In smaller teams, I can usually go to any
                            team member and talk with them about anything on the project,
                            and they know what's up. In larger teams, I find it more
                            frequent that a team member will not know about some things
                            that are going on. It seems they begin to focus their
                            attention on a smaller subset of the active tasks (perhaps
                            our attention span hits limits when the teams have more
                            than 7+/-2 active tasks per day?).

                            - I notice that when teams start to get around 12-15 in size,
                            the teams begin to form into sub-groups, usually around the
                            disciplines. This smells bad to me, as if the social
                            organizing instincts of the team are telling us that the size
                            is too big to form the tighter social structures we want. I
                            can't say why the sub-groups form around disciplines, but I
                            don't think it's a good thing. They also may form into sub-
                            groups around the backlog items they are attacking, which I
                            don't think is as bad, but still seems to then allow space
                            for the other sub-groups to tune out each other a bit.

                            As I mentioned, these are just anecdotal observations and I
                            haven't analyzed any of this much. But of the teams larger
                            than 10 that I've worked with over the past couple of years
                            (around 8 or so), just about all of them seem to have a lot
                            more issues and difficulties than the smaller teams. They
                            seem to have a lower productivity per person than teams more
                            in the sweet spot of 5-9 that we're discussing.

                            I've also seen issues when forcing a team of 12 to split into
                            multiple teams to try to mitigate the above observations.
                            There were other, perhaps equally nasty, issues introduced by
                            the new multi-team needs and practices, and it also seems in
                            some cases there is a minimum effective team size that is
                            greater than half of the maximum effective team size, but
                            that's another story...

                            Regards,
                            Paul
                            -----
                            Paul Hodgetts -- CEO, Coach, Trainer, Consultant
                            Agile Logic -- www.agilelogic.com
                            Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
                            Complete solutions for adopting agile processes, Scrum and XP.

                            Upcoming Events:

                            Agile Product Owner and Customer Boot Camp
                            Agile 2005 Conference, July 24-29, Denver, CO, USA
                            http://www.agile2005.org
                          • Mike Beedle
                            In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) . that remains true even in broadcast or multi-cast mode. What is different
                            Message 13 of 20 , Jul 1, 2005
                            • 0 Attachment

                               

                              In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) … that remains true

                              even in broadcast or multi-cast mode.

                               

                              What is different in Agile mode, is that there are less handoffs (of information), in multi-casts, and

                              this enhances the ability of team to create *shared models* and *shared values*.  This translates

                              into an overall ability for the team (organization) to learn and therefore increases its *bounded rationality*.

                              (Bounded rationality, is simply the limit of intelligence/memory a team can have.)

                               

                              In constrast, teams with only one-to-one communications mode, experience a systemic problem

                              of passing information from agent to agent, because information has to traverse the graph of

                              agents diffusing information in each exchange – think Shannon , colored graph theory, diffusions,

                              Senge, MIT’s beer game, TOC, etc.

                               

                              To get deeper into this some Complexity concepts are useful.

                               

                              First, what we are trying to create in Agile (Scrum) is an organizational structure that is a true team:

                               

                              TEAM == an intelligent autonomous self-interested self-organizing multi-agent

                                          (self-interested but in Nash equilibrium with the organization J, looking out for itself,

                                          and for the good of organization it belongs.)

                               

                              In this view, a team is composed of multiple (human) agents, that is capable to adapt in an

                              environment maximizing one or more utility functions e.g. minimizing a prioritized backlog

                              and/or maximizing learning, etc.

                               

                              The Multi-Agent adapts maximizing these utility function(s), by achieving minima or maxima in

                              a “fitness landscape” through cooperation and collaboration (Kauffman “The Origins of Order”).

                              (Kauffman has shown in  NK models that a maxima is achieved… can you guess? when the

                              number of cooperating agents K in a group formed by N agents is 2.  (Yes, Pair <Anything>

                              makes sense from the Complexity point of view.)  This requirement however, is indicative that

                              agent-to-agent interactions are also needed, suggesting both multi-case and single-cast

                              modes are both important.

                               

                              As 2 or more agents work together, through a Knowledge Creation cycle

                              http://choo.fis.utoronto.ca/KMIottawa/KMfmwk2.html, new knowledge is create locally, that either

                              has to diffuse, or be multi-casted…. That’s why the Daily Scrums are so useful, they ensure

                              the *shared models* are updated at least daily, if the NEW information recently created by

                              cooperation has not diffused to the team as a whole.

                               

                              The Daily Scrums cycles: inspect, adapt, share, cooperate (work together), test (unit), build, test (unit),

                              refactor, integrate, test (all units), are a good example of what Kauffman’s call an auto-catalytic

                              cycle == a periodic system of patterns that trigger each other in a cycle, through a system of

                              (simple) rules.

                               

                              This new information can be of very many different natures, because the agents or multi-agents

                              have many layers:  sensors, filtering of information, interpretation of information,

                              facts, goals, plans, values and beliefs, issues, actions, actuators (that allow them to do

                              things in the world.)

                               

                              As such, each agent has its own model of the world, but the overlaps in what each agent thinks

                              is the world is a *shared model* in terms of facts, goals, plans, values, actions, etc.

                               

                              Having said this, one idea I am tossing around, is that we typically just update the goals/actions/issues

                              part of Scrum team multi-agent, but it may be of great help to externalize other parts of

                              the multi-agent architecture e.g. sensors, filtering of information, interpretation of information,

                              facts, values and beliefs, actuators.  But what is externalized in Scrum is at least the core of

                              the Maxwell Demon (the “Organization of work” machine), that reduces local entropy.

                               

                              So one of the main problems with large teams is the *bounded rationality*, of both the multi-agent,

                              and the individual agents, as more agents are added to the team, less likely is that they

                              hold individually a complex *shared model*.

                               

                              That’s why at some point it serves to specialize into a “subsumtion” layer.

                               

                              To translate this into robotics, each specialized agent (or multi-agent in enterprises), becomes

                              part of a subsumption layer http://ai.eecs.umich.edu/cogarch0/subsump/ , which is one of the

                              *fundamental and key inspirational sources for Scrum*.

                               

                              Translated into social-speak this is:  Conway ’s Law, break larger teams into specialized teams

                              that require cohesion and little coupling with other teams as the complexity of the shared models

                              increase and you get close to the bounded rationality of the team.

                               

                              To emphasize, if the bounded rationality of the team is not being challenged … keep them

                              together.  If the bounded rationality of the team is challenged is time to break them into

                              sub-teams.

                               

                              What is the magic number?  Is it 7+-2?

                               

                              It is different for every team (enterprise, organization), so you have to work through

                              empirical models  (see what works for you in your domain, calibrate your teams, etc.)

                               

                              - Mike

                            • Simon Baker
                              Paul makes good points here and I concur with all of them. Through my experiences: a) I ve definitely encountered difficulties during planning meetings as the
                              Message 14 of 20 , Jul 1, 2005
                              • 0 Attachment
                                Paul makes good points here and I concur with all of them. Through
                                my experiences:

                                a) I've definitely encountered difficulties during planning meetings
                                as the team becomes larger. It's challenging to keep the meeting
                                focused and effective because there can be many vocal
                                participants/contributors, and with more people in the team, more
                                work can be taken into an iteration therefore increasing the size of
                                the planning activity.

                                b) I've often found that teams that are small enough that every
                                member knows everything that is going on - progress,
                                accomplishments, obstacles, etc - are confident, productive and
                                happy. And because they're happy they become more productive. And
                                because they're more productive they become happier. Obviously a
                                plateau is reached at some point. As someone who often works with
                                development teams wanting to transition to agile, this positive
                                cycle is one of the (many) indicators i look for to suggest the team
                                is 'getting into the groove', with the agile practices starting to
                                harmonise. The _right_ team size, based on the characteristics and
                                skillsets of the members, is a direct and significant contributor to
                                making agile methods work. I've found that in a team with the right
                                size, compisition and attitude, collaboration happens natually and
                                gains momentum quickly.

                                c) Take a group of people and you'll find people who are quiet,
                                passive or introvert. These people will be smothered by more vocal
                                team members. It's easier to spot these people when the team is
                                small. When coaching, i try to work with these people without
                                bringing attention to them, in such a way as to help bring them out
                                of their shells, give them confidence and have them realise that
                                they can have fun by communicating. Eventually, the responsibility
                                for this 'coaxing' shifts to the team as they start to self-organise
                                and motivate. Of course, there are people who have quiet
                                personalities but are effective communicators. One chap i knew,
                                didn't speak too often, but when he did you tended to listen. When
                                quiet, he was listening and assessing but when he spoke his words
                                were measured and precise, and his questions direct.

                                IMO, the rule of thumb of 7+/-2 should only be the starting point.
                                Be prepared to adapt the team size and composition as part of the
                                adaptation of agile methods. There can never be a definitive optimal
                                team size because there are too many soft and subjective factors
                                that influence the effectiveness of a team. The situation, project,
                                culture, environment, organisation, distribution, personalities,
                                egos, skillsets, etc all have to be taken into account when trying
                                to find the optimal team size.

                                Simon Baker.

                                > Here are some other things that I've observed happen when team
                                > sizes get to be around 10 to 15:
                                >
                                > - Planning for more people means the team takes on more backlog
                                > items, and produces more tasks for a sprint. It starts taking
                                > more time for sprint planning. A team of 8 can usually get
                                > through sprint planning in 6-8 hours, sometimes less. I've
                                > worked with around 8 teams over the past couple of years that
                                > were 12-15 in size, and they all struggled to get through
                                > sprint planning in a day. When sprint planning starts to
                                > drag on past about 6 hours, team members get antsy and often
                                > start to lose interest, and the quality of the planning starts
                                > to deteriorate. A sprint plan for a larger team has more
                                > tasks, and it seems to get much harder for everyone to grok
                                > the sprint plan in its entirety.
                                >
                                > - In a smaller team, it seems easier for those team members
                                > with less outgoing or aggressive personalities to still become
                                > involved. As the team size grows to 10 or more, it seems that
                                > these folks begin to get drowned out. I observe more team
                                > members with minimal participation (the quiet ones in the
                                > meetings) in larger teams than in smaller teams. Not as much
                                > in the daily scrum or retrospectives where they should always
                                > have their turn, but more so in sprint planning where much of
                                > the conversation is dynamic as backlog items are discussed.
                                >
                                > - In addition to the added challenges of making sure the
                                > messages in daily scrums and other meetings are delivered, my
                                > observation is that the team members have greater difficulty
                                > keeping track of everything that's going on with the project
                                > in larger teams. In smaller teams, I can usually go to any
                                > team member and talk with them about anything on the project,
                                > and they know what's up. In larger teams, I find it more
                                > frequent that a team member will not know about some things
                                > that are going on. It seems they begin to focus their
                                > attention on a smaller subset of the active tasks (perhaps
                                > our attention span hits limits when the teams have more
                                > than 7+/-2 active tasks per day?).
                                >
                                > - I notice that when teams start to get around 12-15 in size,
                                > the teams begin to form into sub-groups, usually around the
                                > disciplines. This smells bad to me, as if the social
                                > organizing instincts of the team are telling us that the size
                                > is too big to form the tighter social structures we want. I
                                > can't say why the sub-groups form around disciplines, but I
                                > don't think it's a good thing. They also may form into sub-
                                > groups around the backlog items they are attacking, which I
                                > don't think is as bad, but still seems to then allow space
                                > for the other sub-groups to tune out each other a bit.
                                >
                                > As I mentioned, these are just anecdotal observations and I
                                > haven't analyzed any of this much. But of the teams larger
                                > than 10 that I've worked with over the past couple of years
                                > (around 8 or so), just about all of them seem to have a lot
                                > more issues and difficulties than the smaller teams. They
                                > seem to have a lower productivity per person than teams more
                                > in the sweet spot of 5-9 that we're discussing.
                                >
                                > I've also seen issues when forcing a team of 12 to split into
                                > multiple teams to try to mitigate the above observations.
                                > There were other, perhaps equally nasty, issues introduced by
                                > the new multi-team needs and practices, and it also seems in
                                > some cases there is a minimum effective team size that is
                                > greater than half of the maximum effective team size, but
                                > that's another story...
                                >
                                > Regards,
                                > Paul
                                > -----
                                > Paul Hodgetts -- CEO, Coach, Trainer, Consultant
                                > Agile Logic -- www.agilelogic.com
                                > Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
                                > Complete solutions for adopting agile processes, Scrum and XP.
                                >
                                > Upcoming Events:
                                >
                                > Agile Product Owner and Customer Boot Camp
                                > Agile 2005 Conference, July 24-29, Denver, CO, USA
                                > http://www.agile2005.org
                              • Mike Beedle
                                ... path)) . that remains true ... Just accounting. so things are clear. In a Daily Scrum, each member broadcasts 1) what he worked on, 2) what his/her issues
                                Message 15 of 20 , Jul 1, 2005
                                • 0 Attachment

                                   

                                  Mike Beedle wrote:

                                  > In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) … that remains true

                                  > even in broadcast or multi-cast mode.

                                   

                                  Just accounting… so things are clear.

                                   

                                  In a Daily Scrum, each member broadcasts 1) what he worked on, 2) what his/her issues are, 3) what

                                  he/she will be work on, to the other N-1 members.

                                   

                                  So each of N agents multi-casts once to the other N-1 agents.

                                   

                                  That’s N(N-1) flows, and N(N-1)/2 paths (subtracting repeated links/edges).

                                   

                                  In each flow, there is something to be learned by the other agents, so the shared models still depend

                                  somewhat on N^2.

                                   

                                  During a Scrum Day, there can be N/2 spontaneous pairs cooperating, or M < N/2 subteams,

                                  cooperating with each other, or (N/2 -1) if N is odd J.

                                   

                                  If agent each has to diffuse NEW information to the other N-1 members, on a one-to-one basis,

                                  then the longest diffusion path would be N-1.

                                   

                                  In the worst case, scenario, all information created new by N agents would have to diffuse

                                  into N-1 nodes to reach all other agents.

                                   

                                  That’s N (N-1) diffusion flows, and subtracting repeated links (edges), that is N(N-1)/2 paths.

                                   

                                  So a knowledge diffusion model in the worst case scenario, is also dependent on N^2.

                                   

                                  What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                  when a human agent (person) multi-casts its message, the probability is higher that the

                                  other N-1 agents will all interpret his/her message as *one and same message*, because even

                                  if they don’t interpret the message identically at first, they can achieve a *shared model*

                                  by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                   

                                  In contrast, there are still N(N-1) messages in the diffusion, but because the other agents

                                  are not present there, no self-consistency in these messages can be achieved so we are

                                  effectively playing the broken telephone game.

                                   

                                  - Mike

                                • Ron Jeffries
                                  ... Agreed on the /2, my mistake. Not so agreed on the other one. Think Ethernet. :) Ron Jeffries www.XProgramming.com Computers are useless. They can only
                                  Message 16 of 20 , Jul 1, 2005
                                  • 0 Attachment
                                    On Friday, July 1, 2005, at 7:13:04 AM, Mike Beedle wrote:

                                    > In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per
                                    > path)) . that remains true
                                    > even in broadcast or multi-cast mode.

                                    Agreed on the /2, my mistake.

                                    Not so agreed on the other one. Think Ethernet. :)

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Computers are useless. They can only give you answers. -- Picasso
                                  • Mike Dwyer
                                    The rule of 7 +-2 also has been found to be viable in Small Group Dynamics where the primary group size is determined by the individuals in the group and the
                                    Message 17 of 20 , Jul 1, 2005
                                    • 0 Attachment
                                      The 'rule of 7 +-2 also has been found to be viable in Small Group Dynamics
                                      where the primary group size is determined by the individuals in the group
                                      and the 'span of attention' each of those individuals and that group has.

                                      There is another issue that Scrum and Agile needs to consider and that is
                                      the distortion of data provided at a daily meeting caused by the attendees
                                      communicating what they heard and understood was said to other groups they
                                      belong to. This is just another version of the telephone game.

                                      Michael F. Dwyer

                                      Mike.Dwyer1@...



                                      -----Original Message-----
                                      From: scrumdevelopment@yahoogroups.com
                                      [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of berteigconsulting
                                      Sent: Thursday, June 30, 2005 10:54 PM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: [scrumdevelopment] Re: Maximum Size of Scrum Team

                                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                      <ronjeffries@X...> wrote:
                                      > The rationale behind the communication overhead theory is that there
                                      > are N*(N-1) two-person communication paths, and this number grows
                                      > like N-squared. On the one hand, Agile methods like Scrum use
                                      > standup meetings and open workspaces to cause more of these
                                      > communications to take place in broadcast mode. On the other, they
                                      > use hot methods of communication, like conversation, that work more
                                      > effectively, reducing communication overhead.
                                      >
                                      > To the extent that the above model is accurate, it was perhaps not a
                                      > special characteristic of this team, but a general characteristic of
                                      > Agile methods that they operate somewhat outside the N-squared
                                      > limit.
                                      >
                                      I agree that broadcast mode communication, conversation, information
                                      radiators, etc. all help Agile methods to overcome that N-squared
                                      limit. But if that's the case, why do we the community assume that
                                      7+/-2 is the ideal team size? I guess I started this thread because I
                                      wanted to challenge that assumption, but I don't have much data.

                                      So if Agile does all these great things with communication, what other
                                      barriers prevent teams from (typically) being very effective if they
                                      are larger than 9 people? What causes the big drop-off in
                                      effectiveness when a team goes from 7 to 8 to 9 to 10 and beyond? Or
                                      is this a rule of thumb that is based on limited anecdotal evidence?
                                      Now I'm intensely curious :-)

                                      Mishkin Berteig
                                      mishkin@...
                                      http://www.berteigconsulting.com





                                      To Post a message, send it to: scrumdevelopment@...
                                      To Unsubscribe, send a blank message to:
                                      scrumdevelopment-unsubscribe@...
                                      Yahoo! Groups Links
                                    • Mike Dwyer
                                      MikeB: ... Daily Scrum, arguably, ... higher that the ... message*, because even ... a *shared model* ... the message is/was. When we construct a formal and
                                      Message 18 of 20 , Jul 1, 2005
                                      • 0 Attachment

                                        MikeB:

                                        Let’s talk about the following:

                                        >What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                        >when a human agent (person) multi-casts its message, the probability is higher that the

                                        >other N-1 agents will all interpret his/her message as *one and same message*, because even

                                        >if they don’t interpret the message identically at first, they can achieve a *shared model*

                                        >by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                         

                                        When we construct a formal and informal communication topology.  The notion of ‘shared model’ has a tendency to become a dysfunctional artifact, at least in my experience.

                                         

                                        If Scrum Team Charlie holds a daily meeting and there are 7 – ‘pigs’ and 5 – ‘chickens’ in attendance and each communicates to 1 other formal or informal group (made up of only 3 people) their interpretation of the Charlie Daily meeting, we end up with how many derivatives of the Scrum Meeting? Carry this out only one more time. 

                                         

                                        In an environment where all parties and groups are collocated, the probability a shared model of what was said will be reached as people bump into to each other, ask questions, make phonecalls, send and respond to emails.  The problem is that the clock has ticked and the information – as well as the truth it conveyed – ages.  As long as you accept that the truth in an emerging solution changes (a premise for the daily update), you have to ask is the genesis of this ‘shared model’ fast enough to carry reflect the current state?

                                         

                                        Within the team, yes.  With the participants, probably.  With those beyond the participants unlikely.

                                         

                                        As we talk about moving into the enterprise we need to recognize and deal with the ‘ripple effect’ the team’s daily update has on the organization and on the noise it can produce.

                                         

                                         

                                         

                                        Michael F. Dwyer

                                         

                                        Mike.Dwyer1@...

                                         

                                         

                                        -----Original Message-----
                                        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Beedle
                                        Sent: Friday, July 01, 2005 8:03 AM
                                        To: scrumdevelopment@yahoogroups.com
                                        Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                         

                                         

                                        Mike Beedle wrote:

                                        > In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) … that remains true

                                        > even in broadcast or multi-cast mode.

                                         

                                        Just accounting… so things are clear.

                                         

                                        In a Daily Scrum, each member broadcasts 1) what he worked on, 2) what his/her issues are, 3) what

                                        he/she will be work on, to the other N-1 members.

                                         

                                        So each of N agents multi-casts once to the other N-1 agents.

                                         

                                        That’s N(N-1) flows, and N(N-1)/2 paths (subtracting repeated links/edges).

                                         

                                        In each flow, there is something to be learned by the other agents, so the shared models still depend

                                        somewhat on N^2.

                                         

                                        During a Scrum Day, there can be N/2 spontaneous pairs cooperating, or M < N/2 subteams,

                                        cooperating with each other, or (N/2 -1) if N is odd J.

                                         

                                        If agent each has to diffuse NEW information to the other N-1 members, on a one-to-one basis,

                                        then the longest diffusion path would be N-1.

                                         

                                        In the worst case, scenario, all information created new by N agents would have to diffuse

                                        into N-1 nodes to reach all other agents.

                                         

                                        That’s N (N-1) diffusion flows, and subtracting repeated links (edges), that is N(N-1)/2 paths.

                                         

                                        So a knowledge diffusion model in the worst case scenario, is also dependent on N^2.

                                         

                                        What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                        when a human agent (person) multi-casts its message, the probability is higher that the

                                        other N-1 agents will all interpret his/her message as *one and same message*, because even

                                        if they don’t interpret the message identically at first, they can achieve a *shared model*

                                        by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                         

                                        In contrast, there are still N(N-1) messages in the diffusion, but because the other agents

                                        are not present there, no self-consistency in these messages can be achieved so we are

                                        effectively playing the broken telephone game.

                                         

                                        - Mike



                                        To Post a message, send it to:   scrumdevelopment@...
                                        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                                      • Mike Beedle
                                        Mike, Good points -- you have certainly taken it to the big picture level. The shared models are certainly a dysfunctional artifact, and we cope with that
                                        Message 19 of 20 , Jul 1, 2005
                                        • 0 Attachment

                                           

                                          Mike,


                                          Good points -- you have certainly taken it to the “big picture” level.

                                           

                                          The “shared models” are certainly a dysfunctional artifact, and we cope with that by having smaller teams,

                                          (or subsumption layers, if you will), shared documents and such.

                                           

                                          I guess both in business and in software development we are still trying to

                                          find ways to keep and update these shared models.

                                           

                                          That is the ultimate challenge for social organizations – to beat their bounded rationality,

                                          and to do that we must have better ways to store, share, update shared models,

                                           

                                          - Mike

                                           


                                          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mike Dwyer
                                          Sent: Friday, July 01, 2005 9:13 AM
                                          To: scrumdevelopment@yahoogroups.com ; agileenterprise.@yahoogroups.com
                                          Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                           

                                          MikeB:

                                          Let’s talk about the following:

                                          >What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                          >when a human agent (person) multi-casts its message, the probability is higher that the

                                          >other N-1 agents will all interpret his/her message as *one and same message*, because even

                                          >if they don’t interpret the message identically at first, they can achieve a *shared model*

                                          >by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                           

                                          When we construct a formal and informal communication topology.  The notion of ‘shared model’ has a tendency to become a dysfunctional artifact, at least in my experience.

                                           

                                          If Scrum Team Charlie holds a daily meeting and there are 7 – ‘pigs’ and 5 – ‘chickens’ in attendance and each communicates to 1 other formal or informal group (made up of only 3 people) their interpretation of the Charlie Daily meeting, we end up with how many derivatives of the Scrum Meeting? Carry this out only one more time. 

                                           

                                          In an environment where all parties and groups are collocated, the probability a shared model of what was said will be reached as people bump into to each other, ask questions, make phonecalls, send and respond to emails.  The problem is that the clock has ticked and the information – as well as the truth it conveyed – ages.  As long as you accept that the truth in an emerging solution changes (a premise for the daily update), you have to ask is the genesis of this ‘shared model’ fast enough to carry reflect the current state?

                                           

                                          Within the team, yes.  With the participants, probably.  With those beyond the participants unlikely.

                                           

                                          As we talk about moving into the enterprise we need to recognize and deal with the ‘ripple effect’ the team’s daily update has on the organization and on the noise it can produce.

                                           

                                           

                                           

                                          Michael F. Dwyer

                                           

                                          Mike.Dwyer1@...

                                           

                                           

                                          -----Original Message-----
                                          From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Mike Beedle
                                          Sent: Friday, July 01, 2005 8:03 AM
                                          To: scrumdevelopment@yahoogroups.com
                                          Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                           

                                           

                                          Mike Beedle wrote:

                                          > In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) … that remains true

                                          > even in broadcast or multi-cast mode.

                                           

                                          Just accounting… so things are clear.

                                           

                                          In a Daily Scrum, each member broadcasts 1) what he worked on, 2) what his/her issues are, 3) what

                                          he/she will be work on, to the other N-1 members.

                                           

                                          So each of N agents multi-casts once to the other N-1 agents.

                                           

                                          That’s N(N-1) flows, and N(N-1)/2 paths (subtracting repeated links/edges).

                                           

                                          In each flow, there is something to be learned by the other agents, so the shared models still depend

                                          somewhat on N^2.

                                           

                                          During a Scrum Day, there can be N/2 spontaneous pairs cooperating, or M < N/2 subteams,

                                          cooperating with each other, or (N/2 -1) if N is odd J.

                                           

                                          If agent each has to diffuse NEW information to the other N-1 members, on a one-to-one basis,

                                          then the longest diffusion path would be N-1.

                                           

                                          In the worst case, scenario, all information created new by N agents would have to diffuse

                                          into N-1 nodes to reach all other agents.

                                           

                                          That’s N (N-1) diffusion flows, and subtracting repeated links (edges), that is N(N-1)/2 paths.

                                           

                                          So a knowledge diffusion model in the worst case scenario, is also dependent on N^2.

                                           

                                          What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                          when a human agent (person) multi-casts its message, the probability is higher that the

                                          other N-1 agents will all interpret his/her message as *one and same message*, because even

                                          if they don’t interpret the message identically at first, they can achieve a *shared model*

                                          by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                           

                                          In contrast, there are still N(N-1) messages in the diffusion, but because the other agents

                                          are not present there, no self-consistency in these messages can be achieved so we are

                                          effectively playing the broken telephone game.

                                           

                                          - Mike



                                          To Post a message, send it to:   scrumdevelopment@...
                                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                                          To Post a message, send it to:   scrumdevelopment@...
                                          To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                                        • Mike Dwyer
                                          Presently I am dealing with exactly this problem. We are running two week scrums that cannot have a daily face to face meeting because of timezones, geography
                                          Message 20 of 20 , Jul 1, 2005
                                          • 0 Attachment

                                            Presently I am dealing with exactly this problem.  We are running two week scrums that cannot have a daily face to face meeting because of timezones, geography and the fact that the product owner and their staffs are constantly in motion.

                                             

                                            What we have done is shift the daily update to a two phase.  First the team gets together, no managers, no scrummaster, just the ‘doers’.  They write down what they their responses to the questions 3 at the end of the day.  The next morning they get together and ‘synch’ with each other going over what they wrote, and talking it over.  Again, no one else (because they are not physically or temporally collocated.)

                                             

                                            One of the team or the team goes to their Manager (who has been trained in Scrum Techniques – but is not fully certifiable) and goes through the ‘questions 3’.  The manager then re-organizes the information into the business issues that he and the product owner have agreed are the drivers for the Sprint and sends this out to ‘all interested parties’.  As I may have mentioned in another thread.  A person or a group makes the interested parties list if they have asked for the update (virtual chicken) or if they are associated with the impediment.

                                             

                                            There are other variations of this (based on team cultures) like a modified punchlist that are also used.

                                             

                                            Here is the interesting thing.  The Daily Update as it is called, is forwarded repeatedly,  Thus providing the entire organization that is impacted by the activity of the team a single statement on the status.  The updates occur every day around the same time.

                                             

                                            Three things are happening that prove this variant of the daily scrum adds value.

                                            1.         The team members report that their productivity has improved because they do not get the “what’s up” call that interrupts them.  Proof, the back log in one critical area has decreased by 2 orders of magnitude – most of which are revenue sensitive.

                                             

                                            2.         Daily Updates that do not go out as expected (there was and will never be a schedule for these) the manager gets phone calls from people not on the distribution list and sometimes not even associated with the activity.  This includes VP and D and C level people looking for insight.

                                             

                                            3.         people who work in groups that are traditionally managed, have begun to perform ‘one man sprints’ and are finding the same results.  In fact one key player has a vendor doing the same  (no formal request, just through example that it works.)

                                             

                                            4.         The larger impact is that the meetings we attend with the receivers of the daily update can move faster and easier, manage customers better and do not worry.

                                             

                                             

                                            Michael F. Dwyer

                                             

                                            Mike.Dwyer1@...

                                             

                                             

                                            -----Original Message-----
                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Beedle
                                            Sent: Friday, July 01, 2005 12:14 PM
                                            To: scrumdevelopment@yahoogroups.com; agileenterprise.@yahoogroups.com
                                            Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                             

                                             

                                            Mike,


                                            Good points -- you have certainly taken it to the “big picture” level.

                                             

                                            The “shared models” are certainly a dysfunctional artifact, and we cope with that by having smaller teams,

                                            (or subsumption layers, if you will), shared documents and such.

                                             

                                            I guess both in business and in software development we are still trying to

                                            find ways to keep and update these shared models.

                                             

                                            That is the ultimate challenge for social organizations – to beat their bounded rationality,

                                            and to do that we must have better ways to store, share, update shared models,

                                             

                                            - Mike

                                             


                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Dwyer
                                            Sent: Friday, July 01, 2005 9:13 AM
                                            To: scrumdevelopment@yahoogroups.com; agileenterprise.@yahoogroups.com
                                            Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                             

                                            MikeB:

                                            Let’s talk about the following:

                                            >What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                            >when a human agent (person) multi-casts its message, the probability is higher that the

                                            >other N-1 agents will all interpret his/her message as *one and same message*, because even

                                            >if they don’t interpret the message identically at first, they can achieve a *shared model*

                                            >by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                             

                                            When we construct a formal and informal communication topology.  The notion of ‘shared model’ has a tendency to become a dysfunctional artifact, at least in my experience.

                                             

                                            If Scrum Team Charlie holds a daily meeting and there are 7 – ‘pigs’ and 5 – ‘chickens’ in attendance and each communicates to 1 other formal or informal group (made up of only 3 people) their interpretation of the Charlie Daily meeting, we end up with how many derivatives of the Scrum Meeting? Carry this out only one more time. 

                                             

                                            In an environment where all parties and groups are collocated, the probability a shared model of what was said will be reached as people bump into to each other, ask questions, make phonecalls, send and respond to emails.  The problem is that the clock has ticked and the information – as well as the truth it conveyed – ages.  As long as you accept that the truth in an emerging solution changes (a premise for the daily update), you have to ask is the genesis of this ‘shared model’ fast enough to carry reflect the current state?

                                             

                                            Within the team, yes.  With the participants, probably.  With those beyond the participants unlikely.

                                             

                                            As we talk about moving into the enterprise we need to recognize and deal with the ‘ripple effect’ the team’s daily update has on the organization and on the noise it can produce.

                                             

                                             

                                             

                                            Michael F. Dwyer

                                             

                                            Mike.Dwyer1@...

                                             

                                             

                                            -----Original Message-----
                                            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mike Beedle
                                            Sent: Friday, July 01, 2005 8:03 AM
                                            To: scrumdevelopment@yahoogroups.com
                                            Subject: RE: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

                                             

                                             

                                            Mike Beedle wrote:

                                            > In a team of N, there are actually N(N-1)/2 paths, and N(N-1) flows (2 per path)) … that remains true

                                            > even in broadcast or multi-cast mode.

                                             

                                            Just accounting… so things are clear.

                                             

                                            In a Daily Scrum, each member broadcasts 1) what he worked on, 2) what his/her issues are, 3) what

                                            he/she will be work on, to the other N-1 members.

                                             

                                            So each of N agents multi-casts once to the other N-1 agents.

                                             

                                            That’s N(N-1) flows, and N(N-1)/2 paths (subtracting repeated links/edges).

                                             

                                            In each flow, there is something to be learned by the other agents, so the shared models still depend

                                            somewhat on N^2.

                                             

                                            During a Scrum Day, there can be N/2 spontaneous pairs cooperating, or M < N/2 subteams,

                                            cooperating with each other, or (N/2 -1) if N is odd J.

                                             

                                            If agent each has to diffuse NEW information to the other N-1 members, on a one-to-one basis,

                                            then the longest diffusion path would be N-1.

                                             

                                            In the worst case, scenario, all information created new by N agents would have to diffuse

                                            into N-1 nodes to reach all other agents.

                                             

                                            That’s N (N-1) diffusion flows, and subtracting repeated links (edges), that is N(N-1)/2 paths.

                                             

                                            So a knowledge diffusion model in the worst case scenario, is also dependent on N^2.

                                             

                                            What is difference is the probability of information loss, or noise.  In a Daily Scrum, arguably,

                                            when a human agent (person) multi-casts its message, the probability is higher that the

                                            other N-1 agents will all interpret his/her message as *one and same message*, because even

                                            if they don’t interpret the message identically at first, they can achieve a *shared model*

                                            by a process of self-consistency, i.e. until all agents can agree on what the message is/was.

                                             

                                            In contrast, there are still N(N-1) messages in the diffusion, but because the other agents

                                            are not present there, no self-consistency in these messages can be achieved so we are

                                            effectively playing the broken telephone game.

                                             

                                            - Mike



                                            To Post a message, send it to:   scrumdevelopment@...
                                            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                                            To Post a message, send it to:   scrumdevelopment@...
                                            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...




                                            To Post a message, send it to:   scrumdevelopment@...
                                            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



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