Managing Distributed Teams

Contents

  • Overview
  • Theories
    • Social Identity Theory
    • Technocracy
    • Swift Trust Theory
    • Media Richness Theory (MRT)
  • Principles
    • Building trust
    • Time zone, language, and cultural barriers
    • Communication
    • Technical alignments
    • Project and process management
  • Practices
  • Resources
    • Blogs
  • References

Overview

Software development eams can be distributed geographically, culturally, with language barriers, across time zones, or just across campus. Developing software using distributed teams requires special emphasis on communication and building trust. A variety of practices are available to help with these issues. The extra effort can be well worth it. The diversity that distributed teams bring to solving a software problem can help to promote innovation and creativity in your teams.

what is Distributed Teams

Theories

Social Identity Theory

People are allocated to more one culture at a time, but different cultures are seen as being mutually exclusive. The theory predicts inter-group behavior on the basis of perceived group state differences, the perceived legitimacy and stability of those differences, and the perceived ability to move from one group to another.

Technocracy

The term was originally used to promote applying the scientific method to solving social problems, but is also an organizational structure of governance where decision-makers are selected on the basis of technological knowledge and merit. Technocrats are individuals with technical training and occupations who perceive many important social problems as being solvable, often while proposing technology-focused solutions. A technocrat is primarily driven by their cognitive “problem-solution mindset.”

Swift Trust Theory

Swift trust is a form of trust occurring in temporary organizational structures, which can include quick starting groups or teams. It was first explored by Debra Meyerson and colleagues in 1996. In swift trust theory, a group or team assumes trust initially, and later verifies and adjusts trust beliefs accordingly. Traditionally, trust has been examined in the context of long-term relationships. The establishment of trust has been thought to rely largely on the history of a group and the interactions between members. This traditional view of trust generally assumes that trust builds over time. However, this view is becoming problematic with the increase in globalization, change in technologies, and an increased reliance on temporary teams by organizations. Meyerson et al. propose that swift trust provides the necessary, initial, cognitive confidence for a temporary team to interact as if trust were present. However, swift trust requires an individual to verify that a team can manage vulnerabilities and expectations.

Media Richness Theory (MRT)

This theory is based on the work of Daft and Lengel (1984 and 1986) and Daft, Lengel and Trevino (1987). MRT is a theory that can be used to describe the ability of communication media to transfer information. It assumes that organisations process information to reduce uncertainty and equivocality (Weiman,P 2010).

Back to top

Principles

Building trust

Nothing is more important than this crucial element of a hyper-productive team, and building trust is essential in the formation of cohesiveness between team members. Gaining trust is a challenge when team members are distributed across different time zones, cultures, and environments, and when they also face communication, language, technical alignment, and project management issues. When a team doesn’t possess a minimum level of trust, it’s more difficult to deal with challenges when they appear – it is often easy to blame and criticize the ‘other’ groups and the team can break down into competing tribes. When trust is strong, team members are able to work through the most difficult issues and they often create innovative solutions.

Time zone, language, and cultural barriers

It is vital to create overlapping office hours so that remote teams can communicate, resolve problems, and bridge time zones for other mission-critical tasks. More overlapping time during the day fosters better engagement and collaboration. When team members come from different cultural backgrounds, language and cultural differences can easily create misunderstanding and generate mistrust among team members. In addition, team members in different regions generally have varying degrees of skill and technology expertise, which can create a class system between the different remote teams and hinder collaboration. W H I T E PA P E R : Successful Distributed Agile Team Working Patterns

Shane Hastie and Johanna Rothman explain the challenges that come with distance, be it cultural, social, linguistic, temporal, or geographic. If you work to reinforce your collaboration habits every day, your geographically distributed agile team will thank you.

Related : https://www.agileconnection.com/article/getting-most-out-your-geographically-distributed-agile-team

Communication

As outlined in the section above, different time zones create communication challenges for teams. Overlapping office hours facilitate periods for discussions, problem solving, remote pairing, and other activities that contribute to a project’s success. It is crucial to create as much overlapping time during the day as possible. Team members at different locations often fall back to using low bandwidth communication channels, such as emails or documents, which generates large amounts of lost or misunderstood information. Therefore, high bandwidth communication tools such as video conferencing or desktop sharing should be used as frequently as possible.

