Team‐external coordination in large‐scale software development projects

High‐quality work is said to depend on team abilities. However, teams working in large‐scale projects often do not have all expertise to complete their tasks, which are also highly interdependent. Therefore, teams need to rely on coordination with other teams, experts, and supporting roles. In this paper, we explore teams' coordination needs and evaluate the impact of the satisfaction of these needs on team performance. We conducted an embedded multicase study with nine teams in two projects in two companies. We collected qualitative data through nine focus groups and 19 interviews and quantitative data using a questionnaire with 49 members from the studied teams. Our results suggest that project‐, team‐, and task‐related characteristics impact teams' coordination needs. Even in the same project, teams may have different expertise and work coordination needs. We found that the satisfaction of these needs seems to influence teams' performance, although our results are inconclusive and yield a closer look in future research. On the basis of our findings, we recommend the companies to cultivate a networking culture and support teams external coordination with other teams and experts, paying attention to their needs, for example, driven by a lack of experience or increased work complexity.

support the teams. Furthermore, task interdependences add to the complexity of coordination in large-scale projects. Examples of dependencies are shared resources, formal requirements and schedules, task interrelationship, and workflow constraints, 9,10 all of which need to be coordinated. Furthermore, the need for parallel work increases the level of complexity and the number of dependencies. More coordination is needed when requirements are written in parallel, and when many components are developed and tested in parallel. 2,11 Finally, a driver for even more complexity in coordination is distribution. You seldom find all teams and stakeholders within the same building in a large-scale project, which creates additional coordination challenges. 6 For all these reasons, effective coordination mechanisms is one of the keys to success in large-scale software development.
Software companies have used different approaches to address coordination challenges. 12 One approach is to focus on employing skilled engineers and on improving institutionalized knowledge and technology-based knowledge repositories. 13 Yet, keeping up active participation in maintaining up-to-date documentation is a constant struggle, 14 especially so in large-scale projects. Even then, not everything can be kept in knowledge repositories, as it is hard to codify "know-hows" (e.g., tacit knowledge). 15 Another approach to coordination is to focus on interactions between people or networking. 6,15,16 However, similarly to becoming an expert, establishing a coordination network requires effort and time, as understanding who knows what and establishing connections with the right people in large-scale projects is a challenge. 17 Mechanisms for cultivating social networks in large-scale projects are also not fully understood. 18,19 Finally, to address coordination challenges, software companies have tried to limit task interdependence with approaches such as centralization and modularization. 9 The centralization approach prescribes that certain functions such as communication with the customer, 3 system testing, or system integration 20,21 are centralized and moved out of development teams. However, this creates new dependencies and requires software teams to synchronize their work, including the exchange of feedback, with the supporting functions and roles. In the modularization approach, the software is split into modules. Modules are said to interact through well-defined interfaces, limiting work interdependences. However, software modules are rarely isolated, and therefore, maintaining and extending the modules can be difficult. 22 Work interdependences can also be addressed by coordination through interactions between the right people or interpersonal coordination. 9 Researchers emphasize that interteam coordination and coordination between teams and support roles in large-scale software development projects are challenging, 3,23 especially in distributed projects 6 because of organizational and temporal barriers and a lack of awareness of each other's work. 24 Besides, while many different approaches have emerged, none of them used single-handedly seems to be enough to solve coordination problems in large-scale software development projects.
In this paper, we contribute with further insights into team coordination in large-scale software development projects. In our study, we understand coordination as defined by Malone and Crowston, the management of dependencies among task activities. 26 We do know that in a large-scale project, teams need to coordinate dependencies with other teams, experts, and supporting roles in the project, which is known as team-external coordination. 27 We also know that development teams are very different and receive very different tasks, 17,28 but we do not know much about how different teams are affected by project-, team-, and task-related characteristics, as well as impact on their teams' coordination needs. We also do not know the extent to which team-external coordination can address teams' coordination needs and to what extent team-external coordination is needed to help teams perform in large-scale software development projects. 12,29 A better understanding of teams' coordination needs could help to decide what effort teams should invest in team-external coordination. Therefore, in this paper, we focus on teams' needs and teamexternal coordination in large-scale software projects and the impact of satisfaction of needs on the performance of the team (i.e., team productivity). 30

| Research problem
The purpose of this study is to understand the impact of team-external coordination in large-scale software development projects. To identify effective coordination practices, (1) we focus on the tasks software development teams receive, (2) how tasks affect teams' needs for coordination, and (3) what is coordinated by software development teams with other teams, experts, and support roles in large-scale software development projects. We also explore how team-external coordination impacts team performance. Therefore, our unit of analysis is a software development team in a large-scale software development project.
Our preliminary analysis demonstrated that team-external coordination differs significantly between teams. 17 Therefore, the next step is to understand why team-external coordination differs, for example, what circumstances and characteristics impact the need for team-external coordination. We know that software development is knowledge-intensive work, but in which circumstances do software development teams in large-scale software development projects need to seek knowledge from other teams and experts to complete their tasks (expertise coordination)? What are the characteristics of projects, tasks, and a team that impact the need for expertise coordination? Similarly, we know that tasks are interrelated in large-scale software development, but when do software development teams need to coordinate work dependencies with other teams and support roles in large-scale development? What are the characteristics of projects, tasks, and a team that impact the need for work coordination? These topics, expertise, and work coordination, more specifically, mechanisms for team-to-team and team-to-supporting roles coordination 18 have been recognized as a high priority topic in research on large-scale software development. 18,19 Thus, our first research question is as follows: RQ1: What characterizes teams' coordination needs in large-scale software development?
In practice, coordination takes time and effort. Therefore, software companies are interested in what counts as effective coordination, for example, when coordination helps to increase performance instead of taking time away from coding. Coordination between teams, experts, and support roles is gaining more attention in the research community. 19 However, little is known about the interplay between team-external coordination and teams' performance. One way to understand team-external coordination is to look at the content of coordination. Do teams address expertise and work coordination dependencies, and to what extent? If the expertise and work coordination needs are low, would the overly active networking influence teams' performance? If the expertise and work coordination needs are high, would the under-satisfaction of the teams' coordination needs influence teams' performance? Therefore, our second research question is as follows: RQ2: What is the relationship between team-external coordination and teams' performance in large-scale software development?
In this paper, we used an exploratory approach to understand the factors that impact teams' coordination needs, how teams seek expertise outside of the team, and how teams coordinate work dependencies with other teams and supporting roles. We selected two case projects where we had broad access to software development teams and where we were able to gather data about teams, their daily work, team-external coordination, and the content of coordination exchanges.
The rest of the paper is organized as follows: In Section 2, we present the theoretical background and related work on expertise and work coordination in software development. In Section 3, our study methodology and overall approach are described in detail, and the empirical cases under study are outlined, providing the contextual information of the studied companies, the teams, and their tasks. In Section 4, we present our results, which are discussed in Section 5. Section 6includes a summary of our main findings, the limitations of our study, and plans for future work.

| RELATED WORK
In this section, we start by defining coordination. Next, we review research on different coordination approaches, focusing on the success of these approaches in large-scale software development. Next, we review related work of expertise coordination and work coordination and respective coordination approaches. There we also review how project-, team-, and task-related characteristics can influence coordination needs and if characteristics have been reported to impact teams' performance.

