How do you do early design with a distributed team?

My experience with remote teams is that you have to get together on a periodic basis. Projects I've been on have had daily or weekly phone conferences with quaterly face-to-face get togethers. All the meetings should have at least an informal agenda. Email and IRC helps. Self imposed deadlines sometimes help depending on the team disposition.

Often my in-person meetings were also occasions for formal presentations regarding design or results. The act of needing to present a coehesive set of charts to provide information/insight to someone else is often an organizing influence. Even if you can't manage to pull everybody together physically, you might at least share presentations and then go through the design together in a teleconference.

I'll concur with the previous post: an essential thing is to keep the thing moving, but IRC or whatever the technology is not in itself the salve -- I have been on projects where IRC was played to death whereas others have used USENET or email very effectively because the management knew what they wanted and their style was destination-oriented. If anything is 'most' important, it is the attention paid to what everyone wants.

An agenda is not a list of topic points to discuss. Think of the phrase "she has a hidden agenda" --- that's the meaning you want. An agenda means knowing what you want; how else would you know when you get it? At the very start of the meeting or even before it starts, state what you want. Also spend time to find out what others expect to get, which is also best idone before the meeting. And stick to those agenda goals. It's ok to get off-topic, we all do, provided the leader can say (as soon as possible) "that's very nice but ..." and pull it back on track. Remember: the auto-pilot in an aircraft spends 99% of its time off course; it's job is to apply corrections, without malice -- it's job is not to apply stifling constraints.

Every meeting will generate more questions and will task people with answering those questions (or asking more) That's where the time-shifting collaborative technology can be useful: Post the meeting notes clearly stating all reponsibilities, then pester the primes for results (or at least some change in status).

Project planners often don't know what they want until they see what they don't want; plan for improvisation and allow for experimentation. Goals are fine, but not if they blind you to possibilities. Try things, as rapidly as possible. The most volatile document is always the business requirements; only fools ask for those up front.

People need to feel included and engaged. If there are two arguments that can't reconcile, seek a demonstration of both; at worst, you've re-affirmed to those two that you value their ideas and that you are willing to try anything that might bring everyone closer to the actual business goals. Ask more than you tell, listen more than you speak.

Try this, just for fun: Put 10 pebbles on your desk; every time you want to voice a response, over whatever medium, move one pebble to the other side of your desk. Try to do the whole meeting only moving the pile of 10 stones just once. You'll have to choose every response very carefully.

Notice how all of my advice has nothing whatsoever to do with colocation proximity or the medium of the exchange? Put another way: bad leadership is medium agnostic -- it can fail to evoke results over any communications channel ;)

I've been on several distributed design teams, starting with the team that designed NFL Challenge in the early 1980's (we used CompuServe for email and file transfer) on up to the present, where modern tools make working remotely close to effortless. Each one has been a success, which is not a statement I'm able to make about projects where everyone worked in the same office.

The distributed teams had the following in common, which I think were key factors in their success:

1. the teams were small (2 to 5)

2. everyone on the team knew what they were doing

If you can arrange that, geography really shouldn't matter at all.

There's an old saying, and I'm sorry I don't remember the source, but it says that there has never been an elegant system designed by committee. I think it is true. In my own projects, I try to get the system fleshed out into at least a prototype state before inviting additional developers to join in. Once I get something into a relatively workable stage, even if there are major features missing or other major shortcomings, at least there is already a clear vision and a clear design in place for people to latch onto and understand and build upon.

I have been going through exactly this in Lampadas, because I had a slew of developers show interest, if we could develop in Python. One of them put together an initial Python implementation, and I didn't like the way it was done. Probably my own personal biases and preferences, it was probably just fine. But I found it uncomfortable to work in. So I started once again to do my own initial implementation, to show how I wanted things to be done. Playing the part of benevolent dictator, if you will. The part of me that believes in democratic processes doesn't like putting my foot down and saying this is how it shall be done!, but the software engineer in me says that having one person, or at least a small team of people who already work together and share mutual values and philosophies, do the initial architecture is the way to go.

Of course, it will all change at some point down the road anyway. Build the first one to throw away, because you will anyway, you know the saying. That's another one I have found to be very true.