
Being Successful as a Distributed Team - bradleyjoyce
http://squeejee.com/blog/2009/10/28/being-successful-as-a-distributed-team/
======
jlees
Something this article doesn't mention, but was crucial (IMO) to the success
of the Weblogs, Inc virtual team I worked in for a long time, was real-world
meetups. (I believe Jason Fried alluded to this as well at Startup School.)

Campfire, IRC, IM, Skype and active chat email lists are all great for feeling
connected to people, but the first time I really felt _part_ of the company
itself - not just a remote node on a graph - was when I covered an event and
hung out/coordinated with a load of other bloggers doing so. It really
instilled a sense of camaraderie - it was a very high pressure task and it was
great that we had been working together virtually for so long (and that some
of the others had worked together in person before too), as that avoided some
of the uncomfortable situations that can occur if a group of strangers tries
to achieve something in a short space of time.

Obviously this only really worked for the blogging/journalis model, but
sending a group of devs to an engineering conference, having a team retreat
(we also did this but as I was in the UK, I never got to go) and generally
finding excuses to hang out productively a couple times a year really makes a
big difference to the team feeling, in my experience. It might be slightly
different if you're writing code, not articles; mind you, at least if you end
up disliking your cow-orkers in person, you don't have to spend that much time
with them!

------
zenocon
I did this for three years as a consultant. I worked from the home office (US)
3-4 weeks, and then travel to Europe for a one-week co-lo...rinse, repeat. We
grew from 7 people up to 3-4 teams with about 30-40 people. In the end we had
a well-oiled machine. What made it effective: good engineers, good build,
continuous integration, and co-lo whiteboard design sessions (can't say enough
about that last one).

I wish there was a job board that highlighted companies that use distributed
teams and are looking to draw talent without requiring re-location.

~~~
tocomment
how does the whiteboard thing work?

~~~
zenocon
I mean a real whiteboard with real people in the same room and some markers :)

We would alternate one week co-located and have intense design sessions in
smaller teams, then go back to our own time zones and code it for 3-4 weeks.

I've looked at a lot of digital whiteboard solutions, but honestly nothing
compares to the real thing. I feel this is still an unsolved problem, and a
good startup idea.

------
lkrubner
You will lose some time if you use a distributed team. I've seen 4 people
spend all day in the same room with each other, talking, and even then it can
be hard for each person to communicate to the other people what they are
really thinking. When you are not in the same room, things slow down even
more. Communication gets harder.

If you are working on the kind of project that needs to ramp quickly, then the
whole project should try to adhere to agile practices. Agile practices have 2
main hopes:

1.) to allow a fast-forming team to quickly become highly-productive.

2.) to control costs by ensuring discipline in regards to goals and deadlines.

I use the word “hopes” instead of “goals” because the ultimate aim of agile
practices is more of an ideal to be aspired to rather than a reality that can
be achieved, and by that, all I mean is that we are constantly learning more
about what these practices mean, and in the future we can reasonably hope to
do better than we are doing today.

Programming is an art, and art needs passion. Many agile practices are aimed
at soliciting a greater emotional commitment from the programmers. I might
write “For an agile project to go well, the programmers need to emotionally
commit to it” but that isn’t quite right. What would be more correct would be
“For an agile project to go well, the programmers need to emotionally commit
to their own professional ideal.” That is, they need to care about the craft
of programming. They need to be constantly pushing themselves to always be
better programmers.

I would never argue that agile practices are needed on every project. If a
project is routine, then long-distance, non-agile practices might be perfect.
For instance, suppose you decide to launch a new online magazine. After
researching your options, you decide you will use WordPress as the software
that powers your site. I’d suggest you find a good designer, local to you, and
work with them to come up with the design. Once you have the design, the rest
of the process is mundane. You could certainly hire a team in India to install
WordPress and implement your design for you. And you would not need agile
practices for such a project. In fact, you do not even need great programmers
for such a task. Mediocre programmers can do a reasonable job with tasks that
are standard, routine and mundane.

However, I would argue that agile practices are needed at projects that need
to be fast moving (this would include most start-ups), or at any project where
the aim is to create something altogether new and unique. If your project is
venturing out into the great unknown, if you are going where no one has ever
gone before, you will need a team of excellent, committed adventurers to go
along with you.

Many agile practices depend on physical proximity. The programmers need to be
able to meet, preferably every day (”every day” in the sense of casual
conversation, not “every day” in the sense of “let’s have a formal meeting”).
Consider some of these practices:

1.) pair programming (two people looking at the same screen, checking for
errors)

2.) the use of index cards to map objects

3.) stand up meetings (meetings kept short and lively because everyone is
standing)

None of these make any sense if the programmers are in different countries (or
different parts of one country).

Again, for routine work, I think a distributed team can be fine. But for a
startup, I would always insist that the team be in physical proximity.

~~~
zenocon
Some fine points. I agree about the quality of the people and the passion, but
I disagree that distributed teams only work for routine work. I worked on a
large, complex project wherein we re-built a company's internals from scratch.
The details are moot, but the point is we executed like a startup -- we had
protection from management, and it worked well. There were bumps in the road,
but we continually evolved the process (yes, we did agile) to make the team
more and more effective every iteration.

Standup was done via phone every day adjusted to meet time zones.

Pair programming was done with VNC when we needed it -- mostly used to mentor
/ bring on new employees who need hand-holding.

We did not use index cards to map objects. We did do the following things at a
one-week-long co-location: 1-2 days of planning and 2-3 days of
whiteboard/design. Iterations were typically 2-3 weeks long after that.

I've used this same model at the last couple of contracts I've done and it can
work very well if done right (e.g. right people, right tools, right process,
right mgmt).

------
bjelkeman-again
I pretty much agree with what he says. We use a different set of tools, but
they largely do the same job.

On the "People management" I think that the key thing is finding the right
people. I manage our software development team and there is a big difference
to being in the same room, or the same building, which I have done at previous
startups, with several of the same team members.

You have to trust people and you have to allow them to do the job. I have
always tried to hire people I trust to do the job, but when they are anything
from one to nine time zones away there is no conceivable way I could "monitor"
them and make sure they do their work. If I tried to suggest something like
Webspy (as suggested in the article) to "check up on them" I would be first in
line to kick myself out of the room. It is all results based. Did you get what
you expected at the end of the day/week?

There are certainly drawbacks with not being in the same room. How I would
love to be able to round em all up more often and have a whiteboard session
(not sure they want that too though... :)). But on the other hand you get very
independent and self propelled colleagues instead.

We try to have a group get together every 6 months, but it isn't always
feasible, but you really notice the increase in "bandwidth" when everyone is
in the same room for a couple of days to a week.

Would I want all of my team in the same town? You bet. Could I have assembled
my team or one like it in the same town? With great difficulty. So, overall,
we are better of with a distributed team, as the alternative would be to have
no team. But it isn't always super easy.

~~~
the_real_r2d2
We have been working remotely for a while. It is difficult but it can be done.
I would like to add a couple of applications that we have used to make our
life easier:

\- Etherpad.com for real-time document colaboration \- Google documents, if
privacy is not a concern

Also, because it is very difficult for us to get together, every time that we
can do it we try to maximize the time (no dumb and useless meetings, going
straight to the important points, etc.). As result, our face-to-face meetings
are very productive.

