STARTING UP A GLOBALLY DISTRIBUTED TEAM: A PRESCRIPTIVE APPROACH BASED ON REAL-LIFE EXPERIENCE VALIDATED WITH RESEARCH

Introduction

An immense number of conditions can cause a project to fail, both internal and external. External factors such as contractual misalignment with execution, lack of managerial support, and misalignment of developers with customer expectations are just a few that can quickly scuttle a project. Internal factors such as misaligning processes or failing to account for social/cultural differences between teams often cause major project issues. While numerous external factors commonly cause projects to fail, the focus of this paper covers the internal factors and issues that arise in projects. This is depicted in Exhibit 1 – Internal Focus Impacting Success and highlights the focus of this paper. Success in a locally organized small agile team using DevOps (continuous integration, continuous delivery, and automated testing) has proven it can be successful when well run. As teams scale up, communication, interpersonal dynamics, and several other factors impact team effectiveness (Boehm & Turner, 2005). GDTs at scale have the same challenges as locally scaled teams plus additional challenges, time, and distance.

What is a globally distributed team? A globally distributed team, in this context, does not need to be global. It is simply a set of teams distributed over time and distance. Time and distance can be another building, state, country, or worldwide. Team communication is impacted by distance as little as another building or floor of a current building (Van den Bulte & Moenaert, 1998). Communication, or the lack thereof, is a common thread for project failure. With communication impacted, GDT principles apply as resolution and management tools for issues on the broader team.

As Director of Software Development, I had a team of about 50 developers. We were well into development, creating a new set of functionalities for our system. The company wanted more, and they wanted it faster. We struggled to stay on schedule with our current development, let alone take on more work. We began to get a lot of “help.” Management wanted more updates on status, wanted to know the plan and wanted more results. They pushed, we tried to expand, and fell further behind. They pushed more and harder. Management finally told us to use another team to help. The team was three time zones away. It felt wrong, like a really poor decision, but, at the time, we did not understand why it was a poor decision. The project ended late, over budget, and never delivered all of the promised functionality. Through research and experience, I now know why this was such a poor decision. I do not know if it would have changed management’s decision at the time, but it certainly would have influenced my approach to the problem. The story above is one of many experiences highlighting the struggle with going global in software development. Unfortunately, the project results are also prevalent.

Throwing people at the problem without a plan is not the solution. The schedule pressure in this situation is likely intense. Failure is not an option. How does one proceed from this situation? Going to a global or distributed team model can be an answer, but how can one do that effectively without worsening the situation? How does one start a globally distributed team avoiding the issues from the start? This article is a guide for starting or moving to a globally distributed team for software development. This article is possible because of academic knowledge gained through research and practical experience from starting and operating GDTs. This article starts with some assumptions as a basis for the starting point.

1. The project consists of at least one local team currently.

2. The project needs to scale rapidly to meet the desired market goals

3. People are not locally available to bring into the facility for any reason.

4. The cost of local engineering talent is more than the budget will permit.

The Starting Point

As a starting point, the assumption stated that at least one local team exists. Exhibit 2 – Starting Team Construct, shown below, provide a basic outline for the current team construct using Agile software development concepts. The team consists of business owners and stakeholders who have a vested interest in the project’s success. The Product Owner, an Agile Scrum term, is the person that has the vision of the work and specifies the priorities to complete broad capabilities. Another Agile Scrum role is the Scrum Master. The Scrum Master is the process owner for the team. The team consists of everyone needed to complete the work and produce a potentially shippable product.

A Working Model

Expanding from one team to multiple teams or from one location to multiple locations entails many factors, both “within” a single team and between the teams. The multi-team structure creates complex dynamics to account for and manage. Which factors impact the combined globally distributed team? How do the teams align when brought together? When analyzing teams separated over time and distance, what are the differences in the teams? Studies regarding how to fix an individual local Agile Scrum team are widely available, as well as coaches and consultants to fix any local team issue imaginable. However, there is no one fix to the issues exaggerated by time and distance. The barriers to success can collapse the team, delay product delivery, and break the organization. The barriers between teams arise from the alignment of the individual teams with the other teams in the GDT (Park, 2021). Exhibit 3 – Globally Distributed Teams Model depicts the alignment of teams coming together.

