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

Scrum as an Intelligent, Autonomous, Self-Interested, Self-Orgnizing Mutli-Agent

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