Can collaboration tools eliminate the need for face-to-face teamwork?

Have we progressed to the point where we can work just as productively in a distributed fashion as when we’re co-located? Agile expert Lisa Crispin examines this question from all angles, exploring how team leaders can make the most of collaborative tools.

This Content Component encountered an error
This Content Component encountered an error

Technology that allows people in different locations to collaborate has also improved rapidly in the past several years. IM, wikis, online task boards, teleconferencing and video chat are well-established tools. Robotic telepresence devices permit remote team members to move around the office at will, just as involved as they would be in person. Do these sophisticated tools replace the need to have any actual face-to-face contact? Or...

are there issues that technology can’t overcome?

There are challenges when team members are scattered in different locations. Let’s consider some of these, and whether available technology can solve the problem.

Working on one code base

Version control and continuous integration tools allow distributed teams to coordinate on one code base, and get quick feedback on each check-in. Large open source products such as Mozilla Firefox are proof that technology allows huge numbers of developers to contribute to one code base.

Remote pairing was pretty easy even when I worked on a distributed team back in the early 00’s. The desktop sharing, voice and video communication tools nowadays make it even easier. We can document our specifications with executable tests and wikis. Careful thought is needed to divide user stories up among developers in different locations, but online tools help teams keep track of who’s working on what.

If time zone differences make pairing difficult, it may be hard to address some problems. It can be hard to deal with remote team member whose work has fallen below the team’s quality standards.  It can be harder to stay motivated when you’re telecommuting, especially if the rest of the team doesn’t keep you in the loop. Tools can’t replace the personal interactions that help each team member continually improve.

Visualizing

Lots of leading software professionals talk about ways to visualize quality. For example, whiteboards help us visualize features to develop, user interfaces, data models, test scenarios, all kinds of models. There’s a big selection today of online and interactive whiteboards to allow drawing and visualizing in multiple locations. At the minimum, remote team members can see whiteboards via webcams and photos.

Mind maps are another example of a tool that lets us visualize models and brainstorm solutions. There are several tools that allow real-time collaborative mind mapping.

Today’s technology accommodates distributed visualizing. If we use these tools properly, and add more bandwidth such as video chat, we can communicate and collaborate as well from a distance as we do in person.

Learning

In my experience, a cornerstone of successful teams is continual improvement. We can each take charge of our individual professional growth, but we’re also responsible for sharing the specialized skills we possess to other team members. Some of those specialized skills are kind of hard to teach, because they’re learned more by doing than by explaining.

For example, if I want to teach a teammate something about exploratory testing, we probably need to pair. As discussed in the previous sections, remote pairing has become easy to do. This is one area where technology removes the requirement to be physically co-located.

Technology allows remote team members to participate in retrospectives, where they can help think of and try small experiments to overcome impediments and improve. Training courses can be done virtually. Physical distance doesn’t stand in the way of team learning.

Trust

I recently attended a talk by Johanna Rothman where she explained that trust is what keeps people in their jobs. At the same time, we humans have a strong tendency to divide and stereotype, according to Linda Rising in her talk at Agile Testing Days 2011, so it would be easy for team members in one location to develop a distrust of “those people” in a separate location. According to Linda Rising, individuals in a small team working close together make an extra effort to achieve. They trust each other and ask each other for help as they work towards a common goal.

The tools we’ve already discussed can help distributed teams build trusting relationships. Video conferencing and telepresence devices let everyone participate in specification workshops and planning meetings, and create a shared understanding of features. Online tracking tools make progress visible and help developers in different locations manage dependencies. Version control and continuous integration processes, used properly, ensure that individuals will take responsibility for fixing any regression failures.

Can these tools really replace in-person, human interactions? In my experience, though being able to see and hear someone goes a long way towards improving communication, nothing builds trust as well as in-person. If at all possible, bring everyone to one physical location as often as possible. Project kickoff is a good time to meet and work out a shared understanding of the project’s mission.

If getting all team or project members in one place is impractical, rotate people around. When I worked on a project with people distributed in three different locations, each person travelled one week per month to go work in one of the other locations. We were able to develop trusting relationships that allowed our teams to jell. Once we knew each other – and our customers – in person, using IM and remote pairing were easy ways to work together.

The bottom line

Based on my experience, a distributed team can never be as effective and productive as a co-located team. We have the technology to keep remote people “in the loop,” but it also takes a lot of discipline. It’s easy to forget to mention something important to the “other team.” I think it’s harder for distributed teams to “gel.” As Bob Martin says in The Clean Coder (2011), a team that gels gets things done.

I’ve made a lot of good friends and professional contacts around the world via social media, mainly Twitter. I often meet my tweeps in person at conferences and meet-ups when I travel. Though I feel I already know a person I’ve communicated with on Twitter and through virtual meetings such as Weeknight Testing, getting to know them in person builds a different, more trusting relationship.

Distributed teams have their own advantages. They might be less efficient in some ways, but they also may allow you to hire better people for your team than if you were limited to one small geographic area. We can even use time zone differences to our advantage. If my team is stuck on a problem at the end of the day, we punt it to our teammate in India who is 12.5 hours ahead of us. Usually by our morning, he has solved the problem and we can all move on to the next challenge.

Today’s technology frees us to experiment and see whether distributed teams can provide the same return on investment as co-located teams. While distributed teams may require an extra investment of time, tools and effort, they may also be able to deliver a higher-quality product that better meets customer needs. Building a great team is hard work, co-located or not. But it’s well worth the effort.

For a comprehensive resource on social media, see Social media: A guide to enhancing ALM with collaborative tools.

This was first published in December 2011

Dig deeper on Building Software Project Teams

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close