| Coordination in large-scale software development projects
Coordination is needed to address dependencies among activities performed in an organization. 26 In this work, we rely on the definition refined by Malone and Crowston-coordination is managing dependencies between activities 26 -to identify and categorize dependencies 31,32 between activities in large-scale software development projects (see Table 1 for summary of definitions). In software systems, dependencies between different modules or services must certainly be managed, and, as teams are responsible for these services or modules, solving a task with dependencies means that teams need to interact. Furthermore, if there are no interdependencies, there is nothing to coordinate and no need for interaction. A software development team needs to coordinate constraints of, for example, requirements, testing, and integration, working together with requirement engineers, other teams, testers, and other support roles. Furthermore, one of the most critical resources for software development teams is expertise. 16 A team needs to coordinate with external experts (e.g., an architect) when solving tasks (i.e., expertise coordination). Malone and Crowston's theory of coordination is useful as an analytical tool, 33 and we apply this theory as our analytical framework. According to Malone and Crowston, 34 communication tools are important to manage the interdependencies between tasks. Components of communication are Definitions of terms

Coordination
Managing dependencies between activities. 26 Expertise coordination Interactions aimed at knowing where expertise is located, knowing where expertise is needed and bringing in the necessary expertise at the right time when working on tasks in software development projects. 16 Work coordination Interactions aimed at managing the alignment and integration of tasks, addressing dependencies that are inevitably created among teams working on software development projects. 2,9 Team-external coordination senders, receivers, messages, and languages. Examples of these components are team decisions that require members of the team to communicate in some form about the goals to be achieved, the alternatives being considered, the evaluations of these alternatives, and the choices that are made. Such communication requires some form of "message" to be transported from senders to receivers in a language that is understandable to both. Establishing a common language for actors to communicate is therefore necessary. Large-scale software development projects present some unique challenges to coordination that make them different from other software development projects. Effective coordination in software development was recognized as critical for successful software development several decades ago 3 and continues to be an important topic today. 18 Effective coordination in software engineering has been shown to be beneficial for project outcomes in different settings. 35 Task interdependencies, code complexity, and accuracy of documentation are areas of significant concern. 9,36,37 Previous empirical research established that coordination is easier, and there is a lower need for coordination when requirements are clear and stable, 38 when systems are maintained, with a good refactored architecture, and well documented. 39 It has been shown that a shared understanding of who knows what increases performance for small, self-managing, and co-located teams. 9,16 Most research on coordination in software development has focused on intrateam (within-team) coordination, finding that it is important that teams have shared knowledge on the tasks and how to do them, as well as who knows what in the team. 9,16,40 We know that in large-scale projects, coordination is more difficult for teams as it can take longer to find and become aware of the right people to talk to and get an answer from. 4 Similarly, in multisite development increases complexity of communication and coordination and cross-site work takes longer to complete 41 and have negative impact on team performance. 29 At the same time, networking had a positive influence on the effectiveness of global software development projects. 42 Previous research has shown that formal coordination provides some benefits for task outcomes, 35 and more communication helped to make interactions between teams better. 43 Research on interteam (between teams) coordination 12,35 has focused on vertical structures of coordination. 4,44,45 As a response to this, software companies have tried to create scheduled meeting structures. 44,46 However, research about formal meetings found that they often ended up more about reporting status instead of coordinating of expertise and work dependencies. 45 Other studies focused on mutual adjustment between individuals or through scheduled or unscheduled meetings. 46,47 Researchers have found that interpersonal coordination is important to coordinate the expertise and the workflow dependencies in the development process 28,48 as personal knowledge often rely on personal contacts to coordinate dependencies and improve team performance. 49 However, little is known about how teams coordinate, not only within or between teams but also with experts and supporting roles and what dependencies exist between teams and supporting roles. 12 Previous research has suggested that coordination problems can be identified by investigating mismatch between dependencies and networking patterns. 50 In summary, companies working with large-scale software development projects are still challenged to find the right coordination approach to address teams' coordination needs. 12 To better understand effective coordination in large-scale software development projects, companies need to identify and categorize teams' coordination needs in relation to different project-, team-, and task-related characteristics.

| Expertise coordination
Expertise coordination is interactions aimed at knowing where expertise is located, knowing where expertise is needed, and bringing in the necessary expertise at the right time when working on tasks in software development projects. 16 For example, a software development team needs to interact with other teams, an external expert, or an architect to locate and retrieve needed expertise. Furthermore, solving tasks in software development projects means that experts often need to work together. That is, a team needs to coordinate expertise when solving tasks. We know large-scale software development projects are associated with the need to possess an enormous amount of knowledge. 3,45 Furthermore, many large systems are built on monolithic architectures. When new features or changes need to be implemented, they are rarely isolated, which increases the teams' need to know even more about the system. 17 Enormous demands of expertise from development teams in large-scale projects have resulted in a significant amount of research aimed at understanding the factors that impact individual and team performance. We know that mature engineers outperform novices, 51 and we know what expertise is brought to the task and that coordination effectiveness will make a difference in the project outcomes. 29 However, we also know that it can take years for individual developers to obtain the necessary knowledge 52 in large-scale projects and that a single individual (or even a team) can often have gaps in understanding the entire system. 17,36 Sharing expertise between developers is a well-known challenge in any software development project, 15,53 and distributed development makes it even more complicated. 54 At the same time, effective expertise coordination within a software development team is linked to increases in team performance. 16 However, we also know that large-scale projects have additional demands for expertise coordination with many supporting roles (for example, system architects, system managers, system testers, and area experts) within or even across organizations in the case of distributed outsourcing projects. 53 Expertise coordination strategies in software organizations vary from those that focus on building organizational capital (for example, documentation) to those that focus on cultivating social capital (for example, communities of practice and other meeting forums). 15 The former is reflected in the technocratic knowledge management studies that emphasize the importance of institutionalized knowledge and codified experiences. [55][56][57] The latter are studies on behavioral knowledge management that focus on the importance of interactions between people and networking. 9,55,58-60 However, relying only on technocratic strategies is insufficient in large-scale software development projects because documentation gets outdated fast. 14 Large-scale software projects have used organizational strategies to address expertise coordination, for example, by implementing different team setups. Large-scale projects often employ either specialized teams working on certain parts of the product (component teams), universal teams working across different parts of the product (feature teams), functional (also referred to as disciplinary) teams that work only on certain types of tasks (testing teams, development teams), or cross-functional (or cross-disciplinary) teams that assume more responsibilities to implement an often end-to-end task. 1,5 When teams specialize in fewer functions or components, these teams might lack overall domain knowledge about the product to address dependencies within the system. 61 Feature or cross-functional teams might lack expertise in other parts of the system to create well-designed task solutions in the part of the system they are working with and address dependencies with other parts of the system. 17,61 In summary, different strategies for project organization and team setups can satisfy some, but not all, expertise coordination needs in large-scale projects. As another approach, some behavioral strategies emphasize expertise coordination by networking, especially to share tacit knowledge. 60 Previous empirical research has shown that there are several project-, team-, and task-related characteristics that impact the expertise coordination needs. Some studies have focused on the experience that is needed to complete a task successfully. 62,63 Teams' unfamiliarity with the task 9,17 increases the need for external expertise and decreases performance. Teams' familiarity with a task is impacted by factors such as (i) team member experience, (ii) team joint work experience, and (iii) availability of product documentation. Individual team member experience is associated with better team performance. 64 Team joint work experience is mentioned in the context that team members need to be aware of the knowledge of the other team members to collectively apply this knowledge to a task. 16,40,65 In the case of a lack of existing expertise, product documentation is one of the key knowledge resources. 17,66 However, not every software development task requires the same amount of expertise. Task complexity is important to consider when discussing how much knowledge a team needs to possess when solving a task. 9,16 Task interdependence is a factor that affects task complexity. When tasks are broken down to reflect the architecture or individual subsystems, teams might need additional knowledge about other subsystems and architectural layers, leading to requiring more coordination. 67,68 Coordination, in this case, concerns the actual work coordination (as discussed below) and expertise coordination, which means that the team should understand another team's subsystem better to implement a solution that will satisfy the integration requirements. In summary, previous research has linked several team-and task-related factors to an increase or decrease in the needs for expertise coordination in software development teams and the impact of expertise possession and coordination on team performance. However, it is not clear how each of these characteristics contributes to teams' needs for expertise coordination in large-scale software development projects and whether a team can address these needs by increasing team-external coordination.