When considering what can and does affect the effectiveness within a team, one must analyze which factors impact just the local team and how these teams interact when brought together. The “within” team or individual local team factors can be categorized into Process, People, Organization, Technical/Project, and Team Leadership practice categories, as shown in Exhibit 4 below.  These local team factors combine to constitute the Team Practices for delivering value to the global team.

Regardless of the team size, the team’s structure, the varying capabilities of the team, and the distance between the teams, the barriers to building and running a successful team have to take the “within” and “between” team factors into account for success. 

From Models to Questions

With a working model as a guide, this section walks the model breaking down each factor into appropriate guiding questions and warning signs. From the guiding questions, choices, trades, and decisions, optimize the steps to form the best direction to move toward a globally distributed team construct.

Globally Distributed Teams Degree of Alignment. GDTs form when two or more teams come together, forming the development and delivery team. The GDT factors within a single team are visible as a between-team barrier if the individual factor is prevalent enough. All local team factors contribute to the overall team’s ability to deliver value to the customer. Concerning GDTs, there are factors that research shows stand out more when teams are combined. In the model above, the cloud depicts the degree of alignment. The alignment is visibly notable in terms of conflict, or lack thereof. This conflict may be the primary factor impeding the delivery of value to the customer.

When value is delivered to the customer, a cloud indicates conflict and obfuscates the team’s actions, as shown in Exhibit 2. When lifted, the veil of obfuscation identifies the storm clouds of conflict impeding delivery, as described by Hinds and Bailey’s research on the conflict between teams (Hinds & Bailey, 2003). When cohesive teams interact, various forms of conflict may result. The types of conflict manifest themselves as Task Conflict, Affective Conflict, and Process Conflict. While healthy Task Conflict is desirable, eliminating Affective and Process Conflict is desired.

Tools for Mitigation

Cross-Team Leadership. The forms of conflict are the measurable forms indicating potential issues for the leadership of a team to resolve. While this paper will discuss some methods to handle issues as they arise, the paper aims to help start a GDT without the issues. Not all issues are preventable, but good cross-team leadership is vital in resolving issues quickly and thoroughly.

Cross-Team Leadership has first to recognize when there is conflict before approaching, uncovering, and resolving the conflict. Conflict comes in many forms, with the following being but one example. Without cultural context, an American Cross-Team Leader may not recognize a problem with a Japanese or Indian team. The Japanese and Indian cultures have strong social norms to defer to leaders in hierarchical structures. If a team suddenly goes silent or affirms the leader’s request, the reason may be deferment and not agreement. A leader must be capable of recognizing this type of affective conflict. Without seeing through the lens of other social cultures, the leader is blind to the issue.

Leadership starts with mission clarity and vision. For each team, mission clarity, or “Start with Why,” as described by Simon Sinek, sets the vision and purpose for the team (Sinek, 2009). “Why” is the intrinsic motivation one feels toward achieving the project goals. When the team members share the same “Why,” they have the same motivational purpose. Shenhar couples the “Why” described by Simon Sinek with the concept of operation when he describes what he terms Strategic Project Leadership (SPL) (Aaron J. Shenhar, 2004).

• Does the overall project leader possess the mission clarity and vision for the project? When the leader communicates the mission and vision, it leads them toward the same shared mental model and direction.

• Is the overall project leader able to recognize the status of personal interactions between teams? The leader needs to be a builder of teams and understand distributed teams’ social and cultural dynamics.

Architectural Modularity. Architectural Modularity promotes independence and parallelism without cross-coupling impacts. The computer science principles of tight cohesion and loose coupling applied at the system level provides modularity and reduces the interfaces between GDTs. Architectural modularity reduces the required interactions between teams for technical reasons. Architectural Modularity can change as design changes are required. The increased interaction when architectural modularity is low causes significant delay in closing issues.

• Can the project be sub-divided cleanly so that each team has distinct interfaces where their deliverable parts are fully testable? Clear and distinct interfaces increase Architectural Modularity and the ability to operate in parallel.

• Utilizing automated tests to validate functional requirements and interfaces enforces the boundaries and allows each team to operate more independently. Automated tests of interfaces ensure integration executes more smoothly.

Degree of Dispersion. Research shows that a distance of 50-meters diminishes interaction (Carmel & Agarwal, 2001). Distances of different buildings, states, and over time zones increase the difficulty of reaching a shared mental model for smooth communication. Interestingly, the Degree of Dispersion seems to decrease based on boundaries and could be categorized as close, near, and far. Close is within the 50-meter distance described by Carmel and Agarwal. Near is on another floor, another building, or another region. The far distance would be across time zones. Experience confirms Carmel’s and Agarwal’s conclusions regarding distance and communication. There is no tangible difference in communication drop-off for people in the near-distance group until crossing time zone changes. Geographical dispersion of teams over time zones is the physical ability to communicate over time and distance (O’Leary & Cummings, 2007).

