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 Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com
Mishkin Berteig
mishkin <at> berteigconsulting.com
RSS Feed