| Work coordination
Work coordination concerns interactions aimed at managing the alignment and integration of tasks, addressing dependencies that are inevitably created among teams working in software development projects. 2,9 Tasks in software development projects require work coordination when the team needs to integrate their effort with others, and the output of another is needed as input to do their tasks. 69 Solving a task with dependencies means that teams need to interact with others outside the team to coordinate a variety of constraints. In large-scale projects, when hundreds of developers work in parallel, their actions require careful orchestration. 1,10 At the same time, distribution, which often is the case in large-scale development, also affects coordination between teams, experts, and support roles, creating fewer opportunities for interactions. 5 A common practice in large-scale software development projects is that work dependency coordination is performed by several coordinating roles and supported by standardizing the processes and ways of working. 70 Work coordination strategies in software organizations vary from those that focus on limiting task interdependence to those that focus on interactions between people. Impersonal coordination enabled by software architecture can be an important means to minimize the need for work coordination in software projects. 5,67,71 However, both modularization and standardization of work, especially in distributed and global contexts, have been recognized as either insufficient 39 or impossible to achieve. 5,37,72 The impact of coordination schemes, such as centralization or decentralization, has been studied, showing that coordination practices have significant influences on workflow coordination between teams. 28 Similarly, some coordination studies focus on means of work coordination. 73,74 Impersonal mode coordination prescribes and focuses on standardization, consisting of formalized rules, standardization, and policies and procedures, that is, the organizational strategies. 28,73 Personal mode coordination focuses on coordination by feedback and is enabled through mutual adjustment. 28,73 Coordination modes were previously used to study work coordination in large-scale software development, 47 and it was found that both scheduled and unscheduled meetings are important for coordination and that needs of work coordination change over time. Large-scale software development projects have been traditionally associated with plan-driven management and coordination by standardization. 20,21 However, empirical studies in large-scale software development suggest that the success of standardization and modularization is limited. 39 Considering these findings, networking as a mechanism of work coordination has been identified to be important. 4,9,12,17,75,76 Previous empirical research has established that there are several project-, team-, and task-related characteristics that impact work coordination needs. In software development, each development team needs to be familiar with the processes required to integrate their software development task in the final product successfully. Therefore, unfamiliarity with the processes in the project will increase teams' need for external work coordination, and teams will need to put effort into becoming aware of and addressing different process dependencies related to their tasks. 76 Factors such as (i) process stability and (ii) process documentation can ensure that people stay familiar with a process or learn about the process from readily available sources. When the process is stable, teams gain an understanding of ways of working on the project over time and require less effort to figure out and address task dependencies. 17 Sufficient process documentation on how task-related work should be done and well-documented ways of working will decrease the need for a team to seek this information in the rest of the organization. 66 Process complexity will also affect the need for work coordination. Process complexity can originate from (i) process dependencies and (ii) task dependencies. Process dependencies increase when certain development functions are placed outside of a team due to, for example, process centralization in large-scale software development projects. When that happens, teams have to rely on others. 67 Work dependencies in large-scale software development, for example, are the need to approve design proposals with architects, handshake on solutions with experts, or require external code reviews. 77 There is also an increase in work coordination needs when software development teams work in parallel with other teams on different software development tasks. 1 Process complexity can be further impacted by task interdependence, as tasks might have more dependencies with other subsystems and layers. 5 In summary, in previous research, several factors have been individually linked to an increase or decrease in the needs for work coordination in software development teams and how work coordination impacts team performance. However, as in the case of expertise coordination, it is also not clear how each of these characteristics contributes to teams' needs for work coordination in large-scale software development projects and whether a team can address these needs by increasing team-external coordination.

| METHODOLOGY
In this section, we describe the set of criteria for selection of the cases and describe characteristics of both cases we selected. Further, we describe data collection methods: interviews, focus groups and questionnaire and how data were collected. Lastly, we describe data analysis methods to determinate teams' coordination needs and visualize team-external coordination patterns and analyze content of reported coordination connections.

| Empirical cases
We aim to learn about and to better understand factors that impact team needs, team-external coordination, and performance in a complex environment-large-scale software development. To understand the characteristics that impact teams' needs and the relationship between the satisfaction of these needs by team-external coordination and team performance, we used an exploratory approach. 78 We conducted an embedded multicase study in which the unit of analysis was a software development team in a large-scale distributed software development project. 78 In our exploratory research, we relied on theoretical sampling to select cases. Cases were selected based on following criteria: (a) large-scale project, (b) distributed development effort, (c) that develops knowledge-intensive software solution, (d) offshore-inhouse software development project, and (e) company is based in Sweden. This allowed us to select two projects in companies that we had access to Project A and Project B and study nine selected software development teams. In both organizations, we selected teams from each of the main development locations. Development teams with overlapping and complementary characteristics were selected. We selected teams that are both mature as well as relatively new teams and teams that worked on tasks with different task complexity and interdependence. In Project A, all selected teams were feature teams. In Project B, all selected teams were component teams. This sampling was done with the help of company representatives.

| Case: Project A
The first case is from company that develops generic software products offered to an open market and complex compound systems with customized versions. At the time of our investigation, Company A had worked in agile development for almost 6 years and at present, agile practices have become standard practice. The investigated project in Company A is the development and maintenance of a subsystem that has multiple components and interfaces with other subsystems. The subsystem is very complex and contains several million lines of code. Eight years prior to our study, the company realized that it lacked competence in certain areas and experienced problems in the implementation of new features in the large-scale system. The size and complexity of the system domain and product knowledge are such that several years are required to become a knowledgeable developer. This resulted in a shift towards cross-functional development teams that are responsible for a feature from high-level description until its release to the customer. Setup of Project A is offshore-inhouse software development. The number of developers working on the subsystem grew from eight in 2007 to five teams in Sweden, eight in-house teams and two offshore outsourcing consultant teams in China, and two Korean teams. Cross-functional feature development teams were supported by additional roles for program management, product management, and release management. Development work at the time of our investigation in early 2014 was organized in 17 self-managing crossfunctional feature teams.

| Case: Project B
The second case is from company that develops automated software solutions and embedded software for various industries. The investigated project in Company B was a complex system with multiple modules with coupled dependencies and requires integration of expertise about vari-

| Data collection
Qualitative data from the multicase study were collected based on 16 interviews, nine focus groups, and observations from visiting five different sites in the two companies. Quantitative data were collected using a questionnaire that facilitated the collection of 49 responses in total (see Table 2).

| Semi-structured interviews
Interviews with individual members were organized for each of the companies. These interviews followed a semi-structured agenda, where individual members of different management levels were asked directly about the following: (i) project characteristics to clarify the type and complexity of the tasks in the investigated projects; (ii) their involvement in the project; and (iii) organizational process and connections that are necessary for teams when working on their tasks. In the interviews, we also asked project managers to describe the daily tasks performed by the teams that participated in focus groups. All interviews in both companies were performed in English, recorded, and later transcribed.

