What Is the Best Way To Build a Virtual Team? 175
stoolpigeon writes "The department I work in is growing and including new members that live quite far apart. Right now most people are in the same office but new members are in Singapore and South Africa, with more coming from other places. I would be interested in Slashdotters' recommendations for software, practices, services and anything else that can help build strong virtual teams."
Re:IRC (Score:5, Insightful)
Seconded. IRC works great for group discussions. Most IRC software is also very customizable in what messages should cause it to pop up or alter you, so you can continue working concentrated when needed. You can easily move from group discussion to 1-on-1 or seperate chats if needed.
You can also leave an IRC client running and see discussions that happened when you were away/asleep, which is nice if there are timezone differences.
I've used Jabber on a previous job, because this was supposedly more secure, but I don't think there's any advantage over IRC+SSL.
Skype doesn't work as well in my experience, as it's less customizable. During the working day, I want to have my colleagues able to interrupt me, but not my friends. Separate accounts isn't really a good solution for that. Maybe there's add-ons for that?
Patience, language, and other tips (Score:5, Insightful)
1. UK ENGLISH IS NOT INTERNATIONAL ENGLISH. AMERICAN ENGLISH IS NOT INTERNATIONAL ENGLISH.
Avoid slang and colloquialisms if anyone new is in the conversation. Think HARD about what might be slang or idiom. Be particularly careful to avoid phrases where the meaning is the opposite of the individual words.
Learn what "mistakes" are common in speakers from particular countries and learn how to go around them. Often non-native speakers will use academically correct English which sounds imperative and aggressive to idiomatic speakers. e.g. "I'll have John look at that" is perfectly natural American English but sounds imperialist even to English English speakers. I've noticed Indian staff often do the opposite and what should be "you must, otherwise this project is doomed" becomes "if you don't mind when you can get around to it if it's not too much trouble."
2. Remember cultural references are not universal, despite Coca-Cola Co's best efforts. Watch out for this when drawing analogies, especially with TV shows, social situations, and personal money.
3. Be patient. It's not anyone's fault that you were born 9000 miles apart. If a communication doesn't make sense or seems offensive on first sight, check.
4. Quick phone meeting every day is essential. Try and find a slot that isn't the end of day for anyone (can be tough to do that depending what timezones are involved.) And I do mean quick - 15 mins - and have a tight agenda e.g. "UK hotspot/news, India hotspot news, Singapore hotspot/news." Be careful about what "today" and "tomorrow" means in practice. "End of tomorrow" is probably "first thing the day after tomorrow" for someone on the call.
5. Unified Comms is great if used properly, but do remember it's not face to face conversation and works on different assumptions. Instant messaging is particularly dangerous because written English and spoken English do not operate on the same set of assumptions; but in IM it's tempting to mix it up. I ran two similar projects in a bank two years apart; the second time, we had Office Communicator and it made the whole thing a HELL of a lot easier. I was astounded by how useful it was.
6. In a virtual team, it's very likely that not everyone in the team will be in the team full-time. Be aware of that and don't assume that "four hours work" means that it will be done the same afternoon. Ask.
7. Notice how far down this list technology is...
Re:Offshore? Traitor! (Score:2, Insightful)
you're, not your
Times three. The GP makes me think I should just hire Indians instead, both bastardize the English language but the Indians are cheaper...
10 suggestions: For what it's worth (Score:5, Insightful)
1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress [wordpress.org], regardless of whether you like PHP/MySQL or not.
2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring [fastspring.com], Plimus [plimus.com] are free; Chargify [chargify.com], Subsify [subsify.com], Cheddar Getter [cheddargetter.com], BrainTree [braintreep...utions.com], Spreedly [spreedly.com] charge; and Zuora [zuora.com] is expensive.
3. Use Google Docs [google.com] and Slideshare [slideshare.net] to share documents.
4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype [skype.com], Jabber [jabber.org], SIP [wikipedia.org]
5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim [zim-wiki.org], Projly [projly.com], DokuWiki [dokuwiki.org].
6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice [google.com] and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.
7. Someone mentioned version control. Use git [git-scm.com] if you're a cool kid. Or svn [tigris.org] if you're old and busted. Read the RedBean book [red-bean.com]. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN [tigris.org] (integrates into Windows Explorer).
8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit [junit.org], PHPUnit [github.com], FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development [c2.com].
9. If you're writing tests, that implies loose coupling [thesoftwar...tional.com], which might require dependency injection [potencier.org]. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.
10. Development processes: Scrum [wikipedia.org], Extreme Programming [extremeprogramming.org]. UML [uml.org] lets you communicate graphically about objects.