Manage Learn to apply best practices and optimize your operations.

Does Agile development’s emphasis on face-to-face hurt teams?

Site Editor Yvette Francino urges Agile leaders to consider problems that may occur if there is too much emphasis on co-location.

“The most efficient and effective method of conveying information to and within a development team is face-to-face...

conversation,” states one of the principles of the Agile Manifesto.

Have some Agile enthusiasts gone too far with this principle? We certainly wouldn’t stop using email just because face-to-face communication is more effective. However, many organizations take co-location so seriously that they limit their employee base to only those who can come into the office every day. Work-from-home is not an option. While face-to-face communication can foster strong teamwork, it may cause other problems. With the advancements in technologies that promote collaboration from anywhere, such as cloud, mobility and social media, is the importance of physical face-to-face teaming still valid? Senior managers need to stay current in tools that would allow their employees the flexibility to work from anywhere and understand reasons that an emphasis on face-to-face communication may actually be hurting organizations.

A bias against remote communication

One of the biggest factors of success in any effort is attitude. If we think we are going to fail, we probably will. If Agile enthusiasts feel that in order to be truly “Agile” they must have face-to-face communication, they may consciously or unconsciously not be making the effort to communicate as often with remote stakeholders or team members.  

In-groups

“In-groups,” also thought of as “cliques” or “silos,” are groups of people who may team very well together, but those who are not part of this “in-group” can feel excluded, leading to poor overall communication. Scrum teams, so determined to break down silos, may be creating silos of their own.

In the paper, “In-group/out-group effects in distributed teams: an experimental simulation,” 10-person groups were studied. Each group had five co-located members and five “isolates” (simulated telecommuters.)

We found that the collocated people formed an in-group, excluding the isolates. But, surprisingly, the isolates also formed an in-group, mainly because the collocated people ignored them and they responded to each other.

The issues that can occur because of the lack of equality felt by “isolates” or “sub-groups” is often attributed to the fact that the team is not all co-located. However, the real problem may be that those team members that are not “seen” are excluded from conversations and decisions causing conflict on the team.  

The whole team is bigger than the Scrum team

Often projects are composed of multiple Scrum teams who are dependent on one another. However, the strong cohesion formed from a co-located Scrum team may be detrimental if the team forms an “us-them” type of mentality when working with other teams. The silos may just be in the form of Scrum teams rather than the silos that are formed by organizational roles.

Agile expert and author Lisa Crispin says, “I’ve seen this myself. One Scrum team doesn’t know what the Scrum team in the next team room is doing. Everybody re-invents the wheel for all aspects of testing and coding.”

Janet Gregory, co-author with Crispin of the book “Agile Testing: A Practical Guide for Testers and Agile Teams,” suggests counteracting the problem. She says, “The idea of Scrum of Scrums goes a little way to help, but there needs to be more ‘larger’ group team building. I call this thinking about your extended family; not only other Agile teams, but the support group, the tech writers, etc.”

The idea of a “community of practice” was also suggested at a recent Agile conference as an idea to create cohesive teams that move beyond small Scrum teams.

Limiting who you can hire

Managers who are against remote collaboration will be limited to hiring only those who live in the proximity of their office location and who are available to come into the office each day. This lack of flexibility not only limits diversity but may be enough to prevent some of the best and brightest from accepting offers. With the advances in technologies, many organizations are offering work-from-home options, and those companies that don’t offer these options may be viewed as rigid and old-fashioned. Employees may feel that they are being micro-managed or being evaluated by their time in the office rather than their deliverables.

SSQ contributor and consultant Matt Heusser says, “The big advantage I see in massively physically distributed work forces -- where anyone can work from anywhere with Internet and power-- is radical changes in who you can hire and why they would want to work for you. If your company is struggling to hire, or to get people to move, to a small market (or even a big market if your company is the dominant employer), then telecommuter workers might be something for you to look into.”

Work is tied to being in the office

Even in cases where the team is co-located, team members go on vacation, get sick, travel or have other reasons that may cause them not to be in the office. If the office does not have an infrastructure that has remote collaboration tools, the team member who is not in the office may miss out on important discussions or decisions that take place during his or her absence. And certainly having the ability to work outside the office offers up opportunities for an employee to be productive in situations, such as bad weather, where in the past, the only option was to shut down the office.

Sometimes documentation is better than face-to-face

One final issue that may occur with co-located Agile teams is that clarifying documentation may be limited. Just as too much documentation can be an issue in traditional environments, too little documentation may be a risk in Agile co-located teams. Read more about issues regarding documentation on Agile teams in part two: Communication advantages of distributed Agile teams.

Follow us on Twitter at @SoftwareTestTT and let us know what you thought of this article.

This was last published in May 2012

Dig Deeper on Building Software Project Teams

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchMicroservices

TheServerSide.com

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

DevOpsAgenda

Close