| Focus groups
After the interviews, focus groups with selected development team(s) members were organized in each of the companies. Focus groups is a research technique 79 that collects data on research themes through group interaction. Focus groups is a group interview based on interaction within the group of practitioners, based on topics that are supplied by the researcher, typically taking the role as a moderator. The explicit use of group interactions produces data and insight that would be less accessible without the interactions found in a group. This means that the researchers should have a active role in creating the group discussion and the iteration in the group as the source of data. 79 The focus groups followed a structured agenda, facilitated by the researcher. A portion of the time was dedicated to acquiring information about each team.
Themes were decided beforehand and derived based on research objectives. We asked each team about (i) the types of tasks they receive and the task characteristics such as familiarity, (ii) the presence of the skills needed to address the team's tasks, (iii) teamwork practices, (iv) interaction with other teams, roles, and communities, (v) teams reliance on different sources of knowledge in their daily work, the teams' perception of their performance, and (vi) the perceived usefulness of the team-external coordination. Focus groups were organized with nine selected development teams in total. We organized one focus group per team. The number of team in each of the company and total number of participants in focus groups are reported in Figure 2. In each focus group, the majority of the team members participated; however, some were unable to attend the focus groups as they were involved in training or on leave. The activities of all focus groups in both companies were recorded and later transcribed by the researchers.

| Questionnaire
A questionnaire was used and focused on capturing coordination contacts, that is, important connections of each team member from the same nine teams that participated in focus groups. Also, the participants reported the content of each connection to their contacts. The participants reported their contacts in a free-recall format. We decided to use a questionnaire because it is a common method for collecting empirical data in the social sciences and also is recognized in software engineering 80 as a means to systematically collect relation data. 81 We conducted a questionnaire with the same nine teams that participated in the focus groups. The questionnaire was web-based for the Company A Swedish site, whereas paper printouts were used for the Company A offshore site, two Company B Swedish sites. A web-based questionnaire for the Company A site was sent a few months later, but all other questionnaires were administered immediately after the focus groups. We partially replicated a questionnaire conducted by Manteli et al. 82 All respondents were asked to report their answer to the question "What kind of knowledge you transfer/receive from this person" with each identified contact in free text format. For each identified contact, they also provided an answer on the frequency of coordination with contact using the 5-point Likert scale (from Neverto Sometimes to Daily). Using this format, we collected team coordination contacts using a "realist" approach. By using this approach, we rely on the network that are perceived by the participants will correspond to the actual boundaries of social groups and organizations. 83 Participants in the paper-based questionnaires were given approximately 30 min to fill in as many responses to the questionnaire as they determined to be necessary in a "free-recall" format. Participants in the web-based *This column refers to the authors' participation in the data collection; the first author is A1, the second author is A2, and third author is A3 questionnaire were given 2 days to fill in as many responses as determined to be necessary, also in a "free-recall" format. A longer time was required for the online process because of the need of the participants to allocate time to this activity in their daily work schedule. We completed the list of recalled contacts and clarified these with company representatives to verify the names, roles in the company, and location. The size of the participating teams ranged from 5 to 9. Not every member of each team completed the questionnaire, resulting in a usable sample of 49 members and nine teams (see Table 3). (1) Company A: In total, 35 people from the six teams completed the questionnaire. The response rate for the six teams in total was 90%, and for individual teams, this rate did not fall below 71%. (2) Company B: In total, 14 people from three teams completed the questionnaire. The response rate for the three teams in total was 88%, and for individual teams, the rate did not fall below 67%.

| Performance measurements
Performance measures are an important consideration in group research. In a study of software development teams, 16 Faraj and Sproull found that expertise coordination within teams affected some performance measures but not others. We follow a similar scheme and use team effectiveness as a measure for performance. Team effectiveness was measured by evaluating five items: work quality, team operations, ability to meet project goals, extent of meeting design objectives, and reputation of work excellence. 84 Following Faraj and Sproull, 16 we collected performance data via subjective assessments made by the interviewees that occupied managerial roles. Although these evaluations were subjective in nature and also a threat to construct validity, we chose to use these measurements to compare performance across teams and companies, because objective measures, such as lines of code per person month or team velocity, might not be comparable across different companies and, thus, are often subject to misinterpretation. All items for team effectiveness were measured using a 5-point scale.
For each team included in the study, we collected performance measurements of team efficiency (five items). One response per team was collected from their respective line managers for the six teams in Company A and one response per team from respective line managers for the three teams in Company B. A summary of the collected performance measurements is presented in Table 6.

| Data analysis
Our data analysis followed a two-step process. The first step involved identifying and quantifying team task characteristics using qualitative analysis performed by coding the interview and focus group transcripts. Our approach entailed within-case and team-by-team analysis. The second step involved analyzing the questionnaire data in which we coded the qualitative part of the responses (the content of coordination connections) and then analyzed team-external coordination using social network analysis techniques.

| Analysis of teams' coordination needs
We determined team task characteristics by analyzing the data obtained: interview transcripts, focus group transcripts, and collected qualitative information about the teams based on the questionnaire. Transcriptions of interviews and focus groups and coding were done by first and second author, using NVivo software. We started to analyze teams' coordination needs using provisional coding process, where a predetermined list of codes based on previous research was applied to the data, 85 as illustrated in Figure 1. Specifically, we used an approach identified by DeCuir-Gunby et al. 86 to develop predetermined theory-driven codes as the strategy for the development of initial codes and coding. We determined theory-driven codes with our literature review of factors (based on Related Work Section 2.2 and Section 2.3) that influence teams' coordination needs in two categories: (i) expertise coordination and (ii) work coordination. In this literature review, we focused on reviewing factors and task characteristics that have been reported as having an effect on team performance. In Table 4, we report these factors and related effect (positive or negative). As a result of coding process, we identified the values of each of the factors for each team, as illustrated in Step 2 in Figure 1. In the second step, we used magnitude coding. Magnitude coding is a coding procedure to associate intensity or frequency to an existing code datum or category 85 . This process is used to quantify the extent of the individual teams task characteristic factors and mediating factors, to then compute the overall extent of the task characteristic factors. When computing the final magnitude of the task characteristics, we added our interpretation of the impact of each factor (task characteristics and mediators) for each team, as illustrated in Step 3 in Figure 1. The results of the coding process are shown in Table 8 (expertise coordination needs) and in Table 9 (work coordination needs).
Triangulation of the data sources was performed to increase the reliability of the resulting values. For example, we measured team member experience in two ways-by averaging each team member experience in the organization and by using the perceived level of technical skills and product knowledge in relation to team tasks, as discussed during the focus groups. Similar to the performance data, we used the 5-point Likert scale to express the magnitude of each factor (from Very Lowto Moderateto Very High). In a few cases, we were not able to determine the level of a factor because of missing or limited data from the focus groups (identified with a question mark).

| Classification of team-external coordination contacts
The analysis of connection classification followed a three-step process. First, the qualitative data that described the content of coordination connections from the questionnaire were coded and aggregated using the bottom-up approach. We piloted analysis by following the Provisional F I G U R E 1 Illustration of coding process to analyze teams' coordination needs Coding approach. 85 However, our coding soon revealed that the predetermined provisional codes based on the relevant literature review (Section 2) were insufficient. Therefore, we created a new iteration of coding and identified new common themes the content of coordination connections and refined the codes. Using refined codes, we classified each reported coordination connection into two separate categories: expertise coordination and work coordination, as illustrated in Figure 2. The result of this step is the classification of the content of coordination connections (see Table 5).
In the second step, we aggregated connections, to create a set of contacts for expertise coordination and work coordination for each team in the study. We used unique contacts per team measure because we focused on team-external coordination in general, not individual team members. 17,77 As such, this measure better represents the effective team-external coordination. We distinguished between contacts and connections in the following way: Connections indicate all reported connections by each team member, while contacts are unique contacts per team (e.g., if two team members report the same individual in their connections, this is counted as only one unique contact).
In the final step, we depicted team-external coordination. Team-external coordination patterns were visualized using the Fruchterman-Reingold layout algorithm. 87 The expertise coordination and work coordination are shown in different colors, and all team members are aggregated in a single node to emphasize the external coordination contacts.