• Unless the Architectural Modularity is very high, it is recommended to have a significant overlap of time in the regular working hours of each team.

• Significantly shifting one team’s workday for long periods typically results in higher than expected turnover and other retention issues.

Team Practices Delivering Value

Team practices must be maintained and function with the broader set of teams. Any individual factor outside the normal parameters for all teams will create conflict.

Process. The Process sub-factor is the processes and metrics that govern software development. The process includes user story creation through feature sell-off in a production-like environment. The process used is less important than its consistency with respect to all other teams in the system. Inconsistent or incompatible processes by teams cause conflicts between teams.

• One team following a waterfall methodology with other teams following an agile methodology typically has issues. Process conflict reduces once teams deliver, integrate, and test on a schedule with regularity and similar quality.

• Product quality and stability are vital to the success of a project. Automated testing from the beginning of the project is the best way to ensure a quality product is delivered (Kim, Humble, Debois, & Willis, 2016).

People. The People sub-factor is the team’s social and emotional aspects, including items such as trust, customs, idioms, norms, and other similar factors. The most effective teams attain a shared mental model that allows members to know and more accurately anticipate team members’ reactions.

• Building a shared mental model (team bonding) is best done in person (Zahn, 1991). It may be difficult for a single local team to be completely in-person in this post-pandemic world, but team bonding is crucial in developing a successful team (Edmondson, 1999).

• The cross-team interactions are more challenging to develop a shared mental model. The best recommendations for developing a good working structure are “cameras on” during meetings, getting to know each other personally, and having in-person time together.

Organization. The Organization sub-factor includes all the needed support items, such as network, office space, training, people for the project, and management support. Organizational support is essential to provide the teams with the necessary support, training, and tools to accomplish the job. Overlooking the infrastructure needs when starting a project may cause significant delays and impediments to project success.

• Ensure the organization supplies the required network bandwidth, server power, development computers, test equipment, knowledgeable and capable people, and tools to execute the project effectively.

• Having to teach a new remote team Agile Scrum is a significant warning sign for project success. Experience demonstrates that the lack of knowledge and cultural transformation will negatively impact the GDT due to the remote management team not understanding the needs, vocabulary, and processes of the team they need to support.

Technical Skills and Domain Knowledge. The Technical/Project sub-factor is the technical ability to develop the software needed for the project at hand as well as the business domain knowledge regarding the project. The lack of knowledge of the business domain causes adjustments to process or requires additional support to be needed by other teams. The knowledge of what to build and the ability to complete the work are vital to the performance of each team.

• Having the requisite technical skills for development on the project allows the remote team to execute with authority and autonomy. No team or individual is a perfect fit for expansion. The warning sign regarding technical skills may look like a UI/Ux JavaScript frontend developer developing a C/C++ backend process or vice versa. One team lacking technical skills will entangle the teams and slow both teams. The lack of technical skills may also create an extensive and undesirable set of task, process, and affective conflict issues.

• Demonstrated experience shows that one team with extensive domain or business knowledge over another team causes a superior-subordinate relationship. This relationship issue’s visible signal is the lack of task conflict or debate regarding how a feature or capability should work. Moving this knowledge to an overall team management position generally helps. Breaking down the project so the remote team has an independent subsystem is another technique that generally helps.

Team leadership. Team Leadership is the strategic vision, communication skills, and emotional intelligence to know when issues arise. Good leadership is not about preventing the issue but handling it immediately, entirely, and transparently. The leader acts as the binding glue that works to recognize and eliminate conflicts and issues between the teams.

• The team leader looks inward to manage the performance of the team. At the same time, they must look outward to interact with other team leaders (A. J. Shenhar & Holzmann, 2017). The team leaders need to act as a team using the same skills, properties, and knowledge as the team members below them. Starting or expanding the team is the time to reorganize the leadership structure to fit the next organization rather than the past.

Building the Team

