How do you do early design with a distributed team?
Posted 15 May 2002 at 02:04 UTC by andrewgilmartin
The Engineering and Agile processes have a life-cycle stage that
happens just after the elaboration is done or the stories have been
told when the team works on the early design. It does not matter if the
design anneals as UML diagrams or test cases there is always the
intense discussion about how "it" should be. "It" includes not only the
parts -- actors and collaborators, entities and voyeurs -- but the
principles too -- how much should be fixed, how much flexible, how much
programmable, how much configurable?
In my experience working it out has always been done by a co-located
team. They are in the same room and they walk the same hallways. Time
is spent together to discuss and time is spent apart to ponder. This is
done several times over a short period of time. "Rinse and repeat."
What happens when the team is not co-located? I am running such a team
now and this stage is going slowly. More slowly then I have ever
experience before. I feel we are missing something. I really don't know
if it is tools or techniques or even the players. I need your help. How
have your distributed teams teams worked it out?
My experience, posted 15 May 2002 at 03:53 UTC by aero6dof »
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
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
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
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.