| Team performance
In our analysis, we aimed to achieve a single score for the team performance based on the aggregated team effectiveness score. 16 First, we averaged the five items to develop a measure of team effectiveness (mean = 4.07, SD = 0.75). A summary of the performance measurements is presented in Table 6. To test for internal consistency of the performance measurements, we calculated the Cronbach alpha levels of all the variables.
The Cronbach alpha level of effectiveness is .86 on the team level. These values are above threshold level .7 recommended to constitute a good level of internal consistency 88,89 and also are in line with the levels achieved in the source of team performance measurement. 16

| RESULTS
In this section, we first describe each team and their networks for two categories: expertise coordination and work coordination. Second, we report on the teams' coordination needs for expertise and work coordination. Finally, we demonstrate the relationship between team-external coordination and teams' performance.

| Team-external coordination patterns
We summarized coordination contacts (unique team-external coordination contacts for a team) and coordination connections (total reported connections from all team members for a team). In Table 7, we report exhibited team coordination data based on the analysis of questionnaire data for two predetermined categories: (1) expertise coordination and (2)   external coordination contacts with the lowest number of reported contacts for work coordination (2 contacts) and below average number of contacts for expertise coordination (7 contacts). The results show that there is a large standard deviation in the work coordination contacts and connections, indicating that some teams have to manage work dependencies with others more often.  In Figure 4, we illustrate team-external coordination based on the number of contacts per respondent. The Figure 4 shows the relative differences in team-external coordination, and it can be seen that the number of contacts per respondent for expertise coordination is more even (eight

| Profiles of teams and their coordination needs
Here, we report team profiles with respect teams' coordination needs in two categories: (1) expertise coordination (in Table 8) and (2) work coordination (in Table 9). These are based on the qualitative analysis of focus group transcripts during which we coded the data with predetermined task characteristics (as described in Section 3.3.1). Qualitative data were quantified using magnitude coding (as described in Section 3.3.1).

T A B L E 7
Team-external coordination data In Table 8, we report factors that impact the teams' coordination needs for expertise coordination: (i) task familiarity, supplemented by three mediating factors: joint work experience, joint team experience, and product documentation; and (ii) task complexity, supplemented by one mediating factor: task interdependence. In Table 9, we report on factors that impact teams' needs for work coordination: (i) process familiarity, supplemented by two mediating factors: process stability and process documentation; and (ii) process complexity, supplemented by two mediating factors: task interdependency and process dependencies.
To understand the similarities and differences between different teams and their teams' coordination needs, in Figure 5, we plotted all teams based on two factors of task characteristics for each of two categories: (1) Needs for expertise coordination are determined by task familiarity and task complexity, and (2) needs for work coordination are determined by process familiarity and process complexity. We distinguished between four different quadrants of task characteristics (combinations of low/high in two factors of task characteristics). Based on the argument that teams in the same quadrant exhibit similar teams' needs for team-external coordination, we grouped these teams together to present a qualitative data summary of the task characteristics and their impact on teams' coordination needs. Different shapes in Figure 5 represent the affiliation to a specific group. We identified four different groups of teams in each of the two categories. In the next two sections, we describe the groups in each category, the similarities in the task characteristics within each group and differences in task characteristics between groups.

| Teams' needs for expertise coordination
In the first of the four groups, as shown in Figure 5 (left matrix), is teams (Team C and Team H) with moderate needs for expertise coordination, and teams in this group have high task familiarity and moderate task complexity factors. In the second group is teams (Team D and Team E) with low needs for expertise coordination; these teams have tasks with moderate task complexity and high or moderate task familiarity. The third group includes Team F with moderate needs for expertise coordination. The team receives tasks with low task complexity and have low task familiarity.
In the fourth group is teams (Team A, Team B, Team G, and Team I) with high needs for expertise coordination; these teams are assigned to tasks with high or very high task complexity and often are challenged working with unfamiliar tasks. To discuss groups, we follow the same structure for all groups and first report team member experience, affiliation, the presence of experts, then member "attrition" or team stability, the characteristics of the tasks, and finally, the characteristics of the team-external expertise coordination. The summary of these results is found in Table 8.

Group 1 (Team C and Team H)
Teams in this group show moderate needs for expertise coordination. The teams receive relatively familiar tasks with moderate-to-high task complexity, but the expertise coordination needs are moderate because teams in this group have a high level of competence. Need for expertise coordination.

T A B L E 9
Team-by-team analysis of needs Someone is always leaving or joining, but someone "old" always stays. Two out of five team members in team H are relatively new to the team.
The occasional work in unfamiliar system areas and an occasional increase in task complexity are the reasons for seeking expertise outside of the team. As noted by a member of team C with respect to the variance in their tasks: [Feature work] could be from half a year to a couple of months, and we also have trouble report sprints where we correct trouble reports for approximately three months.
Team C has a small number of team-external expertise coordination contacts with only four reported contacts (0.80 contacts per participant), and team H has the smallest number of team-external expertise coordination contacts reported from Company B ten reported contacts (2.00 contacts per participant).

Group 2 (Team D and Team E)
Teams in this group show low needs for expertise coordination. This is because these teams are relatively experienced for the offshore site and receive tasks with low-to-moderate task complexity.
Team D and Team E have an average of only 2 and 2.8 years of experience in the project, respectively. Joint work experience in these teams is moderate (average affiliation with the team is 2 for Team D and 2.2 years for Team E). Both teams rate their existing technical competencies and knowledge as moderate (on average). However, experiences are slightly different among the members of a team: Some of us are very strong.
Some of us are very weak. Generally, teams agree that they have the expertise needed to solve their tasks. Team E has expert members: It [experience] is average because we have some experts in our team and they may pull up the overall averages. In addition, team E has been one of the leading teams in the offshore location that trains newcomers. Team D does not have any formal experts in their subsystems. Both teams either have part-time members or some have joined very recently or have experienced frequent changes in team membership, as noted by a member of team E: Many team members changed during these three years. Member "attrition" and part-time members in these teams do not allow them to create a stable knowledge pool within the team. This increases the need to seek knowledge outside of the team, as a member from team D noted: Although we have a lot of people [in the team] we still have resource problem in our team because some people are just part-time.
Both teams receive relatively simple tasks, small features, and problem reports. Task complexity for teams varies and the longest features take up to 6 months, but there are also features that are as short as one or 2 months. Team E occasionally receives features with higher task complexity. Deficiencies in existing expertise in the team that was attributed to limited team stability and was one of the reasons that members sought interactions with older members and relocated to other teams until the needed experience was regained. However, team G also places a strong emphasis on teamwork, which limits their coordination with others.
Team E has reported 12 different team-external expertise coordination contacts (2.40 contacts per participant), while team D has reported six team-external expertise coordination contacts (0.75 contacts per participant).

Group 3 (Team F)
In this group (i.e., Team F), needs for expertise coordination are moderate. Although Team F receives tasks with low complexity, this team is relatively new and inexperienced and still needs to acquire more expertise to solve even those tasks.

F I G U R E 5 Grouping of teams based on teams' coordination needs
Team member experience in the company is low for Team F (average 2.2 years, all team members are new in the organization, except for one member with 11 years of experience). The team joint work experience for team F is very low, with an average affiliation with the team of 0.9 years. The team indicated that existing technical competence and product knowledge is low and that a significant amount of additional expertise about the system is required. Team F does not have any experts. The team is new, with numerous new members in the company and therefore has not created a stable knowledge pool within the team.
Team F is the offshore team and receives relatively simple tasks, small features, and trouble reports. However, because team F is inexperienced in the project, even simple tasks create the need to acquire new task knowledge to solve them. For new and inexperienced teams, product documentation is often the source of task knowledge, and Team F perceives that the source code is a good resource and that there is sufficient documentation on the system architecture. The team noted that some of the product documentation had not been updated recently.
Team F reported a small number of team-external expertise coordination contacts with seven unique contacts (1.17 contacts per participant).

Group 4 (Team A, Team B, Team G, and Team I)
Needs for expertise coordination are high for teams in the forth group. All teams are experienced and receive relatively unfamiliar tasks with high complexity.
The teams are very experienced in organizations (average of 10.8, 12.1, 17.2, and 11.3 years), and the joint work experience for all teams is high (average affiliation with the team is 3, 9.1, 6.1). The team members have a lot of existing technical competencies and product knowledge.
However, the teams also have indicated that they need even more expertise. A developer from team I admits: It's a very complex system. So you don't know everything about it. Although all the teams have experienced members, only Team B has a formal expert (area architect) as one of its members. All teams in this group have been relatively stable over the last few years except for team B, as two individuals and the team leader left, and one team member works part-time.
Extensive experience is often the reason they are assigned to complex tasks, as team A member noted: Features coming to us are more and more complex. I think that is a challenge. Team A also receives unfamiliar tasks relative to their peer teams: We have many senior people with very deep competence in specific sub-systems, and now they are learning other sub-systems. Complexity of tasks requires teams to seek new expertise from experts, as one team member stated: We are also comfortable with relying on experts in different areas. Further, from the teams' perspectives, the quality of product documentation is mixed, such that the more common parts are good, but a lot of effort is needed to identify it, and it is not always useful. This again leads teams to rely more on discussions with the experts from different product areas.
Two teams in this group Team A and Team G reported an average number of team-external expertise coordination contacts with 10 and

| Teams' need for work coordination
In the first of the four groups, as shown in Figure 5 (right matrix), is teams (Team G and Team H) with low needs for work coordination, as these teams are familiar with the process and work on tasks that are relatively isolated. In the second group is teams (Team D, Team E, and Team F) with moderate needs for work coordination because the tasks do not have many dependencies. In the third group, is teams (Team B, Team C, and Team I) with high need for work coordination. These teams work with interdependent tasks and in an environment with many procedures to follow (high process complexity). In the fourth group is team A, which has exceptionally high needs for work coordination, because this team works on tasks with very high task interdependence. In order to discuss these groups, we follow the same structure for all groups. We first report on the familiarity of the team with the process and the stability of processes and the quality of the process documentation in the project. Then we discuss process complexity in terms of two factors-task interdependency and process dependency, and finally, the characteristics of the team-external work coordination are considered. The summary of these results is found in Table 9.

Group 1 (Team G and Team H)
In this group, needs for work coordination are low. Both teams in this group are from Project B, where processes have been stable over time, and thus, the teams have high familiarity with the processes.
Both teams in the group are from Project B, which has been following a V-model development process for a very long time. Both teams have members that are experienced and familiar with processes. The process is well-documented as all teams must follow guidelines for safety-critical software systems development.
For both teams in this group, process complexity is moderate, as Team G and Team H from Project B are working on designated subsystems and thus deal with relatively independent tasks. However, process dependencies are high. Both teams have task-level dependencies because tasks require mandatory agreements with safety engineers for reviews, guidelines, documents for safety-critical reasons, and system-level dependencies. This is because the teams work on a complex product that involves interactions with hardware.
Both teams have a relatively small number of team-external work coordination contacts, as Team H reported 8 team-external work coordination contacts (1.60 contacts per participant), and Team G reported 7 contacts (1.40 contacts per participant).

Group 2 (Team D, Team E, and Team F)
In this group, needs for work coordination are moderate. Teams work with relatively isolated tasks, and all teams are from an offshore site from Company A, where process stability has been moderate at the time of the investigation.
Teams in this group are relatively new. Therefore, process familiarity is moderate to low because their knowledge about the process and ways of working is also relatively low, especially in the case of team F. Furthermore, team E perceives that there is room for improvement in better understanding about processes. Process stability is moderate, as Company A has recently changed some of the processes.
The teams have determined that the quality of process documentation is average and that this factor reduces the needs for work coordination.
Process complexity for all teams in this group is low. The relatively inexperienced offshore teams in Project A receive tasks with fewer task interdependencies. Process dependencies are relatively moderate as teams generally need to coordinate with technical experts (whom they need to involve in approving solutions) and testers. An individual from Team E indicated that there are requirements to handshake solutions with experts, such as system managers, design management teams, maintenance teams, function testers, system testers, and co-integration managers. Sometimes team F finds it difficult to agree on task solutions with technical experts, which leads to rework.
Team D reported 12 contacts (1.50 contacts per participant), and Team E reported 13 team-external work coordination contacts (2.60 contacts per participant), which in our sample is average. However, Team F reported only two team-external work coordination contacts (0.33 contacts per participant), which is low.

Group 3 (Team B, Team C, and Team I)
Teams in this group show high needs for work coordination. Although all teams in this group are senior teams in the company, they also work on tasks with a lot of interdependencies and must adhere to multiple and complex procedures.
Process familiarity for all teams in this group is moderate. However, the reasons are different. As previously mentioned, Project B follows the V-model, and processes have been stable, but Team I has been involved in the new development subproject with different ways of working. Team B and Team C are challenged by frequent process changes in their site, as onsite is used to introduce new processes.
The process complexity for all teams in this group is high. Team B and Team C from Project A work at an onsite office and receive diverse and interdependent tasks in different parts of the system. Team I has more team-external work coordination with others because Team I is responsible for the module that is interrelated with other subsystems. Working across subsystems also leads to more process dependencies, because it usually requires the team to anchor their solutions with experts outside the team, such as technical experts and architects in different subsystems, as Team I noted: We feel that we communicate much when discussing work coordination with others outside the team. The approach to work coordination in these teams is slightly different.
Team C and Team B indicated that they rely more on their experts in a team to address process dependencies, and Team C reported nine team-external work coordination contacts (1.80 contacts per participant). However, Teams B reported an above-average value of 14 for teamexternal work coordination contacts (2.80 contacts per participant). Team I indicated that it is actively coordinating with others but has reported 11 team-external work coordination contacts (2.75 contacts per participant).

Group 4 (Team A)
Team A has a very high needs for work coordination. This is a senior team in the company. Team A is differentiated from Group 3 teams in the same company in that this team receives tasks that have even more dependencies with other subsystems and layers.
Process familiarity for Team A is low, as they are challenged with recent changes in processes at their site, as the main office is used to introduce new processes in the project. For example, Team A is also involved in introducing many changes as a common object for pilot studies and trials: The team is the driver for continuous integration effort and the need for better tool support. Being a pilot team also means that process documentation may not be established yet.
Process complexity for Team A is very high because the members are working on tasks that have very high interdependency, as a team member noted: As far as I know, it is only [Team A] and (another) that work across sub-systems in this way. Team A also indicated that addressing process dependencies requires significant effort: Gathering information and deciding what to do and so on. What needs to be done and how it should be done.
It is hard to understand each time how to do it; you have to look at the process every time.
Team A has reported a very large number of team-external work coordination contacts with 30 unique team-external work coordination contacts (5.00 contacts per participant), which also includes a lot of informal experts and former members from the project.

| Relationship between team-external coordination and teams' performance
To understand the relationship between satisfaction of the teams' coordination needs by team-external coordination and how it relates to teams' performance, we have mapped the previously discussed findings with team performance data (see Figure 6). In the figure on the y-axis, we show respective teams' needs: need for expertise coordination and need for work coordination. On the x-axis, we show respective reported teamexternal coordinating contacts for two categories: expertise coordination and work coordination. Size is reported as the number of contacts per team member to normalize differences in participated team members and thus a comparison between teams. When teams are positioned on the diagonal (that goes through average size of reported coordination contacts point), this means that the actual number of coordination contacts has the potential to satisfy the needs for expertise and work coordination (the higher the teams' needs, the larger the number of team-external coordination contacts). Performance is visualized using a heat map principle. Each colored point in the figure is one team, and the color indicates team performance from 1 (red) to 5 (green). We expect that satisfied teams' needs will result in a better performance by the team, while unsatisfied needs will result in underperformance by a team. Both needs-for expertise and work coordination-should be satisfied to produce better performance in a team. Our results from analysis of teams' needs for expertise coordination and team-external expertise coordination contacts show that two out of four high performing teams are on or above the diagonal (Team I and Team G). However, two teams (Team A and Team C) are below the diagonal, whereby even though they have reported a small number of team-external expertise coordination contacts, they are performing very well. All four average performing teams are on or slightly below the line. Team F has very low performance and is also below the line. coordination needs categories and shows weak performance. This indicates that their teams' coordination needs are not fulfilled. Although Team C is also below the line in both coordination needs categories, this team is assessed as performing very well.