The first step is evaluating the starting position of the current team(s). Is the team a well-formed cohesive group? Does the team have extensive domain knowledge or unique technical skills? Does the team have an excellent agile process with automated testing as part of the culture? Looking for the benefits and warning signs within the current team informs the next steps in broadening the team to a GDT. While all of the factors and warning signs above are important, there is an order to consider when expanding or starting a team.

Understanding the Team Practices Delivering Value equates to building a local or remote team. Building the team is the foundational base of operation. Building a solid team in remote locations is just as vital as any existing team. Without this foundation, the globally distributed collective of teams will not be effective. The organization plays a significant part early in the team formation with facilities, training, and personnel assignments. Bringing the right people together with good leadership is not a simple task. To build the team, the team has to take ownership of their role and understand their strengths and weaknesses. The newly forming team uses their strengths and weaknesses to obtain training, develop compatible processes, and ensure they understand the domain.

With a foundation set, bringing the teams together is the next challenge. Starting with an understanding of the project’s Architectural Modularity and alignment of Processes can immediately mitigate other factors from significantly impacting the execution of the project. Architectural Modularity opens up options for parallelism and independence, while a process with a robust automated test system provides for robust deliveries of sub-products to the broader team. Process alignment is analogous to playing tug-of-war. Both teams are pulling in the same direction if the processes are aligned. The lack of alignment means the teams are pulling against each other. Alignment does not need to be identical, just cooperative. One team following agile practices and the other following waterfall practices find significant conflict throughout the development life cycle.

Developing Latitudinally (crossing time zones). Expanding an existing team latitudinally or crossing time zones is the most challenging expansion for existing teams. This is also many times called going East and West. Crossing time zones creates Degrees of Dispersion. There are two approaches found to mitigate the Degree of Dispersion. The first is to co-locate the new team with the legacy team for a while. From experience, the best approach is to relocate an existing team member to the new team’s location as the team leader. This provides the new team with instant knowledge and helps create the shared mental model between teams at a quicker pace. Locating all or part of the new team to the existing team’s location does help to bring the new team to productivity. Still, it is generally more expensive and, from observation, takes longer. Regardless of how the new team starts, they are playing catch up to all the other teams in the overall project. Factors that can have the most impact seem to be Architectural Modularity, Process, Leadership, and Domain Knowledge. Exhibit 5 - Team Expansion Latitudinally describes the expansion process. The expansion process described can be executed with one person or a more significant part of the existing team. The velocity of Team B will continue to increase if properly brought up to speed. If the velocity of Team B starts to decline, it is a potential sign that they need more training. Addressing alternative training mechanisms need to be addressed.

Latitudinally starting a new project has many more positives when compared to team expansion. All teams start with the same base, Domain Knowledge and Process. The teams are just forming, so all teams have to develop their shared mental model. The leadership team has to bond with the team and with each other. Assuming there is adequate Architectural Modularity, the Degree of Dispersion should not negatively impact the execution of the project.

Developing Longitudinally (spanning distance). Expanding an existing team longitudinally (going North and South) has the distinct advantage of not creating a Degree of Dispersion issue. The longitudinal expansion is shown in Exhibit 6 – Team Expansion Longitudinally. While Degree of Dispersion is not a significant issue in this model, communication and understanding are still the most significant issues to overcome. Similar to the East and West model, co-locating the team members or the leaders is the best way to move toward effective expansion. Co-locating brings the opportunities to teach the needed domain knowledge, harmonize processes, and get to know each other socially and culturally. Temporary co-location comes at a cost, but the benefits are significant. Building the bond of shared knowledge informs actions when no longer together. Whether a North-South or East-West model, the co-location activities take time. In general, experience shows the relocation or co-location time needs to be in the order of three to six months.

The North-South model is the best choice when the Architectural Modularity is low. Low Architectural Modularity is a major challenge with no good choice for GDT expansion. One should consider fixing the architectural issues prior to expansion. The overlapping workday provides time to work out issues and a faster response to the many questions. However, there is still an immense amount of waste occurring between the teams.

Conclusions

There is no one answer to expanding or creating Globally Distributed Teams. As a rule, start with Architectural Modularity. Increasing the ability to parallel develop without interaction significantly helps mitigate the impact of all other factors. Choosing to expand North-South or East-West could create fundamental impediments that impact the project cost and elongate the schedule, so choose the expansion model carefully if you get a choice. Accounting for Degree of Dispersion helps provide opportunities to communicate as much as possible. By itself, it is an impediment to be minimized.

