Re: [epf-dev] Reflections on Collaboration

[Mark.Dickson@xxxxxxxxx]

Hi Steve

Good email.

I support your central point here - "collaborative practices are about creating a fast decision culture." I often discuss "collaborative software development" as a distinct way of working (and presented a paper on it myself at the Agile Business Conference in 2005). I'll try to summarise some of the characteristics of collaborative development, as they appear to me.

- people work together primarily through personal interaction rather than documentation, models or code. This might sound obvious but believe me, I've seen the "software factory" concept bastardised into "the analyst writes the use case spec and gives it to the designer; the designer creates a UML model and passes it to the programmer;..." Everyone has horror stories like this and they don't seem to be drying up.

- as part of the above, the Customer is part of the team. They have real work to do - much more than being a passive, local business representative. An example of this is the DSDM "Ambassador User" role but there are plenty of other examples in DSDM, Scrum, XP, etc.

- Work is done in groups. IMHO, the best UML models are produced by 2-3 people around a whiteboard. The best use case specs are written in workshops of 3-5 people. A telling characteristic of a collaborative approach is lots of workshops (and a good level of background noise in the office)

- the team in empowered to make decisions. This is essential to building a fast decision culture. No empowerment - no decisions are fast.

 

There are lots of secondary aspects - open, honest communication; daily standup meetings; etc - too numerous to mention here. The above points are the most significant to me (or at least, the ones I can remember right now).

 

In essence, these are themselves aspects of a number of things from the Agile Manifesto -

"Individuals and actions over processes and tools"

"Customer collaboration over contract negotiation"

and the principles -

"Business People and developers must work together daily thoughout the project"

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done"

"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

 

Cheers

 

Mark

Mark Dickson
SAE Practice
m 0780 1917480
w www.xansa.com
e mark.dickson@xxxxxxxxx

-----epf-dev-bounces@xxxxxxxxxxx wrote: -----

To: <epf-dev@xxxxxxxxxxx>
From: "Steve Adolph" <steve@xxxxxxxxxxxxxxxxx>
Sent by: epf-dev-bounces@xxxxxxxxxxx
Date: 05/28/2006 07:16PM
Subject: [epf-dev] Reflections on Collaboration

 

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

 

1. ??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.
2. ?? 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

Whilst this email has been checked for all known viruses, recipients should undertake their own virus checking as Xansa will not accept any liability whatsoever.

This email and any files transmitted with it are confidential and protected by client privilege.  It is solely for the use of the intended recipient.
Please delete it and notify the sender if you have received it in
error. Unauthorised use is prohibited.

Any opinions expressed in this email are those of the individual and not
necessarily the organisation.
     Xansa, Registered Office: 420 Thames Valley Park Drive,
     Thames Valley Park, Reading, RG6 1PU, UK.
     Registered in England No.1000954.
     t  +44 (0)8702 416181
     w  www.xansa.com