| DISCUSSION
We conducted a multicase study in which the unit of analysis was a software development team in a large-scale distributed software development project. Our focus was on understanding coordination in large-scale projects and the impact of team-external coordination. We had access to two large-scale software development projects, which allowed us to study nine software development teams in total. We were able to gather data about team-external coordination and the content of coordination activites. We have described coordination activities in large-scale software development projects using the definition by Malone and Crowston-coordination is managing dependencies between activities 26 -as our analytical F I G U R E 6 Team performance versus teams' coordination needs and team-external coordination framework. We have shown that in the development of large-scale software systems, dependencies between different modules or services are managed by team members coordinating with other team members, external experts, and supporting roles. While individual skills and knowledge have been considered to be important for team performance, 51,64 we argue that knowledge and skills are not enough to achieve performance in large-scale projects. In large-scale projects, dependencies between activities need to be managed effectively. Moreover, in large-scale projects, unplanned decentralized communication is essential for rapid responses when handling dependencies and therefore essential for team performance. We observed that communication in our large-scale study was mainly between teams, experts, and supporting roles, which we argue is a sign of decentralized communication. Decentralized communication is also an indicator of decentralized coordination and control.
We found several project-, team-, and task-related characteristics that impact teams' coordination needs, for example, complex tasks require the team to coordinate with many experts. Our study confirms the findings of Smite et al. 17 that found that networking is essential for teams when solving complex, unfamiliar, and interdependent tasks. Our study extends Smite et al. 17 findings by identifying different types of dependencies between activities and linking different project-, team-, and task-related characteristics to teams' coordination needs in two categories: (i) expertise coordination and (ii) work coordination. Expertise coordination is needed to address dependencies on one of the critical resources for knowledge teams -expertise. 16 For example, the software development team needs to interact with experts in another team to solve a task. Work coordination is needed to address a variety of constraints in the workflow, for example, when a team needs to integrate their effort with others, and the output from another team is needed as input to do their tasks. We also demonstrate that team-external coordination is often characterized by a large number of external contacts. That is, the team needs to communicate directly with many other teams, experts, and support roles, which highlights the importance of team-external coordination and decentralized communication. Furthermore, we found that teams often have many team-external coordination contacts to satisfy teams' coordination needs. Additionally, software development teams have different teamexternal coordination patterns, which depend on teams' coordination needs, highlighting that it is essential to understand teams' coordination needs to understand communication and coordination in larger-scale projects.

