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

Re: [scrumdevelopment] Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.