InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Can Virtual Teams Ever Work?

Posted by Ben Hughes on Jun 07, 2007

Sections
Process & Practices,
Development
Topics
Artifacts & Tools ,
Agile Techniques ,
Collaboration ,
Agile
Tags
Collaborative Technologies ,
Distributed Teams ,
Complementary Practices
Given that co-location is one of the bedrocks for Scrum, the increasing trend toward operating non-co-located teams raises questions on how Agile can work in such an environment. Indeed, is an understanding of the common reasons Agile projects fail enough to offset this risk, or with will a new breed of Agile tooling enable virtual teams to work as effectively as a co-located team?

David Churchville described the common distributed team scenarios, offering solutions to common pitfalls of delivering Agile projects using different types of distributed team:

  • Type A: All developers are together, all customers are remote

  • Type B: Multiple development teams in different locations (but each team is together)

  • Type C: "Virtual" team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

The author discussed some valid approaches for Types A and B, however for Type C:

On to Type C teams - the new "virtual workforce" we've been hearing about. Unlike the first two types, these folks never see anybody. This turns out to be strangely beneficial. Because everyone is on the same level, these individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and having an initial in-person meeting as with the first two types. Virtual teams can suffer from poor quality of communication though, and may need to supplement with group collaboration tools like shared whiteboards to supplement daily calls, emails, IM, etc.

For Agile aficionados enamoured with pair programming (developers working on a task together), it's possible to setup virtual desktop and keyboard sharing (using VNC or similar software) along with an Internet phone line (e.g. Skype) to do this.
Tools such as Mingle and VersionOne are firmly aimed at the management of executing the build of a software product (and in their Web based nature supports distributed teams), and using practices such as mentioned above, but cannot facilitate virtual teams activites such as pair programming and daily meetings – where social interaction is fundamental.

In light of Alistair Cockburn’s work on the importance of quality in communication and the role it plays in Agile teams, and the plethora of communications tools (IM, Skype, IRC, Groups, Virtual Whiteboards) - do we have what's needed to make truly virtual teams effective?

Works fine for me by Michael Neale Posted
Depends on the circumstances! by Dave Rooney Posted
Re: Depends on the circumstances! by Bruce Rennie Posted
Re: Depends on the circumstances! by Dave Rooney Posted
Another religious argument by Bruce Rennie Posted
Experience with type "C" by Susan Davis Posted
Re: Experience with type by Michael Dubakov Posted
It is just not team location that matters by Lisa Ray Posted
Been doing wonders for me by Ken Lin Posted
  1. Back to top

    Works fine for me

    by Michael Neale

    The only thing is, you can't take a non virtual team and make it virtual. If it starts out that way, its much easier. You will need some face time each year (just to get familiar with personel).

    The other trick: do stuff, not just talk about it ;)

  2. Back to top

    Depends on the circumstances!

    by Dave Rooney

    First off, "remote" doesn't have to mean "in another continent" - it can mean "on another floor" or "in another building". Remote is remote.

    Second, regardless of the 'Type', each team is different. You will find examples in each category where it worked well and where it didn't. A lot has to do with the culture - are the people empowered to make things work. I've recently seen a Type 'B' team struggle because corporate security wouldn't allow the use of VOIP or remote desktops across continents. However, I've also seen similar situations where it worked fine and the remote teams were fully engaged. I've seen a Type A team work fine, but then have difficulties when the Customer became less involved. That had nothing to do with being remote. Finally, I've only experience one Type C team, and it worked quite well. That, I believe, is as much a function of the people as it is the enabling technologies.

    So, as with most of the agile principles and practices, it all comes down to the people!

    Dave Rooney
    Mayford Technologies

  3. Back to top

    Another religious argument

    by Bruce Rennie

    There was a VERY long discussion about this recently on the agile usability Yahoo group.

    Bottom line: A team will always perform better when they are co-located than when they are virtual.

    Now, the difference in that level of performance may be negligible for a given project. That's the decision of the team and the business.

    A lot of people seem to think this is an argument of the form "Co-location good, virtual team bad". It's not. It's more "Co-location better, but you may have other considerations that make it worthwhile to go virtual".

  4. Back to top

    Re: Depends on the circumstances!

    by Bruce Rennie

    Again, I would say it's not about whether or not a virtual team can work. Of course it can. Humans can pretty much make ANYTHING work.

    It's simply about recognizing that there is a price to pay for working remotely. If that price is small enough to be acceptable then it should be considered.

  5. Back to top

    Re: Depends on the circumstances!

    by Dave Rooney

    Again, I would say it's not about whether or not a virtual team can work. Of course it can. Humans can pretty much make ANYTHING work.

    It's simply about recognizing that there is a price to pay for working remotely. If that price is small enough to be acceptable then it should be considered.

    Agreed 100%! If I wasn't clear about that, then I apologize. My point is that a team is remote the moment they aren't in the same physical workspace.

    Dave Rooney
    Mayford Technologies

  6. Back to top

    Experience with type "C"

    by Susan Davis

    I've successfully led a type "C" project in the past, where no two of us were located in the same city. It was one of the best teams I've been involved with, actually, and worked better than some co-located teams I've been on.

    Not being in the same city made it obvious to everyone that we needed to be really proactive about picking up the phone and calling people very frequently. By contrast, in sort-of-colocated teams where everyone lives in a cube farm rather than a project room, it's easy to get complacent about the fact that a coworker is just down the cubicle row, and to not bother to touch base with them for weeks on end. An actual project room solves the problem the opposite way, by removing the effort to communicate with someone altogether; it's that middle distance that hurts team cohesion.

    I'm setting up a new team right now, and we're all together in one big happy project room. We're sort of "type B" in that there's another team in another country that we interface with from time to time, but for the most part, we're independent.

  7. Back to top

    Re: Experience with type

    by Michael Dubakov

    Almost all open source projects based on Type C teams.
    Many open source projects are successful, but many not.
    There are different reasons, but one of them is Type C team for sure.

    Michael Dubakov
    TargetProcess - Agile Project Management Tool

  8. Back to top

    It is just not team location that matters

    by Lisa Ray

    Colocation of agile teams is an important criteria to bring agile projects to success but this not the only criteria. Using collaboration tools effectively even Type C teams can deliver succesful results.

    WRAP - Agile Project Management Software

  9. Back to top

    Been doing wonders for me

    by Ken Lin

    Virtual projects and project management seems to be the trending work medium nowadays. Definitely for myself and the company I am working for, it has been essential. www.pivotaltracker.com has been a great help for us so far. Definitely recommend it.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.