Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Businesses Communications IT

What Is the Best Way To Build a Virtual Team? 175

Posted by samzenpus from the make-sure-they-don't-play-warcaft dept.
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."
This discussion has been archived. No new comments can be posted.

What Is the Best Way To Build a Virtual Team? More

What Is the Best Way To Build a Virtual Team?

Comments Filter:

  • Keeping in touch plenty! (Score:4, Interesting)

    by Stooshie ( 993666 ) on Thursday April 14, 2011 @02:32AM (#35815382) Journal
    Try to have a quick team meeting meeting every day on Skype/VOIP, if possible. People can start to stray "off message" if left to themselves too long (not through laziness, or anything). If they are in the same office, that can is normally regulated.

    Lots of small targets as well as an overall project target.

    Do try to have face to face meetings occasionally.
    • Used to work with people in China, France and Poland and completely agree, good regular communication is the key. And if people can have some face time to put a name to a face and bond then all the better.

    • Re:Keeping in touch plenty! (Score:4, Informative)

      by Malc ( 1751 ) on Thursday April 14, 2011 @03:10AM (#35815530)

      As somebody who's been doing this for over a decade, let me emphasise the importance of this. You will need a good travel budget, and you will need to be willing to make sacrifices in your personal life, in addition to ensuring other good and regular communication commitments.

      I've just got off our weekly engineering call that went for the last two hours (10pm California, 6am London and 1pm Shanghai). Yawn. Somebody always gets the arsehole timeslot with this many timezones. We've managed to keep it down to one of these a week, with some extra duplicated two time zone meetings in between. Any less and things noticeably fall between the cracks quickly.

      • I'm finding this topic interesting, but a little surprising that so many people are on such geographically dispersed teams. Is it worth it? What is so special about one guy's coding expertise that it's worth going half way around the world for? I'm not disputing it, I just want to understand.

      • I've just got off our weekly engineering call that went for the last two hours...

        I also happen to be part of a geographically dispersed team that has weekly conference calls via Skype. IMHO (and a few others'), the calls are largely a waste of time. I know what my job is. I can work independently. For everything else, e-mail is just fine.

        For most of the call, I'm actually doing real work in another window and pretty much ignore the call because it's about talking about other aspects of the project that

        • Re: (Score:2)

          by tobiah ( 308208 )

          BTW: don't some very famous, large, geographically dispersed software projects get along just fine without weekly conference calls? Apache, GCC, and Linux come to mind.

          I was wondering the same thing. I've worked in similar situations, and gone months without voice calls or facetime. Just email, IM, bugzilla, etc. worked ok for those projects.

        • BTW: don't some very famous, large, geographically dispersed software projects get along just fine without weekly conference calls? Apache, GCC, and Linux come to mind.

          The other thing(s) those projects also have in common are, not needing to meet a budget, not needing to meet a schedule, etc... etc... They're also (largely) worked on in people's spare time - they wouldn't reliably be available for a phone call in the first place.

        • I'm a little confused how you can just sit there not paying attention and that doesn't have any negative consequences. To me, that indicates that the wrong people are on the call. If everybody on the call doesn't have something to contribute to each part of the discussion, then what you've done is taken what is actually two or more teams and glued them together to make a "team" that's not really a team. Now you are mutually wasting everybody's time.

          Using email instead of speaking with your voice is also a c

          • I'm a little confused how you can just sit there not paying attention and that doesn't have any negative consequences. To me, that indicates that the wrong people are on the call.

            Well, it's been nearly 2 years and nobody has reported any negative consequences (aside from the fact that the call tends to waste people's time). The call is comprised of the entire team: that's why it's called a weekly team call. Therefore by definition, there can be no "wrong" people on the call.

            If everybody on the call does

    • Re: (Score:2)

      by Eraesr ( 1629799 )
      Another important thing is to be aware of cultural differences and deal with them. I'm not talking about fundamental Christians having to work together with extremist Muslims or anything on that scale, it's just that cultural differences lead to different interpretation of facts or requests and assumptions made on different grounds.

      For instance, we used to work with a group of people located in the Ukraine (us being in the Netherlands). Turned out that in ex-soviet countries, the culture is still to never

      • Re: (Score:2)

        by osgeek ( 239988 )

        That all stems from a lack of ownership of the quality and customer satisfaction of the result. Instead, the people you described felt ownership of the specific literal tasks that you gave.

        With people like that, you have to get them to care more about quality. You need to put them around customers or customer representatives who can interact with them so they get a better sense of the whole product, rather than their little sub-tasks in building it

        Like you say, their feelings are deeply rooted in culture.

    • Re: (Score:1)

      by Anonymous Coward

      Call often and try visit whenever possible.

      We work with people in US, EU, China and Japan. I've found it absolutely crucial that at least some members in each office have physically met members of the other teams. It makes communicating 10 times easier when you've had a beer with someone and know a little more about their environment. Even if you think you don't need this, others probably do. Keep in mind that not all cultures are as direct and forward as you may want them to be. It can take a lot of bondin

      • Re: (Score:2)

        by hbackert ( 45117 )
        I can highly recommend this: let people meet once in a while. One member from each country visiting one other office. So for 4 office locations, 4 people need to travel per year, e.g. for one week. Makes a huge difference if within some years everyone has met everyone else. We have regular video conferences including some fancy Telepresence meetings (highly recommended when face-to-face meetings are not possible due to costs). Nothing replaces personal meetings though.

    • Re: (Score:2)

      by Confused ( 34234 )

      Before people didn't meet face to face, communication will be inefficient due to cultural differences and the fact that it's a lot harder to relate to an email-address than to someone you spent an evening having beers. Even simple things like Yes or No have very different meaning in different countries.

      What seems to work well is to have at least one big team meeting per year where everyone meets in one place. Even if the meeting itself might not be that productive, the face-to-face time is crucial. Also, if

    • Also, if you're having regular conference calls, make sure it works smoothly. If you spend the first fifteen minutes every time trying to get everyone connected, people will hate you for it.

      • And learn to use the mute button, and be sure that you get a good quality connection, and use good microphones. CLI_I_G and DR__OUTS are really hard to stomach for a long meeting.

  • Constant communication is important. Getting each member of the team to have their voice heard in a call each day reminds everyone that they're dealing with Real People(tm) and not just names behind e-mail addresses. If you have a travel budget, try and get 1 person to the bigger team now and then. This can be a PITA with visa requirements for South African's - not sure about your Singapore staff.

  • A chat and email solution is one aspect.

    But we humans can convey more information via spoken language and mimics. An audio and video connection for interacting with the team member across the globe is important.

    Use IM with integrated Audio and Video, and which enables desktop sharing for collaborative working.

    To stitch further the sense of a team despite of the distance, you can extend the office with the view of the other offices' common room filmed from a camera onto a video wall. Of course there is a pri

  • My 2 cents... (Score:3)

    by LordNacho ( 1909280 ) on Thursday April 14, 2011 @02:43AM (#35815426)

    So, there's two categories of things you need. You need equipment/services to make it possible. And you need to create a sense of "team" among the members, which is harder to do when you're not in the same room.

    Stuff:
    -campfirenow.com. A web-chat for multiple users, where you can see what you missed while you weren't logged in.-
    -Webcams. There's still such a thing as body language.
    -Project management software. We use fogbugz to track dev projects. Whatever you industry is, you might want something similar, because you can't just lean over and explain the issues to your team members. Also, it's good to have a record of issues so you don't forget.
    -Various kinds of shared desktop software. You'll want to be able to show people things, instead of just typing out descriptions.
    -Extra desks. We have extra desks for team members who work from home. If they come in, they won't be homeless, sitting on a tripod, and working on a 10 year old machine.

    Teambuilding:
    -Try to meet for socials now and again, wherever you are in the world. Paintball/Steak/Strippers, depends on what people want to do, but don't skimp on money. You don't want people to feel like they're just sitting in front of their computer taking orders from a web page.
    -Sometimes, you'll need people to actually work together. Looming deadlines and important launches will benefit from flying people in to work face-to-face.
    -Generally, the more life-like contact, the better. I've seen offices where remote users were on webcam, able to join in the banter.

    • Re: (Score:2)

      by Panaflex ( 13191 )

      Just to add a bit to this excellent advise -

      Formal and informal - have IM available during work hours, it's less formal and fast. Let email be for hashing out big issues and letting people know your sick 'having a team chat is good, but it can get a bit overwhelming for more than 4 people, so use it for meetings.

      Screen sharing - we use gotomeeting, it's good stuff and works on nearly anything.

      Weekly targets - you need to get people used committing to goals and reaching them. If people are done early, then

  • Seriously, i would go for Google Apps for Business. Whats not included by default, you add as an app.

  • Aeroplanes (Score:1)

    by Anonymous Coward

    As someone who manages distributed teams, I think the most important thing is for people to work together in person for a short time regularly.

    If a new person joins a team, fly them over to work with the rest of the team for a few weeks. Fly them over again next year for a while.

    This sounds expensive, but in my experience the way in which it engenders trust, and facilitates better communication and collaboration across your skype, webcam, irc, messenger, campfire etc channels once they go back is invaluable

    • That doesn't sound expensive, it is expensive. For some projects it's an absolute must, but it has to be a pretty substantial project to justify the outlay of cash.

  • What are you trying to achieve, how are your teams split up, what kind of collaboration is required. South Africa will have the downside of expensive broadband (due to Telkom monopoly), but it is better than it was a few years ago.
    For video conferencing you can do small teams / groups with software like Oovoo, skype etc, or you can buy a decent dedicated system like Lifesize (now owned by Logitech). There are other more well known names in vid conf as well, but that you can just search to find them. Go
  • Well, first use git or mercurial. Then set up an in person meeting of the team at least once at the beginning of the project. A lecturer at UCLA told me that projects are 70% more likely to succeed if people meet face to face once. I don't have a link to the original research that claims this, though.

    • Isn't having the whole repository, including all past changes, cached on your local machine, a drag? As opposed to svn?

      • Technically speaking, it uses up a chunk of your hard drive, yes, but also makes commits way faster. The only two down-sides that I've found so far, working with git/hg/bzr, are the hard drive usage, and initial clones can take some time. I still hate going back to SVN where needed, simply because commits, and checking logs, aren't instantaneous.

        • Might one downside be that no single repository has the full history of all possible paths that all devs took, and failed/not ready experiments?

          Might not matter in free/open source dev, but it could for a company that wants a record of what approaches have already been tried.

          Also, any "gotchas" for folks coming from the venerable cvs/svn background?

          • So, first, I'm a big fan of Mercurial, and our team just switched to it. The "gotchas" that I can enumerate are:
            • "I have to type TWO COMMANDS to get my bits onto the server???!!!!?!
            • "I have to type TWO COMMANDS to get new bits from the server???!?!?!?! (use "hg pull -u")
            • It's not quite as easy to secure through Apache -- if, say, you are using Trac for project management, that was what kept us using Svn for a while. I'm not saying "impossible", I'm saying "not as easy", especially in an open source project

          • Re: (Score:2)

            by Skuto ( 171945 )

            Might one downside be that no single repository has the full history of all possible paths that all devs took, and failed/not ready experiments?

            No. Experience says that with a single repository, the developers often just don't commit stuff they don't feel is ready to make public. It gets worse when the centralized system is slow, because there's even less incentive to commit early-commit often then. That makes the problem, and the risk to lose stuff, worse. So the ability to always quickly commit "dirty" stuff is an advantage for distributed version control, not a disadvantage.

            Also, any "gotchas" for folks coming from the venerable cvs/svn background?

            Yes, because you don't have to wait ages for a "commit" operation to com

      • Re: (Score:2)

        by Skuto ( 171945 )

        No, it's a massive, gargantuan advantage. Unless you somehow have a repo that is bigger than your disk, in which case: "you're doing it wrong".

        Advantages for this scenario:
        - Speed of all interactions with the version control system is independent of networks speed (or amount of developers - it scales)
        - Developers can continue working if the remote network or the repository server goes out (with different timezones, this gets more important)
        - Better branch+merge support helps when there is potentially less d

      • Re: (Score:2)

        by osgeek ( 239988 )

        If you're a distributed team (point of this article), then it's a huge advantage to be able to operate easily against the entire repository no matter where you are or what the status of your connection to the centrally-shared repository.

        Additionally, these distributed source code control tools are where the real development action is happening. Awesome features like bisect (which lets you zone in on which commit broke the software) and the attic (which is a little like branching but local, convenient, and

  • This can be a good thing. (Score:1)

    by Anonymous Coward

    I'm assuming you're taking about software teams.

    - Make sure the usual stuff is in place: Bug tracking, version control, build servers,...
    - Agree on a common language. In this world and age, English would be a good choice. All documentation, email communication, variable names, comments etc. are to be written in that language.
    - Different time zones can cause wasting a lot of time. Have team members from different areas work on different modules/parts of the project so that you don't need to depend on each ot

  • Use tools like Webex/GoToMeeting/OCS where you can have an integrated A/V meeting and use local telco numbers to control costs. Be aware about the telco plan of the vendor (included or not and at what cost per minute). Webex used to charge for the telco minutes but I don't know what they do these days. GoToMeeting is free as far as I know but check to make sure.

    Set up a collaboration environment like BaseCamp (if it's for Project Management) or MS Team Studio, Atlassian JIRA/Confluence if it's for developme

  • virtual(a): existing in essence or effect though not in actual fact; "a virtual dependence on charity"; "a virtual revolution"; "virtual reality"

    So are you actually looking for the best way to create a team that does not exist but does produce an outcome? I think you are already there :-)

    Or are you looking for software to support the communication between teammembers in such a way that they really feel to be a part of a team? Then I would look for software that is already integrated with the way of working

  • If the members of your team are globally distributed, I'd drop conference calls for many decision-making meetings. Whilst you may have staff that are happy to partake in a conference call at 7pm local time, they will get frustrated with not being as fresh as others where the meeting is being held at 10am their time. For those that are tired, having already worked a full working day, it will prove very difficult for them to efficiently express their side of an argument. Look at how the open source community

    • Re: (Score:2)

      by Malc ( 1751 )

      Ahhhh, never ending email threads where things don't get solved quickly, especially if priorities aren't clear. It doesn't beat live communications, especially if you want to get your job done.

      • Re: (Score:2)

        by tf23 ( 27474 )

        Ahhhh, never ending meetings where things don't get solved quickly, especially if priorities aren't clear.

        If priorities aren't clear, the manner of communications is going to be inefficient regardless.

        Personally, I'll take a well drafted email over any live-person-multiple-people meeting any day. The emails in my experience tend to be well laid out and detailed. Meetings, people show up unprepared and empty-handed. Then don't take well enough notes. Then are preoccupied with other things going on (for that

        • Re: (Score:2)

          by Malc ( 1751 )

          In my experience, long emails don't cut it either. It seems that some people don't read or comprehend beyond four lines, and this seems to be especially bad amongst Americans. I don't know if it's cultural, an attention span issue, or trying to work via a mobile phone whilst doing something else.

          I can find out in a few minutes of conversation (even faster than via IM) whether and what somebody understands or not, which is way faster than writing a detailed email that might be superfluous or not cover the

      • Re: (Score:2)

        by osgeek ( 239988 )

        Agreed. I'd rather have someone's tired presence on a conference call where a decision can quickly be made than a multi-day email thread where things tend to go round and round due to a lack of immediate interactivity that forces feedback into the discussion.

        Especially when your working hours are skewed, it can be excruciating waiting until the next day to inch the conversation forward, only to have the other person completely miss the point of an instruction and waste his entire day working in the wrong d

  • Many of the software/practices/etc. for a team are very different depending on what they're doing, and there's no sense of that in the question. For teams of spread out developers working together, you need strong version control and issue tracking software. Teams doing support will need ways to collaborate on a shared knowledgebase. The right software is very dependent on the job.

    The only general thing all projects like this need is good communications software. You're going to want simple text chat so

  • Okay, so my methods might sounds a little unorthodox, but the key point is that your team will be working together day in and day out on projects, and if they're geographically spread out they will not have the same in-office experiences that they would if everyone was 1 cubicle away.

    Getting everyone together around a speakerphone for a conference call isn't a bad place to start, but if all you do around it is talk shop (and I mean just talk shop, no distractions allowed, etc...), I worry about the cohesive

  • Why are my new team members so far apart?

    Maybe you're putting a bandaid over a symptom, rather than solving the problem.

    • I'm part of an organization that is global. My department here in the U.S. works with and supports offices all over the world. We realize we could do a much better job than we have in the past and part of what we are trying is having team members in the countries we support.

      In some cases Americans go and work in the offices, in others we have nationals doing the job. I'll be moving to Hungary this summer to work in our Eastern Europe office.

      So it isn't a problem for us. This is the way we want to work, we a

  • A team is all about trust. Each member trusts the other members to do what they say they will, in order to meet their shared targets. (If your team members only have individual targets, that's not a team: it's merely a group of individuals who report to the same person. However, that's what most people mean by a team - do you?)

    Now, trust comes in many forms but the most important one requires that you actually know the people involved. Contrary to popular websites marketing, you never really know someone

  • Communicate. And not just about work! (Score:2, Informative)

    by Anonymous Coward

    I am in the UK, and work with a team in Finland, India, Czech Republic, Germany, Lithuania and Sweden... I work with no-one else in the UK. Communicating regularly and often around work topics is a given, both in group meetings and just by following up with IM or a quick call. I make the assumption that you have an appropriate toolkit, such as Office Communicator / Lync, and LiveMeeting or whatever you prefer, but you need something to chat, speak, video call and conference with.

    The real challenge is rea

  • I have researched this. The answer is at http://vulpeculox.net/treems [vulpeculox.net]
    • Limited bandwidth makes it better to get to know a few people really well
    • Management oversight is more difficult so build mini-team responsibility and development and ownership of objectives
    • Make sure people are in the part of the organisation that suits them (see link above).
    • Provide separate communication protocols for gripes and discussions as opposed to getting the job done. (You need a 'grumblee' to be a lightning conductor for t
  • Let the flames be thrown at me for this one: I actually like Sharepoint to keep on the same page as a team. ~

  • IRC ftw. - Fast, textbased, privte chat when needed, multiple chatchannels for different groups.

    And you don't have graphical smilies or video, so no one will fall for the temptation of laggy video conferencing.

  • Patience, language, and other tips (Score:5, Insightful)

    by zevans ( 101778 ) <zacktesting@goLIONoglemail.com minus cat> on Thursday April 14, 2011 @03:42AM (#35815604)

    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: (Score:2)

      by Inda ( 580031 )
      Great advice.

      My German colleague just said the word "prepone" to me, in reference to a meeting. Opposite of postpone? That's what I guessed. It's not a word I've read, heard or spoken in the last 40 years. I had to look it up.

      It turns out that the Indians invented it and it is the opposite of postpone. There is not an English word opposite to postpone, so they made one up. Fair enough.

      I do use slang in front of my German colleagues; normally after they've broken out the German, which they know I'm limited i

      • Re: (Score:2)

        by qwijibo ( 101731 )

        The very concept of preponing a meeting is intrinsically offensive to Americans. The question presumes that the reason the meeting was scheduled for next week is completely arbitrary, and doesn't represent the first available time that that all parties are available. It implies that in other cultures, a meeting could be scheduled for next month with absolutely no thought put into that date or how it may impact other people's plans or schedules. It's even more offensive when you do confirm that yes, in fa

    • 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.

      But on the bright side, you can make some great personal connections if you just show a little curiosity about those cultural references. I spent a couple hours one evening introducing one of my Indian coworkers to NWA, Ice Cube, Public Enemy, and some other hip hop music. This came about after he asked whether a par

      • Re: (Score:2)

        by zevans ( 101778 )

        Good point. I was thinking more about a virtual team that changes often. If you're in it for the long haul then you do start making personal connections and understand what the various people understand and don't understand. Er, if you understand me.

        Then of course there's the whole thing about mental pictures you form on the phone and the shock you sometimes get when you finally meet them. :-)

        • Yeah, if there's a lot of turnover, those personal bonds get very difficult to form. Most of my work with distributed teams has been with fairly stable international groups all working for a single large company, so we've had a chance to get to know one another a bit.

          As trite as it'll sound here on Slashdot, using some social media types of stuff - Facebook, LinkedIn esp. - to "socialize" with your distributed team outside of official business channels can also help foster those bonds - from what I've seen

  • This is of course, assuming you're trying to solve the problem of not being able to get everyone into the same room. Also things differ quite a bit based on what type of work your team does. Since you're asking slashdot, I'm assuming your team is technical like ours. Here's what worked:

    1. Meet using www.teamviewer.com (or something similar) -- Participants would all join and the conductor(s) would use a drawing canvas while discussing ideas (we had a pen device -- I suggest you get one too).
    2. Screen capture yo

  • I'm working with a small team with members in three different timezones, up to 8 hours apart. That makes any of the immediate-mode forms of communication, like Skype and IRC, difficult as it always requires someone to make themselves available outside of normal working hours.

    What we've been doing is using a team blog in which each team member writes a brief summary of what they did each day, raises flags on potential issues, etc. Email is used for more extensive temporal discussions.

    We're running on two-wee

    • Re: (Score:2)

      by osgeek ( 239988 )

      Your comment is the first one I've read that mentioned a code review tool.

      That's a great idea to have in the mix of other communications tools. Being able to distribute your code review both geographically and temporally is very important.

      Anyone have any other recommended code review applications that they'd recommend?

  • ...such as the "basic" Skype (or with a Group Video subscription, gives you a little facetime, or to give a bit more of an immersive feel, SecondLife has a good few island plots (such as Bluepill) that demonstrate the value of CVEs.

  • A couple of suggestions from someone who has done that over 5 years.
    * Do *have* a mailing list. Nothing beats it reach.
    * Have a good ticketing system. We used to let people who are online to pick up tickets from any geo and work on it unless it is something that requires hands on , in which case, we used to pass it on to the local contact.
    * Use a good text based chatting solution. Video / audio solutions are good, but text is better for a lot of things, like small talk , sharing links or a way to avoid m

  • And I've been to several remote teams

    - Have email and preferably shared calendar. Google Apps can do that for you
    - Task management. ScrumDo has positively surprised me
    - Wiki: Redmine instead of Trac

    Code-wise, if you need for programmers, IMHO nothing beats git-svn.
    SVN: easy to setup server, centralized, plenty of tools, etc
    Git is killer for the client though. Other 'less wise' clients can use tortoise svn

  • I've worked in a virtual team for over 10 years and the short answer is that making it work takes work. Most engineers are solitary and it takes a lot of communication to keep a virtual team together. I wrote a book about it. The One Minute Commute [zackgrossbart.com]. It is available free.

  • 10 suggestions: For what it's worth (Score:5, Insightful)

    by Compaqt ( 1758360 ) on Thursday April 14, 2011 @05:31AM (#35815988) Homepage

    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.

    • Re: (Score:2)

      by tobiah ( 308208 )

      That's a keeper, thanks for sharing.
      (but "old and busted"? seriously, I've have a mind to canesmack you)

      • Sorry, just deferring to the new "received wisdom".

        I mean, it was just a few years ago that using svn meant you're trying new things (in place of CVS).

        By the way, have you had any problems with git? Also see discussion above [slashdot.org]. I haven't waded into the waters yet.

        • Re: (Score:2)

          by tobiah ( 308208 )

          Haven't tried git, because I have no complaints about svn. It looks to me like git will end up with more unintentional branches and merge operations, I like how for svn you have to be rather deliberate about it.

  • Honestly, the chance of a virtual team becoming a real team is much lower than for a team at a single site. No matter the technology, the chances are stacked against you. In my observation a lot of virtual teams have to improve to reach a dysfunctional level.

    Less than 1/3 of the virtual teams i know have reached any status resembling a real team (e.g. partitioning the work, fail-over in case of illness/vacation, successful handovers inside the team, cooperation, load sharing). If you take social aspects int

    • I agree completely. Some in-house studies that I have been privy to have shown 2-1 or 3-1 productivity difference between good co-located teams and "good" virtual teams. Creating a true, high-performance virtual team is incredibly hard emotionally, incredibly time-consuming, and costs a lot in terms of tools and travel. If this is being done for convenience of the team members or for cost savings, it's a bad idea. The only good reason to have distributed teams is if there is a compelling strategic reaso

      • Re: (Score:2)

        by Algan ( 20532 )

        I worked in a virtual team for 3 years and we were pretty successful. Here's how we did it:

        1. Core hours are the single most important thing. Have everybody there at the same time. +/- 1-2 hrs are ok, but opposite timezone are not. We all worked on EST with schedules that varied by at most 1 hr.
        2. Continuous IM presence. We also kept a couple of group chats open. One group chat can serve as "water cooler" chat, for swapping failblog links and general breeze shooting.
        3. Group Video conferences. Not always on

  • I personally work at a virtual company, and aside from a neighbor which also works there, I have rarely met my coworkers in person. We use WebEx [webex.com] in order to have online meetings, and work on things together. We use Groopex Integrated Conferencing [groopex.com] to integrate WebEx with our corporate site to easily schedule meetings and launch them. We use Google Apps [google.com] to share various office documents around. We use MediaWiki [mediawiki.org] to keep track of current projects, todo lists, documentation, and other important information. Last

  • Producing Open Source Software (book) (Score:1)

    by Anonymous Coward

    Producing Open Source Software (http://producingoss.com/) has some good descriptions of tools and practices used by open source projects. It's a bit of cultural anthropology: a lot of the ideas are obvious if you've been doing the open-source thing for awhile, but you may not have thought about how to express them. The Art of Community (http://www.artofcommunityonline.org/) covers some of the same ground.

  • I don't know of any products that would do this but some one should make it. If you build an office in a computer game but integrate web cams or xbox kinects so you got real time real life images of your workmates, then display it on a projector or an extra screen. This way you get all the advantages of working in an office team, while being able to relax on a boat next to a Caribbean island (which has good wifi). Also depending on your business a great way for clients or contractors from any where in the w

  • I'm a developer and I've been working remotely from other people for the last 12 years. Nowadays, I rarely work on a project that has co-located people. We may occasionally meet each other in person, if we happen to be onsite at a client's location, but we never have physical team meetings just to meet. I haven't physically met any of my managers in ten years. What I've noticed about successful remote teams is that they adhere to a process, they have good project managers, and they've got kick ass code

  • Try to adopt Yammer or some other micro-blogging platform, and encourage people write often, preferably once a day what they are up to. For techier types, IRC works better, of course.

  • Unless your team members are going to be shifting a lot then have a good kickoff with everyone in one place. Yes it may be expensive but it builds that initial bond so when everyone returns to their respective countries they have an established familiarity with the rest of the team.

    Don't be afraid to change the makeup. If someone isn't working out (and you can) remove or replace them. Not everyone gels with everyone. Conversely just because people don't like each other doesn't mean they won't be good te

  • I currently work on several multi-site research projects, and the biggest lesson we've learned is that when you do conference calls EVERYONE should be prepared to offer a summary of what they've been working on and how it's going. Additionally, have one person who's sole job is to get task lists from everyone and to check off status updates on that master list so that nothing is accidentally left out.

    Before we implemented that in our conference calls, it would basically be the senior people talking to each

  • What I think you mean is a remote, distributed team. In a Virtual Team, everyone will report to managers other than yourself ... and the challenge is to ensure that their Managers set their goals appropriately ... meaning aligned with your goals ;> That's an interesting set of challenges, but different than (but may/often coexist with) remote/distributed team issues.

    I've been part of, or leading distributed teams on and off since the 1980's. The technical details change; but the core issues are innate.

    1.

  • Lots of folks have said good things about weekly meetings, good software, and etc. As a telecommuting veteran, I have found that it is extremely helpful to be consistently available. Whatever hours you (or anyone) work, whenever you are, be consistent. Everyone on the team should know the hours that Johnny and Jill are online and available for chat - without having to look at a spreadsheet or calendar to see if they have changed things up this week. Being busy and/or in a meeting is fine - that happens

  • Get Webcams (Score:3, Interesting)

    by davecotter ( 1297617 ) <(me) (at) (davecotter.com)> on Thursday April 14, 2011 @12:51PM (#35819956)
    make sure y'all have webcams and the software to show the video wall of all connected users. i work remotely myself, and i can't tell you how much more PRESENT i feel at meetings when i can see the participants in the office meeting room, plus any other remote users. Just being able to see who's talking helps in a way that's difficult to describe, everyone will definitely notice the difference.
  • Fengoffice [wikipedia.org] is an open source web environment that is could be good for some ways of collaboration, specially in sparse teams. You can install it in your own server or use it as an online service in the company website.

Slashdot Top Deals

Fast, cheap, good: pick two.

Close