- 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

Agreed on the /2, my mistake.

> path)) . that remains true

> even in broadcast or multi-cast mode.

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

Ron Jeffries

www.XProgramming.com

Computers are useless. They can only give you answers. -- Picasso - 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

I agree that broadcast mode communication, conversation, information

> 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.

>

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 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.

-----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-AgentMike 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 evenif 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,

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-AgentMikeB:

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.

-----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-AgentMike 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 evenif 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@...`

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.

-----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-AgentMike,

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-AgentMikeB:

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.

-----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-AgentMike 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 evenif 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@...`