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

Re: [scrumdevelopment] Re: Maximum Size of Scrum Team

Expand Messages
  • 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 1 of 20 , Jun 30, 2005
      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 2 of 20 , Jul 1, 2005

         

        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 3 of 20 , Jul 1, 2005
          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 4 of 20 , Jul 1, 2005

             

            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 5 of 20 , Jul 1, 2005
              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 6 of 20 , Jul 1, 2005
                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 7 of 20 , Jul 1, 2005

                  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 8 of 20 , Jul 1, 2005

                     

                    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 9 of 20 , Jul 1, 2005

                      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.