Hi Steve,
You’re right that the notion of
collaboration has come to mean “better communication than average”
in the software development community, and at the same time there’s no
clear definition of collaboration. I think one of the benefits OpenUP
can
provide over the current state of things is to push the definition of
what
collaboration is - to make a highly collaborative environment something
very desirable
and effective. And probably difficult to achieve.
We could take the perspective that
collaboration is a desirable set of behaviors in an organization.
Collaboration
need not be about reaching some certifiable nirvana where an
organization has
the official stamp of “collaborative.” It could be a set of
behaviors that an organization is always working towards improving.
There’s
never an end to an organization’s collaborative skills.
Here’s a definition of collaboration
I’d like for us to consider:
Collaboration: The cooperative behavior of
a group of people empowered to solve a clearly defined problem. A
collaborative
group identifies their own objectives. The performance of an individual
is
primarily measured by the performance of the group against the
objectives. All
members of a collaborative group have an equal voice and authority
within the
group.
In other words, collaboration involves
three critical aspects:
- A clearly defined problem the group is responsible for
solving. The problem is never to build the software application. The
problem is the business or technical problem that creates the need for
the software, e.g. “Our customers are frustrated and dissatisfied with
the errors in mortgage processing. We’re losing 5% of our customers
every month to our competitors.” This might be addressed by a primary
objective of: “Increase revenue by 20% by significantly reducing
processing errors, and reducing mortgage processing time by 50%.” The
job of the software team is to solve the problem by writing software
that reaches that objective.
- Group members are equal partners in achieving the
objectives that will solve the problem. There may be some who are
“first among equals”, but this kind of collaboration implies that the
boss is usually not a group member (although the boss may be in charge
of the group).
- Collaboration requires that people take most of the
focus off themselves and put it on the problem being solved. Instead of
trying to “win” by getting one’s own solution accepted, or running off
to solve a problem on their own, individuals in a collaborative
environment leverage the skills of the entire group. Group members are
assessed primarily on how well the group performs and how effectively
they leverage the group as a whole.
The reasons for collaborating are:
- Less risk in defining objectives and making decisions.
The more eyes and brains on a problem, the easier it is to solve.
- Decisions are quicker when the focus is on the group’s
problem and objectives rather than solely on personal agendas.
- A highly collaborative group requires less oversight
(lower management overhead).
- Errors are less likely to arise, in general, when
everyone is responsible for the entire group. Fewer things will be
allowed to fall through the cracks.
- Members of a highly collaborative group are the most
satisfied members of an organization.
There are also reasons for not
collaborating that we should elaborate, such as emergency situations
and
low-trust environments. We also need to indicate that teams need
experience,
discipline, and time to become collaborative.
Thanks,
Jim
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer
email: jruehlin@xxxxxxxxxx
phone: 760.505.3232
fax:
949.369.0720
Good morning everyone:
Well it’s been a while since we have had a good
controversy going
on this mailing list and I thought I’ll try and lob a little nuke into
the mix and see what happens. Ok maybe not a nuke, but perhaps a rather
large
fire cracker J
I’ve reflected on our Friday morning tele-con and realized
that
we may have some divergent views regarding collaboration. Part of the
problem
is collaboration has come to be seen as “good” and therefore a
required buzz word in any process definition. Further collaboration has
a very
broad and general definition, usually something along the lines of
“...people working together…” Obviously two or more people
working on the same software project are supposedly working together.
They may
detest each other but as long as they do not actively attempt to
subvert the
other we could consider them as collaborators. I think with respect to
OpenUP
we have an implicit collective definition of collaboration as
”…people working together effectively…” So what do we
mean when we say collaboration or collaborate is one of OpenUP’s core
concepts?
From what I can recall from our conversations I believe
there are at
least two views regarding the purpose of collaboration. One is we
collaborate
to achieve higher quality results, that is collaboration is akin to
consensus
decision making. The second view is we collaborate to increase our
decision
making velocity. While these two views are not incompatible, neither
are they
fully compatible either.
My personal view is we collaborate in OpenUP to increase
decision
making velocity. This view is based on the proposition that decision
making
velocity is the determinant of agility. Therefore the proposed OpenUP
collaborative practices are social practices intended to increase
decision making
velocity of both individuals and the team. The collaborative practices
align individuals with reality and empower individuals to take the
initiative
harmoniously with the rest of the team and in alignment with the
interests of
the stake holders
The collaborative practices are about providing a
foundation for a
social system from which a rapid decision making culture may emerge.
They are
intended to ensuring people have a common shared vision of the system,
understand the objective of their tasks and given the opportunity to
take the
initiative to accomplish their task. A high trust environment makes
people feel
safe taking the initiative and furthermore speeds decision cycles
because trust
lowers transaction costs in negotiations (Social capital Francis
Fukuyama).
This view of collaboration is of course influenced by the
research I
have been doing into Colonel John Boyd’s Observe-Orient-Decide-Act
loop,
fast decision cycles, and agility. I am presenting a paper on this same
topic
at Agile 2006.
Ok, now what about collaboration as consensus? There are
in general two
common meanings for consensus (see wikipedia.org):
- “…a general agreement among the members of a
given group or community, each of which exercises some discretion in
decision making and follow-up action…” This is a view of consensus that
supports rapid decision making. Consensus is implicit to
maintaining the shared mental model of the system. All members of the
team are in agreement of the status of the system, the objectives, and
the methods for accomplishing those objectives.
- “… a theory and practice of
getting such agreements (for information on the practice
of achieving formal consensus…” The intention here is a
decision making process which potentially yields higher quality results
and keeps people engaged (buy-in) with the project.
As a decision making process I am concerned that consensus
is not
optimal for making decisions in a time constrained environment. While
it may
yield a better quality decision there is Patton’s paraphrase of
Voltaire
“A plan violently executed today is better than a perfect plan executed
tomorrow”.
So where is the nuke in all this? Ooops, I mean the fire
cracker.
Simply, the fire cracker is trying to obtain consensus on what are we
mean when
we say collaboration. We are all probably in agreement this means
working
together and sharing information but to what end? Is it to make higher
quality
decisions or to speed up the decision making process? These two options
are not
diametrically opposed, but neither are they fully compatible either. My
personal view is our collaborative practices are about creating a fast
decision
culture.
That is my two cents worth…chat with you all next Friday,
Steve
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev