| RE: [epf-dev] Reflections on Collaboration |
|
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:
The reasons for collaborating are:
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 From:
epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Steve Adolph"
<steve@xxxxxxxxxxxxxxxxx> 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):
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 _______________________________________________ |