Technical alignments

Team members from different backgrounds and regions may have divergent preferences about technologies and tools. For example, team members in Redmond, Washington may have a bias towards Microsoft technologies, while members in China may prefer open-source technologies. Misalignment in engineering best practices can also create conflicts between the remote teams – for example, determining whether to use test first vs. test later development practices or when to do refactoring. Other typical misalignments are coding standards, tooling, and architectural design. Within a co-located team, these misalignments on values are generally resolved over time by day-to-day discussion and communication between team members, with team members gradually building mutual understanding.

Project and process management

In a co-located team, the need for online project and process management is minimal— most co-located teams prefer a physical task board, and BVCs (big visible charts) in the team area to help them stay current on progress and information-sharing with other members. In a distributed environment, transparency and visibility are essential for all remote teams. High-visibility, real-time online project tracking and process management (for example, next Sprint planning dates, CI monitoring) enables all teams to be fully engaged in the development process.

Related : https://www.mindtools.com/pages/article/newTMM_40.htm

Back to top

Practices

Managing distributed teams,5 golden rules

Build “The A Team“

In order to have the highest quality possible and better productivity, synergy within the team is very important. Often, there are various challenges but this is the most important factor. Team members on the same frequency usually leads to successful projects.

Set Expectations/Roles within the team

Team members should always work towards same goal. In our case, it is delivering the highest quality product. Team managers/leads should let each and every team member know what role they are going to play in the project and their responsibility.

Be Transparent within the team

Being transparent keeps all the team members on same page, which helps reach their goals collectively.

Communicate often within the team

Since the team is distributed, communication is a very important factor, such as having daily calls with leads and with team if required. It is always necessary within the team to have a willingness to learn, share and communicate with peers.

Status Reporting to the team

Each and every team should share their status reports to let distributed team members know the progress, which will help them to carry out the tasks remaining.

Setting up Video conferences

If not daily or weekly, there should be monthly video conferences to help team to know whom they are working with especially if the team is distributed.

Having face to face meeting (if possible)

Usage of Tools

Tools help the distributed team to often store data, collaborate adequately within the team. SharePoint, blog, WebEx, net meeting, Team Viewer, Req Pro, Quality Center, Perforce, MS project are some of the examples. It also increases the productivity and helps us to stay on top of things.

Related : https://www.linkedin.com/pulse/best-practices-managing-distributed-teams-mba-csm-lss-gb

Back to top

Resources

Blogs

Getting most out your geographically distributed agile team

Shane Hastie and Johanna Rothman explain the challenges that come with distance, be it cultural, social, linguistic, temporal, or geographic. If you work to reinforce your collaboration habits every day, your geographically distributed agile team will thank you. Related : https://www.agileconnection.com/article/getting-most-out-your-geographically-distributed-agile-team

Virtual community of practice

This Wikipedia page talks about what is online community of practice also called as virtual community of practice, current research, its advantages, disadvantages and some real world examples.

Related : https://en.wikipedia.org/wiki/Virtual_community_of_practice

Back to top

References

Christopher P. Furner. 2013. Cultural Determinants of Information Processing Shortcuts in Computer Supported Groups: A Review, Research Agenda and Instrument Validation. Int. J. Inf. Syst. Soc. Chang. 4, 3 (July 2013), 17-32. DOI=http://dx.doi.org/10.4018/jissc.2013070102

Na Li and Mary Beth Rosson. 2014. Using annotations in online group chats. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ‘14). ACM, New York, NY, USA, 863-866. DOI=http://dx.doi.org/10.1145/2556288.2557209

Bruce A. Reinig and Roberto J. Mejias. 2014. On the Measurement of Participation Equality. Int. J. e-Collab. 10, 4 (October 2014), 32-48. DOI=http://dx.doi.org/10.4018/ijec.2014100103

Daft, R.L., & Lengel, R.H. (1984) Information Richness: A New Approach to Managerial Behavior and Organizational Design. In L.L. Cummings, & B.M. Staw (Eds.), Research in Organizational Behavior (pp191-233). Homewood, IL: JAI Press.

