ldrews | 1 Jul 01:33 2005
Picon

Réf. : Re: Team Member Performance Reviews under Scrum - any

--- In scrumdevelopment <at> yahoogroups.com, gery.derbier <at> s... wrote:
> >how well I play with others.
> Could you give me a clue at how you measure that ?
> 
> Géry.
> 

<grin> Well, I don't have any standard metrics, if that is what you
mean.  How about: arguments per sprint, smiles per day, voted most
congenial member of the team?  I am open to suggestions.  What
measurement would you use?

-Larry in Florida

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

ldrews | 1 Jul 01:37 2005
Picon

Re: Team Member Performance Reviews under Scrum - any gui

--- In scrumdevelopment <at> yahoogroups.com, "Wayne Allen" <wallen <at> c...>
wrote:
> 
> While I agree that not all team members contribute equally, the
measure of working harder is not the one I wish to reward. I have had
many individuals who worked "hard", but often they were busy fixing
problems they had introduced earlier. I would rather reward those who
worked smarter, eliminated an entire class of problems, was courageous
enough to point out the elephant in the living room, etc.
>  
> Wayne
> 

So, if I am one of the latter type of team members, are you going to
reward me more than the former types?  If not, other than the joys of
participating, why should I break my a** to do the heavy lifting?

-Larry in Florida

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

berteigconsulting | 1 Jul 02:24 2005

Re: Maximum Size of Scrum Team

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

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

Mishkin Berteig
mishkin <at> berteigconsulting.com
http://www.agileadvice.com/

--- In scrumdevelopment <at> yahoogroups.com, "Wayne Allen" <wallen <at> c...>
wrote:
> I guess I wasn't clear. We didn't ask each individual person the 3
questions, we asked the 3 questions about the active backlog items.
Since we typically had 3-5 active backlog items 10 min was plenty of time.
>  
> This was an optimization for this particular team as classic
stand-ups were taking in excess of 20 min, yet there wasn't any real
reason to break the team up.
>  
> Wayne
> 
> ________________________________
> 
> From: scrumdevelopment <at> yahoogroups.com on behalf of David H.
> Sent: Thu 6/30/2005 2:58 AM
> To: scrumdevelopment <at> yahoogroups.com
> Subject: Re: [scrumdevelopment] Re: Maximum Size of Scrum Team
(Continue reading)

Mike Dwyer | 1 Jul 04:15 2005
Picon
Picon

Interesting and Thought Provoking Read

I am re-reading Rob Austin’s Artful Making  (3rd time) because he seems to have some good thoughts on

 

What defines done.

Ensembles

Reconceiving

 

That add insight to all the discussions except performance reviews.   His other book covers that.

 

What thinks these groups?

 

Michael F. Dwyer

 

Mike.Dwyer1 <at> comcast.net

 

 



To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com

---- LSpots keywords ?> ---- HM ADS ?>
Ron Jeffries | 1 Jul 04:25 2005

Re: Re: Maximum Size of Scrum Team

On Thursday, June 30, 2005, at 8:24:15 PM, berteigconsulting wrote:

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

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

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

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

Ron Jeffries
www.XProgramming.com
If you're not throwing some gravel once in a while,
you're not using the whole road.

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

berteigconsulting | 1 Jul 04:53 2005

Re: Maximum Size of Scrum Team

--- In scrumdevelopment <at> yahoogroups.com, Ron Jeffries
<ronjeffries <at> 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 <at> berteigconsulting.com
http://www.berteigconsulting.com

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Paul Hodgetts | 1 Jul 08:17 2005

Re: Re: Maximum Size of Scrum Team

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Mike Beedle | 1 Jul 13:13 2005

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

 

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



To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com

---- LSpots keywords ?> ---- HM ADS ?>
Simon Baker | 1 Jul 13:25 2005
Picon

Re: Maximum Size of Scrum Team

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Mike Beedle | 1 Jul 14:02 2005

RE: 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 <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com

---- LSpots keywords ?> ---- HM ADS ?>

Gmane