The project is delayed when questions have to transition from team to team across time zones (Herbsleb & Mockus, 2003). Using the concept of Media Richness can help improve the ability to communicate, use the overlapping time during the day, turn on the camera, and schedule time for video meetings and calls. These steps will assist in creating the connection, convey more information between the teams, and determine answers more quickly.

Beginning with the end in mind, using the warning signs and questions, and applying good leadership over the project as it starts and expands will account for most internal project failure modes and signs. Expanding globally makes projects even more complex in this world of complex software projects. This paper attempts to address the researched internal project factors and experienced issues.

References

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22-29. doi:10.1109/52.914734

Daft, R. L., & Lengel, R. H. (1986). Organizational Information Requirements, Media Richness and Structural Design. Management Science, 32(5), 554.

Edmondson, A. (1999). Psychological safety and learning behavior in work teams. Administrative science quarterly, 44(2), 350-383.

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on software engineering, 29(6), 481-494.

Hinds, P. J., & Bailey, D. E. (2003). Out of sight, out of sync: Understanding conflict in distributed teams. Organization science, 14(6), 615-632.

Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook:: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (First Edition ed.). 25 NW 23rd PL, Suite 6314, Portland, OR 97210: IT Revolution.

O’Leary, M. B., & Cummings, J. N. (2007). The Spatial, Temporal, and Configurational Characteristics of Geographic Dispersion in Teams. MIS Quarterly, 31(3), 433-452. doi:10.2307/25148802

Park, B. (2021). DELIVERING VALUE TO THE CUSTOMER USING DISTRIBUTED SOFTWARE TEAMS : IDENTIFYING THE KEY RESEARCH FACTORS Paper presented at the ASEM International Annual Conference on Engineering Management, Virtual.

Shenhar, A. J. (2004). Strategic Project Leadership® Toward a strategic approach to project management. R&D Management, 34(5), 569-578. doi:10.1111/j.1467-9310.2004.00363.x

Shenhar, A. J., & Holzmann, V. (2017). The Three Secrets of Megaproject Success: Clear Strategic Vision, Total Alignment, and Adapting to Complexity. Project Management Journal, 48(6), 29-46.

Sinek, S. (2009). Start with why: How great leaders inspire everyone to take action. New York: Penguin.

Van den Bulte, C., & Moenaert, R. K. (1998). The Effects of R&D Team Co-location on Communication Patterns among R&D, Marketing, and Manufacturing. Management Science, 44(11-Part-2), S1-S18. doi:10.1287/mnsc.44.11.S1

Zahn, G. L. (1991). Face-to-Face Communication in an Office Setting. 18(6), 737-754.

About the Author

Ben Park, Ph.D., completed his doctorate in Industrial Engineering with an emphasis in Management Systems at the University of Central Florida (UCF), Orlando. Dr. Park has a Master's degree in Engineering Management and a BS in Computer Engineering, both from UCF. Dr. Park is a software engineering and development leader with 30 years’ experience developing and deploying custom-built software solutions. As CTG’s Director of Software Development, he leads a team of software development professionals that build flexible solutions to meet the needs of enterprise clients across industries. Dr. Park is a proven, motivated, and enthusiastic leader that understands how to apply a strategic vision to practice, seeks and forms collaborative teams, and transforms groups into teams aligned to a common vision. Dr. Park is an award-winning technical leader with the knowledge to design large systems of systems as well as small, embedded devices. With a Ph.D. focus in globally distributed teams using agile software development, he has a clear understanding of what is needed to operate in multiple time zones, locations, and cultures.

Timothy Kotnour completed his doctorate in Industrial & Systems Engineering with an emphasis in Management Systems Engineering at Virginia Tech in Blacksburg, Virginia. He completed his Bachelor of Science in Industrial Engineering at Bradley University in Peoria, Illinois. He is the Lockheed Martin St. Laurent Professor in the Department of Industrial Engineering and Management Systems at the University of Central Florida. He is the Director of the UCF Engineering Leadership and Innovation Institute and the Program Director of the Professional Engineering Management Program. He is the author of the books “Transforming Organization: Strategies and Methods” and “Inspiring the Leader Engineer: Instilling the Burning Desire and Confidence to Change the World.” Dr. Kotnour has been awarded three NASA Public Service Medals (2016, 2005, and 2001) for the partnership work with the Kennedy Space Center. He is also a Fellow of the American Society for Engineering Management (ASEM). He was past editor of ASEM’s Engineering Management Journal.