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 <at> yahoogroups.com [mailto:scrumdevelopment <at> yahoogroups.com] On Behalf Of Mike Beedle
Sent: Friday, July 01, 2005 12:14
PM
To:
scrumdevelopment <at> yahoogroups.com; agileenterprise. <at> 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 <at> yahoogroups.com [mailto:scrumdevelopment <at> yahoogroups.com] On Behalf Of Mike Dwyer
Sent: Friday, July 01, 2005 9:13
AM
To:
scrumdevelopment <at> yahoogroups.com; agileenterprise. <at> 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.
-----Original Message-----
From:
scrumdevelopment <at> yahoogroups.com [mailto:scrumdevelopment <at> yahoogroups.com] On Behalf Of Mike Beedle
Sent: Friday, July 01, 2005 8:03
AM
To: scrumdevelopment <at> 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 <at> eGroups.com
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe <at> eGroups.com
---- LSpots keywords ?>---- HM ADS ?>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 ?>
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 ?>
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 ?>
SPONSORED LINKS
Mishkin Berteig
mishkin <at> berteigconsulting.com
RSS Feed