| Characteristics of teams' coordination needs in large-scale software development
To answer our first research question (What characterizes teams' coordination needs in large-scale software development?), we collected data on team member contacts with other teams, experts, and supporting roles and classified reported team-external coordination connections. In focus groups, we also collected data about each team and their daily work, which allowed us to characterize teams' coordination needs.
Our analysis of team-external coordination patterns and analysis from focus groups suggests that development teams in large-scale projects often have many contacts for coordination. Furthermore, our results suggest that teams often engage in decentralized communication, which is essential for rapid responses when handling interdependencies. Our results suggest two explanations for the high number of contacts and the need for decentralized communication. The first explanation is that for teams that are working on large-scale systems, demands for expertise are often very high, as it is rarely realistic for one team to understand the entire large-scale system, 35,36,53 and teams need to compensate for the knowledge gaps. 3,16,45 We found that highly experienced teams tend to receive more complex and interdependent tasks and may be challenged by tasks in unfamiliar product areas, increasing the need for expertise coordination. Therefore, teams that receive more complex tasks need to interact with many supporting roles, for example, system architects, system managers, and area experts. While new teams had a much smaller network than experienced teams, we still found that they had a high need for expertise coordination because they lacked the knowledge. The second explanation for the high number of external contacts and the decentralized communication is that teams in large-scale projects work in a multiteam environment and depend on supporting roles for certain functions (for example, requirements, testing, and deployment). 4,9,10,61 Our findings confirms previous research on coordination 4,12,18 that has demonstrated that inter-team coordination by mutual adjustment plays an essential role in large-scale software development. Furthermore, even when projects use a modularized system architecture, coordination is still necessary to solve work dependencies among teams 9,39 .
Our sample is too small for robust findings; however, an interesting observation was made concerning the differences between teams' coordination needs across the investigated projects. We found that component teams and feature teams possessed different needs and exhibited different team-external coordination patterns. Component teams show lower work coordination than the feature teams that have more coupled work, although these needs still exist and are not negligible. Our results suggest the explanation is lower task interdependence. We also determined that experienced component teams have higher expertise coordination than experienced feature teams because they are required to have basic knowledge about a number of unfamiliar components ( Table 8).
Results of semantic analysis of the project-, team-, and task-related characteristics and the analysis of teams' coordination needs show that the actual teams' coordination needs might vary greatly between projects and even within the same project. The teams studied related the expertise and work coordination needs directly to various task and project characteristics, namely, task interdependence, 67,68 process complexity, 67 parallel and interdependent work with other teams, 1 and product and process coverage with documentation. 17,66 We found that key factors that determine teams' needs for expertise coordination are task familiarity and complexity. Our results confirm that team members' experience in software development and team members' experience in the project will impact teams' needs for expertise coordination. 16 Teams' joint work experience will contribute to the effective use of the team knowledge pool, 40,65 reducing the need to seek expertise elsewhere. Furthermore, our results show that having an expert member on the team reduces the need for external knowledge pull.
However, we also learned that if these experts only work part-time on the team, their limited availability does not allow the team's needs for expertise to be fully satisfied. Finally, we determined that teams with multiple new members experience difficulty in satisfying teams' coordination needs because of the limited familiarity with project members outside of the team, and the low awareness of the knowledge level of members, and an inability to identify the experts. The challenge of locating expertise and awareness has also been noted in existing research on large-scale software development. 12 We found that key factors that determine teams' work coordination needs are process familiarity and complexity. We found that new teams can have low work coordination needs because they tend to work on simpler and independent tasks, 76 as long as processes are stable in the project. 17 Teams' work coordination needs will decrease when teams become more familiar with processes. However, we found that more experienced teams also tend to receive increasingly more complex and interdependent tasks, requiring them to solve more work dependencies, such as agreement on design solutions, doing code reviews, handshaking on solutions with area experts, and addressing task dependencies with other teams. Task interdependencies and, therefore, work coordination needs also increase as the teams work with tasks that have dependencies with other subsystems and layers. 5 Good process documentation was mentioned as one way to decrease work coordination needs for teams working in unfamiliar areas. 66 In summary, our results confirm findings of previous research that demonstrated that expertise coordination 10,16 and work coordination 9,10 are important parts of overall coordination efforts by teams in software development projects. Therefore, it is fair to state that maintaining teamexternal coordination contacts is important throughout the entire project life cycle. On the basis of the reported team-external coordination patterns, we observed that experienced teams also have more team-external coordination contacts on an individual team member basis, which must be a result of continuous contact growth over time. Based on the way they describe the use of team-external coordination at work, it seems that experienced teams are comfortable relying on their team-external coordination contacts and decentralized communication, and they have the ability to find the right experts when needed, instead of investing time in the process of building the knowledge internally or finding and studying documentation.

| Team performance in large-scale software development
To answer our second research question (What is the relationship between team-external coordination and teams' performance in largescale software development?), we also collected data on team performance. Our results from performance data (illustrated in Figure 7 and summarized in Figure 8) suggest that fulfilling teams' coordination needs by team-external coordination in both categories, (1) expertise coordination and 2) work coordination, seems to be important for improved team performance in large-scale software development. The results contribute to existing research related to the importance of expertise 16,53 and work coordination. 9,12,35 Evidently, we have outliers two teams with high performance and unsatisfied needs (from the perspective of our definition of the needs) in one or both categories (Teams C and G) and one team with average performance and satisfied needs (Team H). One possible explanation could be that their needs were overestimated and that, for example, the influence of formal experts in the team is greater than we assumed. In the case of Team C, there are two expert members (one who currently is a formal expert and one who was previously a formal expert). Another challenge is to understand the influence of expertise coordination needs versus work coordination needs because coordination in our case is a compound variable. We observed that unsatisfied work coordination needs do not appear to influence performance more than unsatisfied expertise coordination needs (based on Team G). We observed that Team A oversatisfied their needs of work coordination but has undersatisfied needs in expertise coordination and performs well. Moreover, it is evident that teams that fulfill both needs perform well (Teams E and I), while teams that do not fulfill their needs in both categories perform worse (Teams D and F). In summary, our results provide strong indications that team-external coordination matters for team performance. Unfortunately, given that our sample of teams is relatively small, we do not have a sufficient number in each of the groups (see Figure 8 for firm conclusions). As such, the direction of future research is to gather more evidence in a study with more teams with different profiles and different team-external coordination patterns (symmetrical and asymmetrical satisfaction of expertise coordination and work coordination needs).

| Limitations
There are some evident limitations in the reliability and generalizability of our findings. The first limitation is that much of the data collection and analysis was based on semi-structured interviews and focus groups. The consequence of this limitation is that the results are influenced by our interpretation of the phenomena observed and investigated. The use of multiple data sources (interviews, focus groups, and survey) made it possible to confirm evidence for the team coordination needs. The study included a survey, as well as talking to and interviewing team members and managers in both companies and at all sites of the teams investigated, which made it possible to investigate the phenomena from different viewpoints, thus reducing this limitation. There is a risk that our findings can also be explained by factors that evaded our attention. One reason is that we did not collect data from observations on actual team-external coordination but relied on self-reported data from the participants; therefore, we probably missed some team-external coordination patterns. In other words, we investigated the perception of the coordination and did not attempt to calculate or determine an objective measurement of the social network. Consequently, expertise and information sharing could have been exaggerated or underestimated by the respondents. Additionally, we collected team-external coordination data only once at a certain time point of the study. It is evident that coordination patterns can change over time based on changes in needs for expertise coordination and work coordination, as well as changes based on processes in the projects and personnel changes. However, giving feedback to the observed teams and managers and discussing our interpretation of the team-external coordination patterns helped validate our conclusions. Another consequence of this limitation is related to performance measurements. We used team performance evaluations, which are inherently subjective. Our use of this type of performance measurement is grounded in the fact that there are no available objective measures that can be used for measurements across multiple companies and facilitate comparisons in the same manner. However, discussing our interpretation with managers and the use of internal validity measurements helped improve the reliability of performance measurements. The second limitation is the use of magnitude coding for the analysis of the teams' needs from qualitative data obtained in semi-structured interviews and focus groups. Magnitude coding relies on researcher judgment to convert qualitative data into quantitative data. We mitigated this by triangulation. As the first step, the first and the second author coded qualitative data independently, and as the second step, both authors discussed any disagreements to decide on the final code.
Additionally, the provisional coding analysis of the questionnaire might be sensitive to the classification of team-external coordination F I G U R E 7 Characteristics that impact teams' coordination needs F I G U R E 8 Relationship between the teams' needs, satisfaction of these needs by team-external coordination, and teams' performance connections and further use in analysis of coordination and patterns. To reduce this limitation, the first and the second author coded qualitative data independently, and as the second step, both authors discussed any disagreements to decide on the final classification of each coordination connection. When converting quantitative scales into qualitative, special attention was given to discussing the convergence of the data toward a single scale and the necessity of taking the case-specific context into account. For example, what is very large in one context might be small in another context. In addition, we were limited to the data points available, and our magnitude and provisional coding might have been different if we had teams in our sample that exhibited even more team-external coordination. Further replications of our study in other contexts and with more teams could help in calibrating our magnitude scale and reducing this threat to conclusion validity; however, we believe that triangulation and discussion of the results with the case representatives helped to sufficiently mitigate this threat.
The relationship model of teams' coordination needs and their influence by team-external coordination and team performance also have limitations. Our model is based on a complex and real work environment of large-scale distributed development projects, which limits our ability to control variables that may influence team performance in such settings. This reduced the validity of our findings, for example, false attribution of team-external coordination behavior to teams' coordination needs or underestimating or overestimating teams' coordination needs and fully capturing all factors that impact teams' coordination needs. To assure Content Validity, we have discussed preliminary findings and conclusions of this study with the representatives from both companies involved. We received feedback that showed that conclusions were valid at the time of the study. We cannot guarantee that replicating the study in the same or similar contexts would lead to the conclusions. However, given the state of practice and tool advancement at the time of data collection and today, there is no reason to believe that the link between the satisfaction of the team coordination needs and team performance is not true today. Moreover, a recent application of the survey instrument for creating social networks in a modern product environment utilizing microservice architecture showed that the content and amount of coordination are comparable and that teams that were seen more successful had larger networks, while teams that were challenged had fewer contacts. 90 Further studies with additional data samples are needed to understand the full complexity of what factors impact team-external coordination in a large-scale distributed environment. Further studies that sample more teams with potentially different needs and team-external coordination patterns are needed to further understand the interplay between team-external coordination and team performance. Finally, the generalizability of the conclusions is impacted by the sampling strategy and the cases included in our investigation. We were only able to access two large-scale distributed software development projects at two companies. This limited our ability to use a more rigorous sampling technique in terms of teamexternal coordination research and to limit control variables of the teams' coordination needs. However, this allowed us access to the otherwise unavailable context, the large-scale distributed development for this type of study. We combined several instruments to improve the reliability of our conclusions (e.g., multiple data sources and cross-case triangulation). Gathering empirical data within similar conditions is required to generalize our findings.

| CONCLUSIONS
In this paper, we share the findings from an exploratory study of teams' coordination needs, especially when challenged with unfamiliar or complex tasks. Teams working in the same project often will have different needs depending on a variety of factors and thus should be treated differently. This means, for example, that mandatory coordination or communication fora and rituals might not be equally beneficial for everyone. Organizations should instead focus on enabling the teams to source expertise and address work dependencies with the right contacts when needed. Furthermore, to improve the support of teams, organizations should improve the awareness and availability of experts and support roles for teams. Organizations also should support the necessary infrastructure for local and cross-site expertise and work coordination. Finally, our study suggests that the satisfaction of teams' coordination needs is important for achieving desired performance. We suggest that future research should focus on extending the evidence of teams' coordination needs and team-external coordination patterns and their effect on team performance by increasing the number and diversity of cases, teams, projects, and task characteristics. We acknowledge that cultivating team-external coordination can require time and effort that could also be used for development work. Thus, future research should also explore cases in which too extensive team-external coordination can hamperteam performance.