Let's explore a bit how one sets up teams, and how they might communicate.
It seems that setting up teams is like deciding how to partition an application across network processors. We want to put people together who need to communicate a lot, and we allow ourselves to separate people who don't need to communicate a lot.
With this in mind, we wouldn't separate the guy doing the parser from the guy doing the code generation, but we wouldn't mind so much separating the C++ compiler project from the team building the communications library.
We would keep the people doing payroll together, and the people doing general ledger together, but we wouldn't mind so much separating the two projects.
The principle is to minimize communication across a difficult boundary. A difficult boundary in programming is a network or processor boundary, compared to an ordinary call or message send. A difficult boundary in human communication is separation. It is said that putting people one floor apart reduces their communication by something like 80%.
Since it's difficult to communicate across physical separation (and since that communication is more error-prone), we try to minimize the material that needs to be sent across.
The payroll guys, therefore, really need to agree on the format of data sent to the general ledger. It's merely a convenience, however, if they name their internal variables the same way, or if they manage to reuse some of the same objects. The one is necessary - the other is just desirable.
The communications library guys need to know the eventual syntax of the language, but they don't need to know how the compiler works. (Although in C++ it can be a big help ...)
The necessary material to communicate across the boundary: interface. Java has been rather successful in communicating among all its users by publishing the APIs. The language is trivial and well-understood. We can write programs that work together if we all use the same APIs.
So, if we have to do a project with distributed teams, we break up the teams along boundaries that will minimize communication across them. And we devise our communications to
minimize unnecessary communication - because it's expensive and error-prone;
maximize understanding when we do communicate across the boundary.
Now we can look at the various forms of communication across boundaries, and assess when and how to use them. We might consider:
briefings - largely one-way high-level transmit only
meetings - largely two-way give-take
live demonstrations - one-way transmit. what about impact compared to briefings?
training courses - largely one-way, more detail. techniques needed?
phone calls - two-way, limited topic, limited circle of knowledge
design documents - very one-way. high volume, low applicability to a given reader
wiki - a living n-way design document. increases?? applicabilty to a given reader because everyone is responsible. reduces?? formal gobbledygook.
video phones - two-way, larger circle, less prone to communication errors than voice phones (you see if one is distracted and not actually listening)
integrations - putting both pieces of software in the same environment and running them at the same time
programming episodes - writing concrete code with one member of each team
joint refactoring - first find two pieces of very similar code in both systems, then get together (big room with a projector attached to the workstation?) and refactor until they are the same
and so on - please add more and comment on these.
bagels on thursday morning - n-way inter- and intra-team about unofficial issues
I've been doing the extreme case of Distributed Teams for three years now. I've supported development teams in California and Oregon while living and working in North Carolina. I'm a technical writer, and I need to be closely coupled to the development team. It's a challenge.
Here's what I've learned.
Face time is essential. I fly out to meet my co-workers once a month at a minimum. While I'm there, we have handwaving whiteboard meetings, I read the emotional temperature of the team (do I believe the ship dates? Is new content trembling on the brink?), and I establish the human contact that makes cooler conversations over mail and phone possible. Face time builds trust.
Video technology isn't there yet. The time lag is excruciating. You can't interrupt, as you do in a normal meeting, because the person you're interrupting has already moved on. Affordable-bandwidth videoconference setups blur faces, so you lose the vital emotional content. The equipment breaks down and glitches frequently. It's still much too expensive. It isn't good enough, but sometimes it's all you have.
Nobody except me knows what's essential communication. I make sure I'm on every mailing list even dimly related to my project. On most of these lists, I keep my mouth shut and listen. I'd far rather get too much information than too little.
I need an agent. I depend on my co-workers who are in the site to keep me up on water-cooler gossip, do physical things (like hand-delivering review copies to recalcitant reviewers), and check on meetings that have forgotten to speakerphone me in.
How would I generalize to the distributed-development team problem? I'd task one person on each team, somebody who was a natural gossip and networker, as "ambassador" from the other team. This person would be responsible for keeping the other team in the loop. Every time she heard something she thought the other team should know, she'd pass it on. She'd speak up for the other team's interests during meetings at which, through some oversight, they were not included. And I would include frequent same-site planning meetings for the entire team in my budget.
--Betsy Hanes Perry, virtual team member
See original on c2.com 