Daft, R.L., & Lengel, R.H. (1986) Organizational Information Requirements, Media Richness and Structural Design. Management Science, Vol 32, No. 5, pp554-571.

Daft, R.L., Lengel, R.H., & Trevino, L. K. (1987) Message Equivocality, Media Selection, and Manager Performance Implications r Information Systems. MIS Quarterly, Vol 11, No. 3, pp354-366.

Fang Chen, Limin Zhang, and Joseph Latimer. 2014. How much has my co-worker contributed? The impact of anonymity and feedback on social loafing in asynchronous virtual collaboration. Int. J. Inf. Manag. 34, 5 (October 2014), 652-659. DOI=http://dx.doi.org/10.1016/j.ijinfomgt.2014.05.001

Timo O. A. Lehtinen, Risto Virtanen, Juha O. Viljanen, Mika V. Mäntylä, and Casper Lassenius. 2014. A tool supporting root cause analysis for synchronous retrospectives in distributed software teams. Inf. Softw. Technol. 56, 4 (April 2014), 408-437. DOI=http://dx.doi.org/10.1016/j.infsof.2014.01.004

Jennifer A. Nicholson, Darren B. Nicholson, Patrick Coyle, Andrew Hardin, and Anjala S. Krishen. 2014. Exploring the Use of Virtual World Technology for Idea-Generation Tasks. Int. J. e-Collab. 10, 3 (July 2014), 44-62. DOI=http://dx.doi.org/10.4018/ijec.2014070103

J. F. Nunamaker, Alan R. Dennis, Joseph S. Valacich, Douglas Vogel, and Joey F. George. 1991. Electronic meeting systems. Commun. ACM 34, 7 (July 1991), 40-61. DOI=http://dx.doi.org/10.1145/105783.105793

Gary Klein, James J. Jiang, and Debbie B. Tesch. 2002. Wanted:project teams with a blend of is professional orientations. Commun. ACM 45, 6 (June 2002), 81-87. DOI=http://dx.doi.org/10.1145/508448.508452

Barry W. Boehm. 1991. Software Risk Management: Principles and Practices. IEEE Softw. 8, 1 (January 1991), 32-41. DOI=http://dx.doi.org/10.1109/52.62930

N. Jonsson, D. Novosel, J. Lillieskold, and M. Eriksson. 2001. Successful Management of Complex, Multinational R&D Projects. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences ( HICSS-34)-Volume 8 - Volume 8 (HICSS ‘01), Vol. 8. IEEE Computer Society, Washington, DC, USA, 8044-.

Catherine M. Beise. 2004. IT project management and virtual teams. In Proceedings of the 2004 SIGMIS conference on Computer personnel research: Careers, culture, and ethics in a networked environment (SIGMIS CPR ‘04). ACM, New York, NY, USA, 129-133. DOI=http://dx.doi.org/10.1145/982372.982405

Viviane Santos, Alfredo Goldman, and Cleidson R. B. De Souza. 2015. Fostering effective inter-team knowledge sharing in agile software development. Empirical Softw. Engg. 20, 4 (August 2015), 1006-1051. DOI=10.1007/s10664-014-9307-y http://dx.doi.org/10.1007/s10664-014-9307-y

Wikipedia. (2016, April 15). Swift trust theory. Retrieved from Wikipedia, the free encyclopedia: https://en.wikipedia.org/wiki/Swift_trust_theory

Weimann, P, Hinz, C, Scott, E and Pollock, M. “Changing the Communication Culture of Distributed Teams in a World Where Communication is Neither Perfect nor Complete” The Electronic Journal Information Systems Evaluation Volume 13 Issue 2 2010, (pp187 - 196), available online at www.ejise.com

Lori Anschuetz, Tec-Ed, Inc., “Managing Geographically Distributed Teams”, IPCC 98 Proceedings, the annual conference of the IEEE Professional Communication Society, 1998. http://teced.com/wp-content/uploads/2011/06/ipcc98la-managing-geographically-distributed-teams.pdf

Monica Yap, Successful Distributed Agile Team Working Patterns, SolutionsIQ, Inc. 2010 https://www.solutionsiq.com/docs/successful-distributed-team-working-patterns.pdf

Back to top