Inter-team communication in large-scale co-located software engineering: a case study

Abstract

Large-scale software engineering is a collaborative effort where teams need to communicate to develop software products. Managers face the challenge of how to organise work to facilitate necessary communication between teams and individuals. This includes a range of decisions from distributing work over teams located in multiple buildings and sites, through work processes and tools for coordinating work, to softer issues including ensuring well-functioning teams. In this case study, we focus on inter-team communication by considering geographical, cognitive and psychological distances between teams, and factors and strategies that can affect this communication. Data was collected for ten test teams within a large development organisation, in two main phases: (1) measuring cognitive and psychological distance between teams using interactive posters, and (2) five focus group sessions where the obtained distance measurements were discussed. We present ten factors and five strategies, and how these relate to inter-team communication. We see three types of arenas that facilitate inter-team communication, namely physical, virtual and organisational arenas. Our findings can support managers in assessing and improving communication within large development organisations. In addition, the findings can provide insights into factors that may explain the challenges of scaling development organisations, in particular agile organisations that place a large emphasis on direct communication over written documentation.

1 Introduction

Communication plays a vital role in ensuring that the various development activities work in concert towards producing a software product in an efficient manner (Curtis et al. 1988; Bjarnason et al. 2011; Cataldo and Herbsleb 2013; Santos et al. 2015), especially so for large organisations. While requirements communication (Flemming 1978; Curtis et al. 1988; Damian 2001; Karlsson et al. 2007; Mallardo et al. 2007; Stapel and Schneider 2014), technical interdependency (Kraut and Streeter 1995; Begel et al. 2009; Bick et al. 2018), and mirroring the structure of the software within the developing organisation (Conway 1968; Parnas 2002) together with plans and processes (Herbsleb and Grinter 1999) are key aspects for management to consider when organising large-scale software development, an organisation also relies on communication between teams to deal with unforeseen events (Sosa et al. 2007).

The unpredictable nature of software development with unknown technology, unreliable estimates, changes in requirements etc., means that everything can not be planned from the start and unexpected issues need to be handled as they occur. Rather than wait for management to catch and address such issues, teams can resolve issues as they surface in an autonomous and responsible way. This is particularly important in organisations where teams have a high degree of autonomy regarding their tools and work practices. For example, in agile development organisations that rely on informal and organic communication as their main coordination mechanism. For such communication to support alignment and coordination of work between self-governing teams, it is vital that teams communicate with each other not only through formal communication as defined by processes and work practices, but also through informal communication between teams and individuals (Kraut and Streeter 1995; Herbsleb and Grinter 1999; Dingsøyr et al. 2018). Our case company is an example of such an organisation that faces challenges in retaining this informal and organic communication as their main coordination mechanism, as the company grows. While there is a host of research within software engineering on communication in general (Flemming 1978; Curtis et al. 1988; Damian et al. 2013; Stapel and Schneider 2014; Nundlall and Nagowah 2020), we are only aware of a few studies explicitly studying the communication between software engineering teams (Santos et al. 2015; Rahy and Bass 2019). Since this is an important and challenging aspect for growing companies, such as our case company, we wanted to investigate inter-team communication in the context of large-scale development organisations.

We view product development as a communication web where communication across organisational boundaries is an important success factor (Brown and Eisenhardt 1995), especially in large software development projects (Curtis et al. 1988), in general, and in particular, between teams (Santos et al. 2015). While distance is known to affect communication (Kiani et al. 2013; Bjarnason et al. 2018), there are also indications that other factors are at play such as experience, team size, culture, and interaction frequency (Kiani et al. 2013). We wanted to gain more insight into such factors and how they relate to distances and communication, and also understand what strategies that can be used to facilitate inter-team communication. Thus, we defined the following two research questions in the context of a large co-located software engineering organisation: RQ1 What factors affect inter-team communication and how do they relate to distances? and RQ2 What strategies are applicable to facilitate inter-team communication?

To address these research questions, we have performed an exploratory case study and studied ten teams belonging to the Quality Assurance department of a large R&D organisation that develops embedded software products. We studied the inter-team communication by measuring distances between these teams and through five focus groups at the company. The psychological and cognitive distances between teams were measured through self-assessment by using interactive posters where the teams marked their perception of other teams by placing stickers on the provided posters (Diebold et al. 2017). Preliminary results on how distances affect the communication between the teams are published in (Bjarnason et al. 2018) based on one (of five) focus groups. In this article, we present empirical findings based on analysis of the full set of data, consisting of factors affecting inter-team communication (RQ1) and strategies for facilitating the communication between teams in software engineering projects (RQ2).

The rest of this paper is structured as follows. We present the concept of distances in software engineering in Section 2, and related work on inter-team communication in Section 3. The case company is described in Section 4 and our research method in Section 5. We present and discuss our results in Section 6. Finally, we conclude and outline future work in Section 7.

2 Background: distances in software engineering

While communication may be challenging within smaller projects, scaling to a larger organisation with hundreds of engineers is a different kettle of fish largely due the impact of distances on the communication within software engineering (Herbsleb and Grinter 1999; Bjarnason et al. 2011; Bjarnason and Sharp 2017). In large-scale software engineering, the work and the engineers need to be split and organised into smaller units, which requires coordination of the work and inter-team communication to deliver a common, and often complex, end product of high quality. This causes challenges both within global software engineering (Herbsleb and Grinter 1999; Begel et al. 2009; Kiani et al. 2013; Nguyen-Duc and Cruzes 2013) and for large co-located software development organisations (Curtis et al. 1988; Karlsson et al. 2007; Bjarnason et al. 2011; Bjarnason and Sharp 2017). In our previous research, we have investigated how distances affect communication within large-scale co-located software development, and found that effort is required to effectively communicate across distances and that software development practices can be used to bridge or decrease these distances and thus mitigate the risk of communication gaps (Bjarnason et al. 2016). For example, misunderstandings about requirements can be reduced through cross-functional reviews of test cases where roles from different parts of the organisation, often located on different floors or buildings, are brought together thereby mitigating geographical, organisational and cognitive distances (Bjarnason et al. 2019).

The Theory of Distances in Software Engineering (Bjarnason et al. 2016) is an empirically based theory that poses that distances affect the amount of effort required to communicate within software development and that distances increase the risk of communication gaps. For example, when there is a cognitive distance (or difference) between people regarding the amount of domain knowledge for the system or component under development, additional effort is required to ensure that the requirements are uniformly understood within a development project. Software development practices can mitigate distances, and thus affect the alignment of development efforts. For example, cross-role communication in which roles from different teams work together on an activity can mitigate cognitive distance by increasing the amount of direct communication and thereby reducing the knowledge gaps.

A distance is defined as ‘a difference in position or level between entities’, i.e. actors, artefacts or activities within software development (Bjarnason et al. 2016). A distance requires effort to traverse in order to perform a software development task and can negatively affect the communication of requirements (Bjarnason and Sharp 2017). The Theory of Distances defines eight types of distance between people, between artefacts and between activities. The distances between artefacts are adherence (similarity between an artefacts description and the actual situation), semantic (similarity in meaning between artefacts), and navigational (distance to navigate between related parts of different artefacts), while temporal distance denotes difference in time between performing activities. In this paper, we focus on the distances between people, and in particular, between teams, namely the following distances:

• D1 Geographical. The physical distance between the positions of actor’s workplaces. For example, a physical distance between a product owner and the testers often has a negative effect on the frequency and ease of communication of requirements. A geographical distance can cause delays and misunderstandings in the communication with distant team members.

• D2 Organisational. The distance between actors’ placement within an organizational structure, e.g. level within a hierarchy of units and departments. For example, when stakeholders and project members are from different parts of an organisation they may have different objectives and priorities. Organisational distances can cause difficulties and delays in decision-making, e.g. concerning conflicting views on which requirements to support.

• D3 Psychological. The subjective level of effort perceived to be required by one actor to communicate with another actor. For example, a tester may be reluctant to ask for clarification of requirements if they believe it takes a lot of effort to communicate with the relevant person. Psychological distances can cause conflicts and difficulties in agreeing, e.g. when discussing requirements details.

• D4 Cognitive. The difference in levels of cognition between actors, i.e. knowledge, competence and understanding. For example, differences in domain knowledge between a product owner and the development team can lead to differences in understanding of a requirements change. Cognitive distances can also cause both misunderstandings and missed communication.

While distances require additional effort to traverse or bridge and in general have a negative impact on software development organisations, there are instances where long distances can a positive effect and can be used to stimulate creativity and independence within an organisation. Creativity and creative solutions are the results of recombination of existing ideas and experiences (Amabile 1988), and are encouraged by greater distances, or differences and diversity, within a team or organisation. De Vaan et al. found that creativity was facilitated for cognitively diverse teams of video game developers when there was “a workable space where some misunderstanding is tolerated in the interest of creating a new creole [a merge of cultures].” (de Vaan et al. 2015) Thus, good and functioning communication between these cognitively distance people creates a space where creativity can occur.

The other instance where distances between people are beneficial, is independence and a team’s freedom to pursue a task without being hampered by knowledge from or relationships to others. We observed this in a previous case study, where system testers were organisationally distant from the development teams. In this case, the distance to others enhanced the test team’s ability to independently interpret requirements, detect and report issues (Bjarnason and Sharp 2017).

3 Inter-team communication

Most of the research on communication within software engineering is found within the context of large-scale development, in particular global software engineering (Herbsleb and Moitra 2001; Avritzer et al. 2010; Stapel and Schneider 2014) and/or agile software development (Yagüe et al. 2016; Bjørnson et al. 2018; Rahy and Bass 2019; Nundlall and Nagowah 2020). Existing research within this field, to a large extent primarily focuses on coordination with the general aim of organising software development projects in a way that decreases the need of coordination especially between sites and distant teams, and thereby minimising the need for communication across distances while maximizing communication within teams (Avritzer et al. 2010). Similarly Bass et al., see both direct and indirect communication (through artefacts or processes) as means of coordination (Bass et al. 2009). For co-located software engineering, the research related to communication is mainly within large-scale agile software development and on coordinating multiple self-governing teams (Paasivaara et al. 2012; Bjørnson et al. 2018) including knowledge networks (Šmite et al. 2017), and softer aspects such as common values and norms (Nyfjord et al. 2014; Paasivaara et al. 2014). Research specifically on inter-team communication within software engineering is sparse with the exception of work on knowledge and information flow between teams (Santos et al. 2015; Rahy and Bass 2019).

3.1 Large-scale Agile software development

While research specifically on inter-team communication within agile is limited, the topic strongly relates to inter-team coordination and knowledge sharing both of which have been identified as key research challenges within large-scale agile development (Bass 2019). Santos et al. have identified a number of factors that influence the effectiveness of knowledge sharing between teams within agile software development both positively and negatively (Santos et al. 2015). These factors including organisational and physical structures, culture, management style, communication flow including the use of tools to support knowledge sharing. In addition, the pressure of quick and frequent delivery of working software tended to lead to teams focusing primarily on their own tasks, and down prioritising sharing and communicating with other teams. This study also identified three stimuli that trigger communication and knowledge sharing between teams, namely problems, common goals or interests, and external incentives such as a free lunch seminar.

A standard way to manage large agile projects with multiple teams is to host Scrum-of-scrum meetings to coordinate the work of the different teams. However, Paasivaara et al. found that this practice does not scale well. When there are too many participants with disjoint interests these meetings become very long and inefficient. An alternative more efficient approach can be to host multiple meetings where teams with shared goals, e.g. working on the same feature, gather to communicate and coordinate their work. This content or architectural-based model appears to be more effective, but there is still a need for project-wide synchronization (Paasivaara et al. 2012). Another approach to facilitate knowledge sharing is the use of guilds, which was studied by Šmite et al. at Spotify who found that this type of arena can enable knowledge sharing across an organisation in a bottom-up fashion and align development practices across teams and sites (Smite et al. 2019).

Rahy and Bass studied tools for inter-team communication within agile software development for a distributed SME context consisting of in total 65 employees working at 2 sites (Rahy and Bass 2019). In this case, a common virtual Kanban board was used to manage project work and progress. While the majority of employees recognized the value of using such a shared digital workspace, there were varying preferences concerning the communication method of choice, face-to-face or tool-based communication like Slack or Skype. When these different preferences concerning communication channel occurred between teams, this caused inter-team communication problems, which in turn could result in slow response, or lack of awareness.

Dingsøyr et al. studied the communication patterns of an agile development programme consisting of 12 teams and a total of 175 people, and found a wide range of formal and informal communication arenas at the group and personal level (Dingsøyr et al. 2018). The formal meetings included demonstrations, management meetings called metascrum, Scrum-of-scrum meetings per sub-project. Experiences were shared across teams within each sub-project through various types of forums, e.g. lunch seminars and technical corner. Informal and impromptu meetings were facilitated by co-location and often took place in the various team areas. Communication at the individual level was seen as crucial for the collaboration and was supported by several factors, including co-location, a helpful culture, and social interaction points such as common lunches and coffee breaks. In addition, job rotation was consciously used to distribute knowledge between teams and sub-projects, although resistance to this increased over time. Another important communication strategy was management-by-walking, where the managers would visit teams, talk to them about their status and issues and spread information. Finally, the development programme used a main plan to coordinate all work packages and epics. This plan was initially stored in a document, but later transferred to an issue tracking system where all teams could follow the progress.

Bjørnson et al. studied inter-team coordination within a large agile IT programme consisting of 175 people running over 3 years (Bjørnson et al. 2018). In this context, they identified three mechanisms applied at the inter-team level, namely shared mental models, closed-loop communication, and trust. They observed that as the work on describing the solution progressed, the people gained a shared mental model, which enabled more efficient communication between teams. The shared mental model was supported by gaining a shared understanding of the work process, the tasks and a shared awareness of who knew what. For example, by rotating engineers responsible for contributing to the solution description. Closed-loop communication between teams was achieved through a combination of formal and informal communication channels including mini demos, daily stand-ups, Scrum-of-scrums and by co-location, and by having specialists act as informal contact points for the teams. These mechanisms lead to an overall increase in domain knowledge between the involved entities that facilitated inter-team communication. In terms of distances, the cognitive distance decreases as a team gains similar knowledge, thereby facilitating effective inter-team communication. This aligns with previous research on awareness and how knowledge of what other people are doing supports communication by guiding both the sender and the receiver in how to formulate and interpret what is communicated through awareness of cultural context, domain and individual knowledge (Gerosa et al. 2003).

3.2 Global software engineering

There is a need for effective and efficient communication between teams in global and large-scale software development organisations, where teams are spread over several buildings, campuses, and time zones. Begel et al. studied this at Microsoft and found that there is a high cost to manage inter-team dependencies and that a lot of time and effort is spend on communicating with other teams (Begel et al. 2009). For example, to ask for status updates, dealing with the effect of un-notified changes, reaching agreements with other teams about necessary changes and ensuring that they are realised. The pre-dominant communication channel between teams is e-mail, while direct contact is taken 50% less frequently than when resolving issues within teams (intra-team). Furthermore, issues are often resolved through escalation to managers or by setting up specifics meetings to discuss the issue at hand. The predominant communication strategy advocated by most teams is to maintain personal connections with people from dependent teams. Begel et al. found that teams are depended on the following artefacts from other teams: release schedule, prioritization and status, features, APIs, bugs, documentation, and code. The main strategies for mitigating coordination issues is to minimize the dependencies, align their schedules and to have a back-up plan without the problem dependency. In addition, communication plays a vital role in managing dependencies by tracking existing dependencies by email, through a work item database and through status meetings, and to a lesser extent by using other tools such as excel, outlook tasks, websites or simply by remembering them (Begel et al. 2009).

Weak awareness of dependencies between teams is one major reason for misalignment and in-effective coordination in large-scale distributed software development projects, as was concluded by Bick et al. They found that while coordination worked very well within teams, there were severe issues with inter-team communication due to a lack of awareness of dependencies that in turn were due to the challenges of pre-planning development work, and the inherent conflict with the agile practice of performing requirements and design work just in time rather than upfront (Bick et al. 2018). These problems frequently caused delays as teams were blocked by unforeseen events caused by unidentified dependencies. These issues were dealt with by escalating them to a central team, thereby handing over the responsibility for resolving the issues, with subsequent risks of communication gaps.

The awareness between teams in large-scale distributed development organisations is affected by distances, as well as by factors such as experience, team size, culture, and interaction frequency (Kiani et al. 2013). Kiani et al. found that lack of work, company or team experience within a team had a negative effect on inter-team awareness, while teams with highly experienced team members had a high degree of awareness other teams even when geographically distant. They also found that team size is negatively correlated to awareness, i.e. small teams have a higher degree of awareness of others than large teams. In addition, a culture of frequent discussions and learning about each other’s work, as in agile development, has a positive influence on awareness. In contrast, Kiani et al. found that for co-located teams without this culture (predominantly non-agile teams) there was low inter-team awareness. Finally, frequent communication with distant teams can increase the level of inter-team awareness, and was found in teams that were either small or agile (Kiani et al. 2013).

Nguyen-Duc and Cruzes found that within global software engineering, organisational boundaries affect the coordination between teams in several ways including challenges with aligning collaboration policies, organizational structures and development processes (Nguyen-Duc and Cruzes 2013). These differences in culture and work practices caused issues and have a negative effect on the communication and awareness between organisationally distant teams. The extent of the challenges seems to correlate to the organisational distance between teams, and multiple mechanisms are required to ensure sufficient coordination across organisational boundaries, of which team contact points acting as boundary spanners play an important roles in support good inter-team communication.

This role of boundary spanners and how they contribute to efficient inter-team communication was further explored by Nguyen-Duc et al. through a multi-case study of four global software development projects (Nguyen-Duc et al. 2014). A boundary spanner contributes to communication between different parts of an organisation by having good leadership and decision-making skills, inter-feature technical expertise, and inspires and relies on internal team recognition. These competences are used for navigating task-related information, and for negotiating and resolving conflicts between teams.

Šmite et al. found that most development teams that perform complex or unfamiliar tasks rely on team-external networking and sharing of knowledge with others. They identified a number of factors that influence the size and behaviour of these networks in which communication takes place (Šmite et al. 2017). For example, the extent of a team’s company experience affects the size of this team’s social network, where people with more experience tend to have a larger set of contacts. Participation in forums and communities of practices increases the amount and frequency of interaction and communication between teams, and increases the size of social networks. The study also found that teams seek information and communicate on the basis of need, thus teams working on complex and unfamiliar tasks, or with changing and unfamiliar work processes, are forced to reach out for information and synchronise with other teams. The importance of certain coordinating roles, contact people, or boundary spanners, was also confirmed in the shape of formal experts that communicate knowledge between teams. Finally, the study also found that personality and team culture have a strong influence on how teams interact and communicate.

Finally, socio-technical congruence is an approach that aims at supporting communication needs by aligning the social networks within a global organisation with the technical dependencies of the software that is to be developed (Cataldo et al. 2008; Avritzer et al. 2010). The underlying conjecture is that the technical structure of the system mirrors the communication needs of the people working on the different components. Cataldo et al. found that development productivity is enhanced when the coordination patterns of developers align with their coordination needs, and that changing coordination needs is a major obstacle, or challenge for distributed development organizations (Cataldo et al. 2008). Herbsleb and Grinter conclude that distances need to be overcome through a combination of informal communication and coordinating architecture, plans and processes, due to the evolving and changing nature of software development (Herbsleb and Grinter 1999). In addition, they suggest a combined approach of both reducing the need for cross-site communication through design, organization and documentation, and to overcome communication barriers through wise use of cross-site travel, contact roles, and tools supporting awareness and collaboration.

4 Case description and problem motivation

Axis Communications offers intelligent security solutions and network products based on an open platform. Axis has over 3.000 employees. Over half of the employees and the majority of research and development (R&D) are based in Lund, Sweden. R&D covers a wide range of fields, from mechanics and electronics, embedded firmware, to server software and mobile apps.

There is a Quality Assurance (QA) department within R&D that provides testing for the different R&D departments. At the time of the study, the QA department employed 185 test engineers organised into ten test teams, see Table 1. These teams are responsible for testing either products, such as cameras and hardware (teams Camera 1–4, Hardware), or systems including client software for these products (teams Client 1–3). In addition, there is a team that supports the other teams with tools, test environments etc. (team Infrastructure). All of the teams work closely with a development team, while organisationally the test teams belong to a common department.

Table 1 The test teams included in the case study, the testing targets for which they are responsible and the number of members with senior titles of the total number of team members

Axis’ way of working is based on a corporate culture of cooperation and openness to change rather than on plan-based processes and formal communication channels between teams. Rather, the company promotes direct communication and cooperation through informal communication and direct interaction between employees in different parts of the organization. This is encouraged and manifested in the company’s decisions to use the ability to cooperate as a criterion when recruiting, to encourage new employees to talk directly to other employees, and to have the majority of research and development co-located on a single site. The company also encourages informal meetings between people that usually do not work together, both through everyday activities such as coffee breaks and through organized activities such as department days (QA days for the QA department) where people are encouraged to mingle with people that they do not know. However, during the last decade the organisation has grown thus making it increasingly hard to coordinate through direct communication between people. The company’s preference for working in this open, collaborative, and flexible fashion rather than through a planned-based development model is one of the main reasons for initiating this study.

The part of Axis that is studied in this research, namely the Quality Assurance (QA) department, has grown during this past decade, from less than 20 in 2008 to over 180 people in 2018, and from one team located on the same floor to ten teams spread out over different buildings. (This study was performed during 4 months at the end of this time period, i.e. winter 2018/2019.) Teams have grown in size and been reorganised into multiple teams as they have become too large for one manager. The QA teams have been organised to match development teams, who in turn have been formed around specific products and or product components. This has the benefit of allowing teams to specialize in certain products or components, but also the drawback of distributing the understanding of the whole system that these products and components are a part of, over multiple teams. All of the products and components that the teams work on have interdependencies, either as components that together make up a product (e.g. a camera) or through products that communicate through network APIs (e.g. camera and client). Some teams are located within the same office area, while other teams are dispersed over different floors or buildings within the site and some testers are placed with the corresponding development team that they are working with. The whole QA department used to meet weekly, but now only meets four times a year. This growth has led to increased distances between the teams that makes direct interaction between employees more difficult. These distances are due to the physical dispersion of the multiple teams but also to the lowered frequency of interaction. In this larger organisation, it is more difficult for testers to get to know each other and to know what others are doing, thus increasing psychological and cognitive distance. The cognitive and psychological distances between the test teams together with their physical location were assessed in our case study, see Section 6.1. The cognitive and psychological distances were calculated based on self-rating data collected through interactive posters, see Section 5.1.

While the distances between test teams is becoming more of a concern, there is an increasing focus on interoperability between products developed by different development teams. This is in line with overall trends of an increase in system interaction, such as Internet of Things, where individual devices are expected to be integrated into larger systems. This has historically been addressed by the company with APIs and an emphasis on backwards compatibility for these APIs. However, in line with the company culture described above, issues between teams providing APIs and teams consuming APIs have been solved through direct personal communication. This reliance on personal communication, rather than relying on strict contracts such as design by contract, has been preferred by the company to encourage cooperation and openness to change. Another factor that increases the necessity for communication between test teams is an increased focus on delivery speed. This is in line with trends such as continuous delivery and continuous deployment. This means that any issues between the teams need to be solved faster and more efficiently. At the same time the company has been clear that it wants to keep the company culture.

The case company has identified and acknowledged these communication challenges and taken steps to address these. The research presented in this paper is one of these steps that the company has initiated, namely to investigate how distances between the teams within the QA department affect the communication within the development organisation.

5 Research method

We performed an exploratory case study at Axis Communications. The study was initiated in response to the company’s need to address the challenge of managing inter-team communication within their growing software development organization, see Section 4. Our study applied guidelines for case study research provided by Runeson et al. and consisted of design, data collection, and data analysis, and finally reporting (Runeson et al. 2012). Data collection was performed at the company through interactive posters (Diebold et al. 2017) and focus groups. The interactive posters were used to assess communication between the studied teams as perceived by the team members through self-rating of the perceived cognitive and psychological distance to other teams. This quantitative data was presented and discussed at focus groups to gain in-depth knowledge of inter-team communication. Finally, through data analysis the presented set of factors and strategies related to inter-team communication were identified and then complemented by a literature review. An overview of the study is shown in Fig. 1.

Fig. 1

Overview of our research method. Interactive poster voting was used to assess distances between teams that were then presented and discussed at focus group sessions. The knowledge obtained in our case study was compiled into a set of factors and strategies for inter-communication

Our research with the case company, around inter-team communication and the concept of distance, has been ongoing for almost two years, of which the design and data collection for this case study was performed during four months. During this time, the authors (one researcher and two practitioners from the case company) met regularly to design the study, the interactive posters used to collect data on the distances between teams, and the focus groups used to elicit in-depth knowledge of communication between the teams. The data gathered using the interactive posters was collected by the 2nd and the 3rd authors, and then jointly analysed and interpreted. The focus groups were jointly designed by all authors and held primarily by the 1st and the 3rd author. The knowledge synthesis including the analysis of the focus group data was primarily performed by the 1st author who also performed the literature review, and discussed this with the 2nd author. Finally, the full set of results was reviewed by and discussed with all authors.

5.1 Interactive poster voting

We used interactive posters to assess inter-team communication by measuring cognitive and psychological distance between teams. This method of data collection was chosen since it is shown to stimulate participant engagement (Diebold et al. 2017) and may do the same for interest and awareness of our research and thereby increase the impact of our research at the company. We iteratively designed a poster concept with a two-axis graph, one for cognitive distance and one for psychological distance. We used one separate interactive poster per team (to enable calculating values per team), where each team member marked their view of cognitive and psychological distances to the other teams on a three-point Likert scale (1-Low, 2-Medium, 3-High) using stickers with the names of the (other) teams. An example of an interactive poster used in our study is found in Fig. 2.

Fig. 2

The interactive poster for one of the teams. The team members were asked to assess distances to other teams by answering the questions (for Cognitive distance, marked on x-axis): “If I need to perform the work of this team for one week it would be”, and (for psychological distance, marked on y-axis): “If I need to talk to someone from this team it would be”. For both axes, the scale used was Easy (lätt), Medium (mitt i mellan) and Hard (svårt). Each team member voted by placing stickers with names of the other teams in the field of the graph corresponding to their views of distance towards these teams

We collected data from all ten test teams within Axis Communication’s R&D unit, see Table 1. The aim of the study and the poster set-up were presented to each team, and then one interactive poster was put up for each team, in a location close to the team’s office area. The posters were available for voting during 7–10 working days with some variations between teams, and then collected. The responses were counted and transferred into a spreadsheet. This transcription was performed by the 2nd author and validated by the 3rd author. Discrepancies in the numbers were re-checked and the correct values entered into the spreadsheet.

The data obtained through the interactive posters (see previous section) was used to calculate the psychological and cognitive distances between the studied teams, and geographical distance was assessed by noting the office location of each team. For the psychological and cognitive distances, we calculated both the total perceived distance per team and the distances between each team. The total distances per team were obtained by combining the poster votes (values 1, 2, or 3, see above) from all the teams toward each other team, and calculating the mean values and the 25 and 75% percentiles. Psychological and cognitive distances from team X to team Y were calculated by combining all the votes from team X’s poster marked with a sticker named team Y, and calculating the mean and standard variation for these. The full set of distance measurements are found in Fig. 8 in Appendix A: Measured Distances between Teams.

5.2 Focus groups

We organised focus groups to present the results of the interactive posters and to further explore how distances and other factors relate to inter-team communication, and which strategies can be used to facilitate this communication. The reason for using focus groups was two-fold, namely, to provide value to the case organisation and to gather further empirical data. One focus group was held with the mangers of the ten studied test teams, and four team-specific focus groups were organised. The first focus group was also used to obtain agreement from the manager regarding additional focus groups with selected teams. Each of the focus groups was audio recorded, transcribed, and analysed using thematic coding. The protocol for each type of focus group is available in Appendix B: Protocols for Focus Group Meetings.

At the focus group with the managers, we presented the total cognitive and psychological distance per team, as obtained through the interactive posters. These distances were visualized with boxplots, see Fig. 3. At the meeting, the managers first presented themselves and their teams, and were then asked to guess the total distance for their own team, i.e. the perceived cognitive and psychological distance to their team. The results from the interactive posters were then presented and the participants were invited to reflect on the measurements; were the results expected or not, why this result? Finally, the session was concluded by discussing further focus groups with the individual teams. An initial set of factors was identified based on thematic analysis of the focus group with the managers.

Fig. 3

Example of a diagram discussed at a focus group. The total cognitive distance for each team is shown using boxplots based on the mean, 25 and 75% percentile values

As agreed with the managers, separate focus groups were held with representatives for four of the test teams to present and discuss the distance measurements. The teams were selected in dialogue with the company to represent a range of team characteristics, such as teams with either very short or longer distances, teams with a high level of seniority, teams working with camera vs. client-side software. For each team, the team manager selected four team members to participate in the meetings. The instructions were to select both senior and junior members. The participants of these focus groups are listed in Table 2. The sessions with the teams contained an initial discussion on their experience of using the interactive posters and a reflection on the total distance for their team (similar to the focus group for managers). The participants were asked to reflect on their communication with other teams. For example, which teams are easy or more difficult to talk to and why? The cognitive and psychological distances between teams obtained from the interactive posters, were visualized using bar charts of mean value and standard variation for each team, see Fig. 4.

Table 2 Focus group participants from the selected test teams including their main responsibilities and number of years in the team, at the company and within the profession

Fig. 4

Example of a diagram discussed at the focus group with the team Client 1. The mean cognitive distance for this team (Client 1) towards each of the other teams is shown with the standard deviation

During the focus groups with the teams, the factors identified from the managers’ focus group were further explored. As the participants mentioned factors influencing their communication, these were noted on individual sheets of paper and placed on the table. The factors not mentioned spontaneously were then presented and the participants were asked if they thought these were relevant to communication or not. If relevant, these factors were also placed on a piece of paper on the table. The participants were then each asked to indicate how large an impact the factors have, using the $100 method where each participant was given the equivalent of an imaginary $100 to distribute over the factors. Their votes were summarized and the factors with the highest impact were discussed.

5.3 Knowledge synthesis

The full set of data gathered throughout our case study, i.e. interactive poster data, focus group transcriptions and related work was analysed gradually throughout the study, used as input to the next research step and, finally synthesised into the set of factors and strategies reported in this article. We used the quantitative data from the interactive posters to calculate distance measures, as described in Section 5.1. Visualisations of these distance measurements were used to stimulate discussions and reflections at the focus group meetings, as described in the previous section.

The transcriptions from the focus groups were analysed in nVivo using thematic coding to identify the factors and strategies reported in the Results section. For example, this part of the transcript from the focus group with the Client 2 team “we don’t know very much about what that team does, we assume it is difficult. It is an assumption” was coded with the factor “F1 Awareness of Others”. Initially, open coding was used, and a first version of the factors (as codes) was derived by the first author through coding the transcript from the focus group with the managers. This set of factors (and, thus the codes) was then discussed by all the authors and used in subsequent focus groups with the teams and in coding of these transcripts, thus validating these codes through triangulation. The codes were, gradually extended, refined, and clustered as additional data was analysed, and our knowledge deepened. We also coded aspects such as distances, pros and cons of the interactive poster method, product components, and aspects of the knowledge flow. The full set of codes was used to identify relationships between factors and to distances.

The outcome of the thematic coding, primarily the set of codes for factors, was used to guide a review of literature to identify related work on inter-team communication by using the factors as search terms. A set of relevant articles were found. The relevant parts of these articles were coded using the codes for factors, strategies, and distances.

Finally, the results were reported per factor and strategy, thus synthesizing the findings from all data sources. The coding helped us to describe our results (in Section 6) through grounding these in the data by providing examples and quotes from relevant parts of the transcripts and related work as captured by the coding, e.g. of factors. Whenever communication between two specific teams was mentioned in the transcripts, the quantitative data (distance measures) for these teams was consulted and considered in the analysis. The performed analysis was, thus primarily qualitative but informed by quantitative data. Furthermore, the quantitative data was used to trigger reflections and discussion in the focus groups, thereby allowing us to explore factors and strategies, and potential relationships between these and the distance measures.

6 Results and discussion

We have identified factors and strategies related to inter-team communication based on our case study of ten teams within a large co-located software engineering organisation. The factors provide insights into various aspects that can affect inter-team communication, while the strategies provide examples of how communication can be facilitated in large co-located development organisations. The source of presented observations and quotes are noted by referencing the focus group (see Section 5.2) either by team name, e.g. [Client 1] or with [Managers] for the manager’s (separate) focus group. A description of the teams included in the study can be found in Table 1. For each subsection below, we first present the results based on our data and then (in separate paragraphs) discuss these results in light of previous research and of our own insights. An overview of our results is also provided below for each of our research questions.

6.1 Factors influencing inter-team communication (RQ1)

We have identified a set of factors that affect inter-team communication and present these based on analysis of the focus group material and of the obtained distance measures, see Figs. 5, 6, 7. For each factor, we also discuss relevant findings from previous research. We provide an overview of the factors, their relationships to related work and to other factors in Table 3. The teams participating in the focus groups rated the impact of each factor. They believed that interaction frequency and extent (F2) and team characteristics (F6–F10) are the factors with the largest impact on inter-team communication, while attitude to others (F3–F5) and awareness of others (F1) have somewhat less impact, see Table 4.

Fig. 5

Mean cognitive distance between teams based on data from the interactive posters. Each row shows a teams’ (mean) distance to each of the other teams. Scale: 1-Short (white), 2-Medium (grey), Long distance (black)

Fig. 6

Mean psychological distance between teams based on data from the interactive posters. Each row shows a teams’ (mean) distance to each of the other teams. Scale: 1-Short (white), 2-Medium (grey), Long distance (black)

Fig. 7

Physical distance between teams. Each row shows a teams’ distance to each of the other teams. Scale: Short (white)–same building and floor, Medium (grey)–same building, but different floors, Long distance (black)–different buildings

Table 3 An overview of factors that affect inter-team communication, their relationship to distances and other factors

Table 4 Rating of factors’ impact on communication and collaboration, as accessed at the focus groups with four teams through $100 voting, and average over all teams. The numbers are normalized to 100 votes per team. Factors not deemed relevant by the participants are marked NA

6.1.1 Awareness of others (F1)

During the focus groups, the participants gave many examples of how awareness of other teams affects the cognitive distance and their communication with these teams, both positively and negatively. Several participants described that lack of awareness can lead to an assumption of a cognitive distance, when “we don’t know very much about what that team does, we assume it is difficult” [Client 2], which in this case was measured as Medium–High (on average 2.5 between teams Client 2 and Camera 2). Similarly another test team explained their high values for cognitive distance (on average 2.5–2.6 towards the teams Non-video devices and Client 1) as being due to “we don’t know how they work” [Camera 1]. This cognitive distance then makes it “harder to know which level to start talking to them; basic or [more advanced]?” [Client 2] In contrast, knowledge of another team, who they are and what they do, makes it “easier to go and talk to them.” [Client 2] Awareness of others thus appears to affect the ease of communicating with them, which is the definition of psychological distance. Based on this data, we observed a potential correlation between psychological and cognitive distance.

Participants at all the focus groups described that physical proximity supports awareness of others and that easy insight into when someone is available facilitates direct interactions. Geographical distance makes this harder. In particular, those in coordinating roles found that physical distance has a negative effect on communication, as one test lead described, “there is always a threshold to cross when initiating contact.” [Client 2] To some extent, tools such as Skype and e-mail are used to create awareness of geographically distance teams by checking “are they available, are they there?” [Client 2] While co-location facilitates awareness of others, this awareness may dissipate quickly when relocating to another part of the office due to the many changes in team responsibilities, office location, etc. [Camera 3].

Working with similar technology or architectural layers, thus having similar work tasks (F10), or being clearly connected to a physical product (such as Camera 1), appears to facilitate awareness of what other teams do. This awareness provides “some understanding of what the others do” [Client 1], which aids communication. One team that sticks out is the Hardware team that in general has long distances towards all the other (software-related) teams. One focus group participant explained this by saying that “we hardly have any communication with Hardware. It’s difficult since I don’t really know what they do and the topic is more unknown to me than software” [Camera 3], i.e. there is a large difference in work tasks (F10). Another similar gap can be seen between the teams that work with the company’s core technology, i.e. the cameras and platform layers, and the teams that work with higher-level software for applications and services, such as the Non-video devices team. The software for these two product areas do not integrate with each other and was described as not having a “natural basis to communicate between” [Managers].

Participants described that there is often less awareness of teams that work with a variety of task (F10), e.g. for Infrastructure, since others do not have insight into their wide range of responsibilities. Also, that larger teams (F7) have a tendency to have less awareness of people outside of the team; “you are fully occupied keeping track of your own team when you are 30 people.” [Client 1] Similarly, when the testers work closely with a larger development team they expressed that they “do not see that much of the others within QA.” [Client 1] This is connected to ways of working and sense of organisational belonging (F9) as development or testing.

Our findings on the role of awareness of other teams validate results by Bjørnson et al. that shared mental models support inter-team communication and effective use of resources when collaborating in projects (Bjørnson et al. 2018). Their empirical data identify three strategies that support the development of these common mental models namely a shared understanding of the way of working, tasks to be done, and shared awareness of who knows what. In the case study reported by Bjørnson et al., this awareness was further facilitated by all teams being located on the same floor. This meant that the teams were aware of when other teams had meetings and could see the progress boards of other teams. In addition, a shared understanding of the project’s quality requirements was gained through joint responsibilities for these by the development and the test projects. Thus, when teams share a common mental model there is a high level of mutual understanding of what and how other teams work, i.e. a good awareness of others (F1) that facilitates inter-team communication.

Furthermore, our observations that inter-team communication is supported by short cognitive distances, correlate well with Santos et al.’s findings that knowledge sharing between teams strengthens the relationships between people and thereby improves their interaction and collaboration (Santos et al. 2015). Thus, by sharing information, the cognitive distance between teams is decreased, and their attitude and awareness of others (F1) is improved. This includes the culture (F3) within the organisation and a commitment at organisational level to team-level activities that create a maturity regarding issues “essential to the continuity of the organisation”, and thus beyond the immediate project at hand.

6.1.2 Interaction frequency and extent (F2)

The focus group participants described how frequent interaction with other teams is a prerequisite for good inter-team communication [Client 2] since this increases their awareness of each other’s work (F1) and decreases cognitive distances. One participant said: “If you talk to someone often you get to know them and what they can do.” [Camera 3] There are several examples of this in our data. For example, the teams Camera 1 and Camera 3 work together a lot, with work rotation and sharing of test cases [Camera 1]. Between these two teams there is both a Low cognitive distance (on average 1.0) and a Low psychological distance (on average 1.0), see Fig. 5 and 6. Similarly, Camera 1 and Camera 2 are the teams with the most interactions with the Hardware team, and the teams with the shortest cognitive (on average 1.8–1.9) and psychological (on average 1.4–1.7) distance towards the Hardware team. Our data also reveals the opposite, namely that teams with a low interaction frequency express a low awareness of each other. For example, Client 2 does not work directly with the Hardware team and have little insight in what they do. For these two teams there is a Medium to High cognitive distance (on average 2.3–2.5) and a Medium psychological distance (on average 1.5–2.0). The numbers are similar for the teams Camera 3 and Client 1 for which the interaction frequency is low, i.e. a Medium cognitive distance (2.1–2.5 on average) and a Medium psychological distance (2.0–2.3 on average). Thus, the interaction frequency between teams appears to correlates with their ease of talking to each other, i.e. psychological distance.

The amount of interaction for individuals varies within teams depending on the roles and responsibilities of individual team members. Some people act as formal or informal contact people and have more team external interaction than other team members have. For example, within the Camera 1 team, the test lead meets Hardware testers, while other roles do not. [Camera 1]. Similarly, work tasks (F10) affect the amount of team-external interaction. For example, when performing broad and extensive testing there is a need to interact with other teams as problems surface [Camera 3]. For example, one team member of Camera 3 said “I have quite a lot of contact with the Hardware team because of the SDK, others never need to talk to them.” These differences within teams may explain variations in the distance measurements.

Physical proximity was described by focus group participants as having a large positive impact on interaction frequency since you “may run into each other more often” [Camera 1], and make it easier to communicate. Similarly, events such as cross-testing and QA days create physical meeting points that facilitate inter-team communication.

Seniority (F8) gradually creates an increased interaction frequency since “over time you have something new to do with people at other departments, and you get to know more people” [Client 2].

Technical dependencies create needs for interaction between teams due to similar or dependent work tasks (F10). For example, there is more communication between the teams Camera 4 and Client 2 since Client 2’s component is tightly integrated in the platform, which all Camera teams work with [Camera 3]. For the team Non-video devices, there is no dependency to the platform and thus no need for direct interaction with the teams working with the platform. Bug trails also create a need for interaction. For example, the Client 2 team find issues that the Camera 3 team fixes and verifies [Camera 3] creating a more frequent interaction between these two teams. Finally, business priorities can also affect the interaction frequency. For example, the Camera 3 team has more interaction with the Client 2 team than with the Client 3 team since the Client 2 team targets a more prioritised business segment.

Begel et al. found that even within a very large development organisation, such as Microsoft, interaction frequency and extent together with personal contacts is the most effective factor for successful inter-team collaboration (Begel et al. 2009). Harrison et al. report similar findings when studying the effect of diversity on group social integration, and concluded that meaningful interactions between people weakened the effect of the surface-level diversity, such as age, sex, ethnicity etc. (Harrison et al. 1998). These findings are confirmed by our study, where the participants rated this factor as the one with most impact on inter-team communication, see Table 4. However, how such interactions are facilitated in a small versus a large organisation varies greatly. This is exemplified by the growth of our case company and the studied test organisation. While all engineers within a small organisation can be located in the same office space, thus facilitating awareness and direct communication, new challenges arise as the organisation grows. Our case company faces challenges in retaining the informal and organic communication as their main coordination mechanism, and therefor seek a deeper understanding of the factors and strategies that influence inter-team communication for large-scale development organisations.

6.1.3 Attitude to others: culture (F3), attitudes and opinions (F4), personality (F5)

We found that the communication between teams is greatly affected by their attitude towards other teams and the work they do, and that this is in turn can be related to a team’s knowledge and awareness of other teams (F1). This was confirmed at the focus groups with two of the teams with the overall shortest psychological distance of all teams, namely Camera 1 and Camera 3. The Camera 1 team stated: “It’s all about attitude” [Camera 1], and the Camera 3 team described that they consciously strive be open and helpful. This sentiment was shared with the Client 2 team, which stated that attitude to others is a key factor for good communication with other teams. However, the Client 2 team described challenges in communicating with the teams Hardware and Camera 2. These challenges may be correlated to their attitude toward these teams and to the fact that they are located in a different building, i.e. there is a long physical distance. At the focus group, the Client 2 team described hardware testing as “just dropping some heavy things”, thus indicating a lack of insight (or awareness) into their work. They expressed a similar attitude towards the Camera 2 team for which they also “don’t know very much about what they [Client 2] do” and said that “they let through so many bugs, so how hard can it be to do their job?” [Client 2]. However, this partly contradicts their previous responses to how hard it would be to perform the work of these teams (i.e. cognitive distance) for which their response was Medium, bordering on Long cognitive distance towards both of these teams, namely 2.3 for the Hardware team and 2.5 for the Camera 2 team. In addition, the psychological distance for the Client 2 team towards these two teams (Hardware and Camera 2) are among this team’s longest distances, namely 2.1 to the Hardware team, and 1.9 to the Camera 2 team, thus indicating challenges in communicating with these two teams.

The importance of the attitude towards others for good inter-team communication validates the findings by Rahy and Bass that when teams have a negative attitude towards other teams this often leads to communication gaps and down-prioritizing team-external tasks (Rahy and Bass 2019). Similarly, lack of inter-team trust was identified by Bjørnson et al. as a hindrance to inter-team communication, and that transparent and frequent communication, common workspaces and meeting points build such inter-team trust, even between teams of different work cultures (Bjørnson et al. 2018).

At the focus groups, the participants described how their attitude towards other teams is based on a combination of factors such as company culture (F3), similar attitudes & opinions (F4), and personality (F5). The company actively works with cultural values (F3) such as acting as one, being open and helpful, and communicate these at all levels within the organisation, e.g. at kick-offs and introduction for new employees, and during performance management [Client 2]. The case company’s consistent work with these cultural values has a clear impact on the ease of communicating and collaborating between team, and the focus group participants described that in general it is not hard to talk any of the other teams. As one participant said: “This is why the [psychological distance] values are all well below Hard. It is a result of the core values.” [Client 2] One new employee from the Client 1 team described that he found it easy to communicate with other team since “my colleagues have encouraged me to go and talk to people, and not just send e-mails. Even if I don’t know a team very well, we would go and talk to them, they would come back to my desk and we would test together.” However, the size (and growth) of the organisation makes it harder to act in line with company culture: “it has become harder to act on them [core values] now that we are so many in the organisation. It was easier to get things done through direct contact. Now there is some more bureaucracy. Processes are needed otherwise there would be chaos.” [Camera 1].

Santos et al. found that while agile methods boost a culture of collaboration within teams, this may also create boundaries between teams that hinders good inter-team communication. Thus, there appears to be a conflict between intra-team collaboration and inter-team communication, especially for teams that have no overlap in responsibilities or integration needs. These boundaries may create an attitude of us-and-them that increases with differing team characteristics (F6-F10, see next Section). This was also seen in our study, in particular for larger teams with strong intra-team communication, and in particular for the teams working on separate architectural layers, e.g. between client and camera teams, or between hardware and other teams. These teams had different work tasks (F10) and low interaction frequency & extent (F2), and relatively high cognitive and psychological distances.

The teams [Client 2, Camera 1] expressed that they find it easier to communicate with teams that have attitudes and opinions (F4) similar to their own and that work towards the same goals rather than competing. “It’s one thing to talk to someone, another to agree. That can be harder.”[Client 2] One participant [Client 2] believed that “a common attitude has a greater impact than a similar way of working”, which tends to apply mainly within a team. However, our participants believed that the agile development methodology that is applied within some teams has a positive effect on inter-team communication by encouraging an attitude of collaboration and joint responsibility. Concerning the fact that a mix of process models are use within our case organisation, Bjørnson et al. found that working according to the same process model in all teams, e.g. Scrum or SAFe (Scaled Agile Framework), can facilitate inter-team collaboration (Bjørnson et al. 2018). We see some indications of this correlation in our results, although in our case the way of working is also related to the architectural layer, and thus the positive impact on communication may be caused by working on similar technology.

Personality (F5) affects how easy or hard it is to talk to others and is related to the concept of psychological distance. “When you need to talk to someone new it can vary how easy or difficult you find that.” [Client 2] Some people are generally perceived as easier to talk to than others, and these people often become informal contact points. In contrast, other people are viewed as harder to get along with and, thus, “how you ‘click’ with a person can vary a lot.” The team with the longest psychological distance (i.e. Client 1) expressed that they tend to be less active at social events organised by the company, which may indicate a less outward going personality. However, one team expressed that this behaviour may also be related to team size (F7), and that “the less people you are in a team the more outward going you become” [Client 1].

In our data, we see some indications [Client 1, Camera 1] that personality is correlated to certain teams and work tasks (F10). One participant said: “We are engineers; it’s dangerous to talk to someone you don’t know [laughter].” [Camera 1] Another person said [about Client 1]: “Half of us are sort of social. But, some sit and program automatic tests… they prefer to not go and talk to others. They don’t like social activities. It’s their personality.” In contrast, people working in coordinating roles, such as technical area managers and the platform service team were often mentioned as being “pleasant” and “service minded” [Camera 3].

Our results indicate that personality is a relevant factor for managers to consider when composing teams and assigning work roles and responsibilities. Manager should ensure diversity regarding personality since this may enhance a team’s capacity for inter-team communication. Diversity in software engineering organisations, e.g. regarding gender and tenure, has been shown to support increased productivity (Vasilescu et al. 2015) and may also facilitate communication within a software engineering organisation (Catolino et al. 2020).

6.1.4 Team characteristics (F6–F10)

Through the focus groups, we have identified several team-related aspects that may affect inter-team communication. These characteristics are the age and the size of a team, the amount of senior team members, sense of team belonging, and the work tasks for which the team is responsible.

The age of a team (F6) appears to affect the awareness of others (F1) towards this team regarding who they are and what they do. For example, there appears to be more awareness of what older teams such as Camera 1, Camera 2 and Camera 3 do than for newer teams such as Non-video devices and Infrastructure [Client 1]. “My team is a new organisation and the knowledge of what we do is weak.” [Non-video devices manager] In the case of the Non-video devices team, this weak awareness is also connected to working on a new business segment that has a lack of technical dependencies to established teams and thus connected work tasks (F10), coupled with being geographically distant. However, some of the team members with seniority (F8) have previous experience from other parts of the platform, in particular the Camera 4 team. These team members have become “natural contact points” [Non-video devices manager].

Older teams, e.g. Camera 1, tend to have a wider social network due to previously being co-located and co-organised with other testers that now (due to re-organisation) work in other teams. Also, teams gradually gain insight over time by interacting with people from different parts of the organisation.

The size of a team (F7) was mentioned by participants from two different teams as a factor that may affected the teams attitude to others (F3-F5), and in particular to inter-team versus intra-team communication. “The less people you are, the more outward going you become. But in a large team you isolate yourselves… and are busy keeping track of your own team.” [Client 1] The manager of one large team said: “we work very much in our sub-teams and it is not so easy to come and talk to someone within them.” [Client 3] A smaller team size appears to facilitate communication with other teams. An example of this is the Hardware team that work with an area “that none of the others work with, but it’s still easier to talk to us since we are quite a small team and some people have been there a long time.” [Hardware manager] Another aspect of this is the ease of co-locating people from small teams, e.g. with developers, and thus affects their sense of organisational belonging (F9). “It is quite easy to sit together and be close to both developers and testers.” [Client 2] On the other hand, for very small teams this may result in being the only tester co-located with a development team, which was described as creating isolation towards other testers. [Client 2] A larger team may cover a range of work tasks (F10) and competences, and personalities (F5) which may increase the probability of a match to individuals in other teams [Managers], but may also lead to variations regarding cognitive and psychological distance depending on which part of the team you consider [Camera 1]. On the other hand, “there is a higher probability of knowing someone within a large team”, e.g. due to more exposure at, e.g. QA days [Client 1]. However, one person believed that communication is affected more by the individual personality (F5) of team members rather than the size of the team [Client 1].

Our observations regarding the correlation between team size and ease of inter-team communication validate the findings of Bjørnson et al. In their study, they identified a negative relationship between team size and interpersonal contacts and pose that this may contribute to the challenges of scaling agile methods (that rely on interpersonal communication) to large organisation (Bjørnson et al. 2018). Similarly, Catolino et al. also identified team size as a factor that can mitigate communication issues (Catolino et al. 2020), though they provide no explanation on why or how, e.g. if small or large teams are more beneficial from an inter-team communication perspective.

Seniority (F8) of team members appears to be a factor that facilitates inter-team communication. One participant said that it was easy to talk to any other team “since I have been here for a long time… met all the other teams.” [Client 1] Senior team members tend to have a large social network due to previous co-location, co-organisation, job rotation, attending joint events etc. For example, the team Camera 3 and Hardware consist of many senior engineers and are known by many people in the organization, and for these team “many know of someone they can talk to” [Managers]. Similar, the Camera 1 team “has quite a lot of people who have worked for a long time so other teams have contacts into” this team [Managers]. However, as one focus group participant pointed out, seniority in itself does not make a person easier to talk to, but that personality (F5) is an important factor. This person reasoned, “there are people who have worked for a long time, but are hard to talk to, and the other way around” [Camera 3]. Catolino et al. present some evidence that diversity, in particular gender and tenure, may mitigate undesirable communication patterns in a software development organisation. However, they also found that gender diversity is “perceived as being less important than experience or team size… in mitigating [communication issues]” (Catolino et al. 2020). The question of diversity and its role in inter-team communication is an important topic and one for which more research is needed.

The organisational belonging (F9) of a team appears to have an impact on inter-team communication. Participants described that working for the same manager, and thus having a short organisational distance, influences people’s “attitudes and ways of working… that come from the department” [Managers] and thus their communication with others. When working for a joint manager you may attend the same meetings and get similar information. However, several participants thought that the impact was weaker than when actually working together, e.g. on similar work tasks (F10) and being co-located. There is a difference among the studied test teams regarding how closely they work with development. Some teams have more interaction with developers than with other testers since the testers are co-located with a development team [Client 1, Client 2, Camera 3]. This facilitates communication with developers. However, several testers that work in this way expressed that they may then become isolated from colleagues within QA. The participants described this as a risk especially for new employees that then “do not even know who his [own] team is.” [Client 2] The data also suggests that organisational distance between development teams might be affecting the distances between the studied test teams. Even though the test teams all belong to the same department, some development teams have deliberately been organised in a different, more distant, part of the organisation to provide them with freedom to innovate. In particular, this may affect the test teams Non-video device and Client 1 that work with these organisationally distant development teams. The organisational distance of these development teams may partly explain the longer psychological distances towards these two test teams, i.e. between the Non-video device team and Camera 1–3, and between the Client 1 team and Client 2–3. Our findings on organisational belonging validate results presented by Rahy and Bass that team belonging influences the urgency and priority placed on work tasks depending on if they originate from the own or another team. In their study, they found that tasks from other teams were often down prioritized, resulting in delays and need for rework, in particular for tasks related to inter-team dependencies (Rahy and Bass 2019).

Work tasks (F10) vary between teams regarding the type of roles, work tasks (e.g. the type of testing) and tools used. For example, in some teams such as the Camera 1 team there is a lot of coordination work, project reporting etc., while other teams primarily perform tests. When the work tasks are similar and require similar competence, the cognitive distance is shorter. In contrast, when there are differences in work tasks “we are not used to that. There is a threshold to cross.” [Camera 3] The differences in work tasks also lead to differences in ways of working that can cause challenges in communicating. For example, the work of the client teams (Client 1, Client 2, Client 3,) varies quite widely. [Managers]. Teams that have “common systems work with that [other] team … then it is not difficult” to communicate. [Client 2] When there are technical dependencies, or when a team’s product is used by another, e.g. for testing or for daily use, the cognitive distance between these teams is shorter due to common knowledge. For example, between the team Camera 4 and Client 2 “there is more communication since they use the [component] more.” [Camera 3] Using another team’s product induces a need to interact with them, thus increase interaction frequency & extent (F2). Some teams, e.g. Client 2, even actively promote the use of their “application also in other teams so that it [communication] should be easier.” [Client 2] This may explain why most teams report a shorter cognitive distance towards the Client 2 team, than Client 2 reports towards them. However, some teams perform their work very differently, even if there are technical dependencies. “We [Camera 3] test the camera in our way and let Client 1, Client 2 and Client 3 do it their way. We work in different ways. Very divided! … Even if they use our stuff.” The technical area, architectural layer or product that the teams work with vary, and thus the competence required of each team varies. Communication between teams with differing competences tends to be more challenging. For example, the Client 1 team works with a large and complex product that required specific competence, which then affect the communication to other teams. Differences in the technical platform used may also increase the cognitive distance between teams, e.g. teams that work on Windows or on Linux, and require additional effort to communicate effectively.

6.2 Strategies for facilitating inter-team communication

We have identified five strategies for inter-team communication based on the data from the focus groups: awareness of cognitive distance (S1), physical meeting points & arenas (S2), job and office rotation (S3), key people (S4) and tool support for interaction (S5). We provide an overview of these strategies, related work and found relationships to distances and to inter-team communication factors in Table 5.

Table 5 An overview of strategies for facilitating inter-team communication observed at the case company

6.2.1 Awareness of cognitive distance (S1)

An awareness of the existence of a cognitive distance may facilitate adapting inter-team communication in a way that reduces the risk of misunderstanding due to a mismatch in knowledge. For example, if you know that a team is not familiar with a certain technology you can be more explicit when discussing issues related to this. One participant expressed that “if I don’t know what background a person has, how do I start to talk to them. It’s harder to know what level to start at, basic and indicate that they are fools, or…?” This awareness relies on being familiar with other teams and what knowledge they have. Awareness is an aspect that the company actively works with. One participant described that “information concerning what people do [is important], but … it is more important to get to know people” [Camera 1]. Knowledge of others can be obtained by frequently interacting (F2) with them. One member of the Camera 3 team expressed this as “If you talk to someone often you get to know them and know what they can do”. Similarly, organisational belonging (F9) supports awareness of others (F1), at least within your own organisational unit. As one participant said: “If you are organisationally close you might be aware of each other” [Client 2]. For teams that are reorganised, this awareness remains even after they are split into multiple team, at least for a period of time. This is seen for the teams Client 2 and Client 3 that used to be one team until up until a year prior to our study, and for whom both cognitive and psychological distance remains low (on average 1.4). The team members say that they still “have good insight into what they do [in the other team]” [Client 2]. In this case, the awareness is retained also by the physical proximity of the two teams. The focus group participants believe that co-location has a stronger impact on inter-team communication than co-organisation. This includes being easy to find, e.g. by not changing the location of the teams, which makes it harder for others to locate them.

We have seen in a previous study that awareness of the existence of a cognitive distance enables people to adapt the communication to the level of knowledge held by the other person and avoid misunderstandings due to tacit knowledge (Bjarnason and Sharp 2017). However, this strategy is not actively or consciously applied at the company at the time of the study, rather the concept of cognitive distance was introduced as part of this case study. Thus, further research is needed to investigate how a strategy of encouraging awareness of distances can be implemented and how it may affect inter-team communication.

6.2.2 Physical meeting points and arenas (S2)

Physical meetings are an important part of the case company’s work culture (F3) and planned, and spontaneous meetings are the preferred way to communicate. The company encourages employees to talk to each other face to face rather than just rely on communication via e-mails, issue management systems etc. Geographical distance affects all kinds of interactions, both short and spontaneous ones, and pre-planned meetings, and physical proximity is seen as a very important facilitator. This was mentioned at all the focus group meetings and by very many of the participants, e.g. “It becomes harder to work together if you are not located in the same building, rather than 10 steps away. Then you have to allocate an hour just to go and talk to someone” [Camera 1]. Similarly, “it was easier when we all sat together, and we could talk to them during a coffee break” [Camera 3]. Regarding pre-booked meetings, one participant said: “I am not particularly happy about having many meetings in the other building” [Camera 1].

When co-located, e.g. within the same office floor, this implicitly creates a physical arena that facilitates frequent and informal communication between those located in that arena (Santos et al. 2015; Bjørnson et al. 2018). Dingsøyr et al. found that in large agile organizations, there appears to be a shift towards such informal meeting points over time (Dingsøyr, Moe and Seim 2018). This indicates the importance of the physical arenas within the workplace and that management should strive to facilitate the desired communication patterns through mirroring these in the organization of office space.

Within our case company, there are a number of meeting arenas, such as cross-organisational events and activities that are organised with the purpose of bringing people together from different parts of the organisation. Examples of such events include test department events (QA days), innovation days and other social events. The main intention of these events is to create social interaction between teams and, thus increase the interaction frequency (F2). Some participants expressed that they consciously “try to get to know people from the other teams” [Camera 3] at these events. However, the opposite was also described, and several participants pointed out that “people tend to stick with their group… and mostly talk to those we already know about.” [Camera 1] Some of the social events, such as Joint breakfast and Friday Coffee are organised per building rather than for the whole site. One participant described that he consciously attempted to join these events for other building on days when he was there for meetings anyway [Camera 3]. Other researchers report on similar arenas of various types that support knowledge sharing, e.g. demos and experience forums (Dingsøyr, Moe and Seim 2018), and social interaction, e.g. coding dojos and marathons (Santos et al. 2015), lunches and coffee breaks (Dingsøyr, Moe and Seim 2018).

Some of our case study participants mentioned joint activities with a clear work focus as a good way of facilitating inter-team interaction and getting to know each other. For example, people from different parts of the organisation work together in improvement projects on topics such as total system testing and cross-functional test sessions [Camera 1]. Cross-functional testing is another activity that creates a physical meeting point for testers from different teams where they meet to test a certain software or product. These events were described as contributing to connecting socially, but having less value if “the product is to be the focal point” [Client 2]. Currently, these testing events are held irregularly, based on need.

In some cases, several teams have joint kick-offs (e.g. Client 1 and Non-video devices) or weekly meeting (e.g. Camera 3 and Camera 4). Even though these meetings become crowded due to the large number of people attending, they are seen as beneficial and “good to have them together when we work on the same things” [Camera 3]. The meetings provide participants with a “wider circle of contacts and make it easier to talk to people.” [Client 1] The participants also described these meetings as providing new employees with awareness of other teams (F1). Previous research reports on several such work-related meeting arenas, including Scrum of scrums and metascrums (Paasivaara et al. 2012; Dingsøyr, Moe and Seim 2018), reviews and demonstrations (Bjørnson et al. 2018). Through frequent such meetings across teams, ample and efficient inter-team communication can be achieved (Bjørnson et al. 2018).

Tartaglia and Ramnath report on the use of a physical meeting place for resolving urgent issues that affect multiple teams, named Open Spaces (Tartaglia and Ramnath 2005), a practice that we have not observed at the case company. The practice was found to facilitate inter-team communication through gathering the relevant expertise in the same room and at the same time. Albeit supporting effective communication, the practice requires some discipline to be efficient and focusing on the topic at hand and documenting the resulting formal decisions. In addition, the discussions need to be kept objective to avoid overheated emotions and the risk of inducing psychological distances between people with opposing views.

Our results concur with the conclusion by Dingsøyr et al. that a combination of scheduled and unscheduled meetings are necessary to facilitate the needed interaction within a large development organisation including the existence of sufficient meeting points to realise that ‘we need to talk’ (Dingsøyr, Moe and Seim 2018). In addition, the exact set of meeting points within an organisation should be adjusted over time as needs surface and change (Dingsøyr, Moe and Seim 2018). Similar to Paasivaara et al., we conclude that inter-team communication remains a serious issue for which large development organisations are still struggling to find solutions (Paasivaara et al. 2012).

6.2.3 Job and office rotation (S3)

Several participants mentioned rotating employees between teams and office location as a means to facilitate awareness and knowledge of other teams (F1) within the growing organization. Through this strategy, employees gain new insights and get to know more people, which thereby facilitates inter-team communication. One participant described that when you have worked in a team it becomes easier to do their job, thus cognitive distance is reduced. An example of this is seen for the Infrastructure team for which most members have previously worked in the Camera 3 team, and where cognitive distance from the Infrastructure team towards the Camera 3 team is very low (1.1), while the Camera 3 team perceives a much longer cognitive distance towards the Infrastructure team (2.2), see measurements in Fig. 5.

Job rotation also increases the number of personal contacts and allows employees to “get to know more people”. This reduces the psychological distance and makes it easier to contact and communicate across the organization. This is seen, once again for the teams Infrastructure and Camera 3, where the psychological distance from the Infrastructure team to the Camera 3 team (where most Infrastructure team members have previously worked) is very low (1.0) and with no variation at all, while this distance is somewhat longer in the opposite direction (1.4). One participant stated that job rotation also reduces psychological distance for people who due to their personality (F5) are less inclined to attend and join in at social events, but “if they change teams, they have no problem become part of that team.” [Client 1].

People who have rotated within the organisation often become informal contact points to other teams, and thus key people (S4). When people do not know who to talk to, they often ask someone “who has worked there since she has contacts… she is acquainted with many people there and knows who to talk to.” [Client 1] For example, within the Non-video devices team, which is a relatively new team, the team members who have previously worked in the Camera 4 team have become “natural contact points” [FG Manager].

The case company encourages job rotation even though “most manager do not want to lose their people” [Client 2] due to issues caused by loss of competence for the team they are leaving [Client 2]. Within the company, there is also an option of a temporary job rotation where you work in another team for 2 weeks. The focus group participants perceived short-term rotation as a good option “since it is a big step to change team” [Client 2].

One participant suggested that rotating your workplace, e.g. on a weekday basis, might facilitate awareness by varying whom you are physically close to. In some teams, the testers are co-located with a development team, which facilitates communication with development but weakens the awareness and communication with other test teams within the department [Camera 3].

Our results validate previous results that rotating people can be used to level and share knowledge between teams and project (Santos et al. 2015). Dingsøyr et al. report on a case where changes in team set-up was consciously used to distribute knowledge and facilitate coordination, and found that at times this may even resolve issues related to personal chemistry (Dingsøyr, Moe and Seim 2018). However, they also found that as teams become established, they may become more resistant to team changes. Our participants mentioned this cost of losing a team member and indicated that rotating people in a less permanent fashion may be preferable, such as temporarily, or within the team [Client 2]. For example, assigning development team members to participate in other types of work within the team (Dingsøyr, Moe and Seim 2018).

6.2.4 Key people (S4)

Within the case company, there are key people that facilitate inter-team communication, both informal contact persons and roles appointed within teams as responsible for certain artefacts, primarily suites of test cases. The focus group participants primarily described informal contact persons. For example, a developer who is not “an appointed contact person but has just become one since she has previously worked with Nn… she knows many people there and knows who to talk to.” [Client 1] Informal contact persons act as natural contact points due to having a large social network within the company, often created through seniority (F8) and job rotation (S3), in combination with competence and an outgoing and helpful personality (F5). These informal contacts play a vital role in facilitating communication across the organisation, as one participant said: “If you know someone in a team, then it becomes easier to talk to the whole team “ [Camera 3].

One drawback of informal contact persons, in contrast to formally appointed roles of responsibility, is the challenge of knowing who they are, and several participants described difficulties in knowing who to talk to that “has a negative effect on the work” [Camera 1]. When there are formally allocated contact persons, the time required to locate a suitable person may be reduced. Another positive effect of formal roles of responsibility lies in “concentrating the knowledge to a few people who can share it, like a proxy “ [Client 1]. This would also decrease the interruption caused to non-contact persons when “all the new employees come with questions … but I can’t answer all the questions” [Camera 3]. However, as one participant described, while a formal role of responsibility within a team makes the inter-team communication more efficient, the overall amount of interaction between individuals decreases [Client 1], which may lead to a decrease in general awareness of other teams (F1). Another person expressed that allocating formal contact people can cause issues when that person is unavailable, e.g. on vacation or ill, and suggested using an IT-based communication channels for team-specific communication, thus alleviating the need to locate a specific person [Client 1].

Related research has identified two types of key people both of which facilitate inter-team communication, namely cross-functional communication brokers and roles within a team responsible for a certain aspect, such as testing. The informal key people identified in our study are primarily of the type communication brokers. Thus, they are people with extensive domain knowledge that hold key positions in the organisation’s communication structure and that communicate across team boundaries beyond the known technical dependencies within a project. Damian et al. recommend identifying team members with exceptional knowledge of an application domain or system component, and ensure that these key people are facilitated in sharing their knowledge within the organisation, without getting overwhelmed with interaction requests (Damian et al. 2013). Dingsøyr et al. identify another type of key people as roles in a team with responsibilities for specific aspects, e.g. technical design, testing etc., that coordinate these areas with other teams, thus acting as key people for certain aspects of their team’s work (Dingsøyr et al. 2018). Thus, there may be several such key people within a team. The roles appointed (by the teams) as responsible for certain suites of test cases are examples of such roles.

Finally, Catolino et al. have identified a set of communication-related risks, or community smells, one of which relates to our suggested strategy of introducing key people as information brokers between teams. This is the risk of Radio silence as imposed by the key contact people interposing themselves in all inter-team communication rather than facilitating and encouraging inter-team interaction (Catolino et al. 2020). While we see no indication of this at the case company, mainly due to the culture of openness being prevalent, it is worth noting and to be aware that imposing too strict and narrow channels for inter-team communication can have a negative effect.

6.2.5 Tool support for interaction (S5)

Within the case company, various tools are used to facilitate interaction with distant teams. As the case company has grown, the distances between the teams have increased through being organised under different managers, placed in different buildings and on different floors, but also by working on a wider range of products and architectural layers. In particular, the increased physical distances between certain teams has a negative effect on communication since “you cannot just go over to that person.” [Client 2] To some extent, these distances are bridged by the use of tools such as e-mail, Skype and the intranet.

Before visiting a distant team or individual, contact is often initiated via Skype or e-mail to find out if the person is present and available, and “then decide if you need to come over.” [Client 2] In these cases, the tools are used to gain awareness of others before going to their office space. This causes some delays in the inter-team communication but avoids the risk of potentially wasted journeys.

When the employees do not know whom to contact, they may use the intranet to identify the appropriate team, its members and where they are located. One participant described that they “usually check which building they are located in and take a chance in going there.” [Client 1] In this scenario, providing “a face too, makes it is easier” [Client 1] to locate people that you do not know.

One participant expressed frustration concerning the difficulty of locating an available contact person and suggested using dedicated digital communication channels for each team. This would then avoid delays and communication gaps when the contact person is not available, e.g. sick or on vacation. “Then I don’t need to identify who to talk to, but just write … and it’s up to them [receiving team] to solve who is to answer my question.” [Client 1] This would also have the added benefit of retaining a log of communication history that is available to the entire team and “then the next person can follow the previous communication.” [Client 1] However, relying solely on such a solution may have a negative effect on the company’s open and helpful culture. Since, this type of communication channel is narrower and more impersonal than direct communication, this may induce longer psychological distances, and increase the overall effort required to communicate effectively between teams.

The mentioned use of ICT tools within the case company are primarily to facilitate physical interaction, rather than to replace the direct communication. To a large extent, this is due to the company culture which encourages these direct interactions but may also be due to the focus of our study. We know that tools are used within the company to communicate directly between people, e.g. through issue management systems etc. In other case studies, ICT tools are found to improve the knowledge flow within development organisations by raising problems and sharing topics of interest although the set-up and effectiveness varies greatly between organisations (Santos et al. 2015). To some extent, we expect this to be the case also at our case company. However, our study does not explicitly cover the use of tooling, and it remains as future work to investigate how face-to-face communication is complemented by tool-supported communication. From other research, we know that there are different preferences regarding tools for inter-team communication, each with their own benefits, and that communication can be improved when people deliberately adopt someone else’s preferred communication mechanism and thereby facilitate communication (Bjørnson et al. 2018).

As pointed out by Dingsøyr et al., ICT tools, e.g. instant messaging channels, chatting tools, wiki pages, issue tracking tools and other common artefacts provide virtual meeting points (Dingsøyr et al. 2018). Such virtual arenas can ease communication and support knowledge share without interrupting people, and thus provide an important complement to the physical arenas. We recommend the case company to consider how the existing physical meeting arenas may be complemented by virtual meeting points.

6.3 Limitations

We will now discuss the limitations and threats of validity for this study based on guidelines for case studies in software engineering (Runeson et al. 2012).

The main threat is one to internal validity, namely the risk of incorrectly identifying factors, strategies and relationships between factors, and that relevant factors may have been missed. This is particularly relevant since we investigate a complex phenomenon in a live context where there are multiple uncontrollable factors that likely influence each other. This risk has been partly mitigated by studying one department within a large case organisation and sampling a selection of teams and team members from which to collect data. Selecting a specific department limits our inquiring to the communication between specific teams. This enables a focused study on a subset of the entire organisation thereby increases our chances of identifying valid results for this unit of analysis, while limiting external validity beyond the test department and beyond the case company.

There is a risk that the obtained psychological and cognitive distance measurements incorrectly reflect the actual distances, partly due to risks related to self-assessment and partly due to the risk of participants incorrectly interpreting the questions in the interactive posters. However, we deem that potentially incorrect measurements has a limited impact on the final results (factors and strategies) since these were derived primarily from the focus group data, and not solely on the distance measurements. Even so, we took steps to reduce the risk of misunderstanding the interactive posters through iterative design of these. The interactive posters were designed primarily by the 2nd and 3rd authors and reviewed several times with the 1^st author, and then tried out on a few practitioners to validate how the poster was understood and interacted with. In addition, the posters were presented and explained to each participating team prior to posting them in the various team areas thereby further mitigating the risk of misunderstandings. Despite this, the focus groups reveal some variation in how the participants had voted, in particularly when they were unfamiliar with other teams. In this case, some had responded that it was hard to perform their work, while others made a best guess about the unknown team, which in some cases was that it was easy to talk to and perform their work.

We partly mitigated the risk of focus group participants misunderstood questions, misinterpreted the presented distance measurements, or simply omitted to mention relevant aspects of inter-team communication by explaining how to interpret the diagrams showing distances and by designed the sessions to be conductive to free and open discussions. In this way, we provided an environment that was as conductive as possible to openly share experiences and opinions of inter-team communication. Each session only contained participants from one team to enable frank expression of potential issues experienced with other teams, and the sessions with the teams were limited to 3–4 team members to encourage all participants to share openly. Furthermore, triangulation was applied by analysing and comparing the focus group data with the obtained distance measurements. However, it remains an open risk that we may have incorrectly identified factors and strategies related to inter-team communication, and that other relevant factors may have been missed. Further research is needed to validate and to explore what other relevant factors may be at play here.

Finally, external validity is limited due to the inherent nature of case studies where the findings are based on data for the specific case and unit of analysis. In this case, we analysed the teams belonging to the company’s test department and thereby have identified factors and strategies relevant for such team and in the context of this case company. However, we believe that the results may be applicable and of interest beyond the studied department and company for organisations with similar characteristics, e.g. regarding size, type of development and company culture. For this analytical generalisation needs to be considered by comparing case characteristics to those of our case company. In particular, the results are likely valid for large, co-located organisations that develop embedded software products using a mix of agile and more traditional development models with a company culture that encourages direct communication, openness and helpfulness towards others, and where teams and departments have a high degree of autonomy and freedom regarding their work practices.

7 Conclusions and future directions

Within large development organisations, in general, and within large-scale agile organisations in particular, inter-team communication becomes an important success factor that enables teams to resolve issues as they surface in an autonomous and responsible way. When inter-team communication is weak or inefficient, this can result in rework, increased lead times and quality issues with the product, as well as, frustration and irritation within the organisation. Our case study contributes with new knowledge in this area including observations of how the presented factors and strategies affect inter-team communication.

We have identified four main categories of factors that affect inter-team communication, namely awareness of others (F1), the frequency and extent of interaction between teams (F2), a team’s attitude towards other teams (F3–F5) and various aspects of a team’s characteristics (F6–F10), see Table 3. A team’s attitude towards other teams is affected by the company culture (F3), having similar attitudes & opinions as other teams (F4) and by personality (F5). In addition, there are team characteristics that can influence a team’s ability to communicate with other teams, in particular a team’s age (F6), size (F7), seniority (F8), organisational belonging (F9), and work tasks (F10). In addition, we have identified five strategies for supporting inter-team communication within an organisation, namely awareness of cognitive distance (S1), physical meeting points (S2), job and office rotation (S3), key people (S4), and tool support for interaction (S5), see Table 5.

7.1 Advice for practitioners

The phenomenon of inter-team communication is complex, and each organisation is unique, however, we believe that our study can provide useful and empirically based insights and knowledge for practice beyond that of our case company. We suggest that management of large software-development organisation use our findings to gain an increased awareness of factors and strategies that influence inter-team communication including different types of distance between teams. In particular, we want to high-light the importance of providing three types of arenas to facilitate different types of meeting points between individuals and teams, namely physical arenas (S2), virtual arenas (S5), and organisational arenas, i.e. units such as teams, departments, interest groups, projects etc.

The physical arenas that are provided within an office building or site, facilitate physical meeting points for both spontaneous and planned interactions. Creating suitable physical arenas is vital since physical distance plays an important role in facilitating or hindering inter-team communication. For example, interaction is facilitated for teams that have their desks in close proximity to each other. Also, providing dedicated spaces for team or project meetings creates a fixed point both for those belonging to the team or project (e.g. for stand-up meetings, location of project status board), and for others who need to contact them. Other physical arenas to consider are social areas for coffee breaks and lunches. The placement of such areas can encourage cross-team meetings. Physical arenas can also be created for specific events that are held either regularly (e.g. project meetings, department days), or as one-off events (e.g. workshops, guest speakers).

Virtual arenas and digital meeting points complement the physical ones in providing tool support for inter-team communication that becomes increasingly important as an organisation grows. ICT can facilitate information share, awareness of teams and individuals, and can be used to create on-line meetings and events. These channels complement the direct communication of physical meetings by enabling also distant teams to participate, and by providing knowledge, e.g. through Wiki pages and discussion forums. We recommend that organisations agree on a common set of communication tools and channels to use to avoid multiple non-connecting virtual arenas within the same organisation.

Finally, organisational arenas, i.e. organising employees into units and teams, and thereby provide groups and structures within which individuals and teams interact. This includes line organisational units such as departments and teams, and work-related unit such as projects and task forces. The traditional line- and project organisations can be complemented by other organisational groupings, such as interest groups, disciplines, or role-specific groups, to create additional cross-functional and cross-organisational interactions. Our study points to several aspects to consider when composing a team including the characteristics of the team itself (size, age, seniority etc., F6–F10) and its attitude to other teams, where the latter is affected by company culture (F3) and personality (F5). This indicates the complexity of the issue of inter-team communication that ranges from aspects of the individual within a team to organisational issues such as team and work composition.

We want to highlight the importance of inter-team communication especially within large organisations and encourage management to consider this aspect when designing the physical, virtual, and organisational arenas for their organisations. This includes considering which strategies to use to facilitate inter-team communication, e.g. concerning job and office rotation (S3) and key people (S4). An important part of a company’s strategy is to actively promote cultural values that support inter-team communication, such as mutual trust, transparency, and tolerance for admitting mistakes between teams.

7.2 Case company learnings and conclusions

This study has provided value to the case company by confirming the importance of certain known inter-team communication factors and strategies, and by providing the company with new insights. The known and confirmed aspects include:

• Organizational aspects (F9) that have been actively preserved during the growth of the company, where new test teams (such as Non-video devices) have been placed within the QA organization rather than within the development teams.

• Importance of team building (S2), represented by the QA days where team members are actively encouraged to meet people from other teams (lowering psychological distance) and where the hosting team has a chance to present their daily work (lowering cognitive distance).

• Tooling (S5) has been acknowledged as a challenge within the company, as the company culture encourages freedom of choice for teams. However, for certain tools, such as test management tools, the QA department has actively worked towards the use of common tools (lowering cognitive distance), despite this not always being popular with certain teams.

Going forward, the study provides the company with evidence for these choices and can be used as arguments for continuing to use them to strengthen the communication between the QA teams. But, there are also some factors and strategies that this study has highlighted that have not been as actively used by the company. This represents an opportunity for the company to further strengthen inter-team communication. One such factor is the importance of Key People (S4) that act as boundary spanners, connecting different teams. While the QA days bring together all the team members in all the teams, more focused effort on bringing together and nurturing people that act as connectors between the teams is an underused strategy by the company. Another factor is Tool Support for Interaction (S5) and making better use of ICT tools to create virtual arenas that can ease and support knowledge sharing between teams. The company’s existing physical meeting arenas can be complemented by virtual meeting points.

7.3 Future research directions

There are several interesting avenues to pursue in future research within this area. For example, to investigate how to design and combine physical, virtual, and organisational arenas to complement each other in achieving good inter-team communication. There is also a need to design and empirically validate methods and tools for assessing inter-team communication within an organisation and for providing guidance to management regarding how to continuously improve and adapt the provided arenas to the changing needs of their organisations. In addition, we have identified relationships between factors, strategies, and distances, and in this paper pose hypotheses regarding these relations. Further research is needed to test and validate these hypotheses and to investigate if there are other potentially influencing factors. Finally, as research and knowledge of inter-team communication is accumulated and matures, we would welcome the development of an empirically based theory of inter-team communication that captures and represents this knowledge concisely, and thereby facilitates communicating this knowledge within software engineering.

Appendices

Appendix A: Measured distances between teams

See Fig. 8

Fig. 8

Overview of the measured cognitive and psychological distances between teams. Each row shows a team's mean distances to each of the other teams and the standard deviation for each value. The scale for distances is 1—for short (marked with green), 2 -medium (marked with yellow), and 3—long (marked with red) distance

Appendix B: Protocols for focus group meetings

2.1 Focus group with test team management

• 1. Round-the-table introductions of participants and the teams they manage. Write names on signs.

• 2. Welcome (5 min): present context of research including confidentiality and audio recording

• 3. Open discussion (15 min)

  • a. Introduction to boxplots and how to read them

  • b. What rating do you think your team received for total cognitive and psychological distance? Note answer privately on paper.

  • c. Round-the-table presentation of guess with motivation. Summarise on whiteboard.

  • d. What is your experience of poster voting? What discussion have there been in your teams related to this?

• 4. Present results from posters (30 min)

  • a. Show boxplots of total cognitive and psychological distance

  • b. Why this result? Is it expected, or unexpected? Can you explain the ratings?

• 5. Next steps (5 min): How do we want to proceed? Suggestion: Workshops per team to discuss results

2.2 Focus group with individual test team

• 1. Introduction (10 min)

  • a) Who’s who: name, main responsibilities/tasks, time at company and in team. Fill in pre-printed signs with numbers.

  • b) Present context of research incl confidentiality and audio recording. Explain cognitive and psychological distance, and relate these to posters. Present the aim of today, i.e. to present and discuss the data.

• 2. How did you experience poster voting? (10 min)

  • a) Open question.

  • b) Follow-up questions: Interactions &/ discussions in team around poster? Voting strategy? Gains, new insights, discussions? Any risks or problems, e.g. affect on results due to influenced by other votes, others, lack of anonymity?

• 3. Total distance experienced towards our team (10 min)

  • a) Introduction to boxplots, mean and 25–75% range

  • b) Show results of total distance perceived for each team

  • c) Is it expected, or unexpected? Can you explain the ratings? Make note of factors mentioned by participants.

• 4. Distance we experience towards other teams (10 min)

  • a) Which teams are easy vs hard, and why? Make note of factors mentioned by participants.

• 5. Perceived distance towards our team (10 min)

  • a) Is it expected, or unexpected? Can you explain the ratings? Make note of factors mentioned by participants.

• 6. Sum-up of factors (10 min)

  List the factors mentioned during the meeting and ask if any additional ones from the list below are relevant to add.

  • a) Can you think of any other relevant factors to add? Do you want to merge any factors?

  • b) Which factors have the largest/most serious impact on the communication between teams? Vote by distributing 10 markers each (in total) on the factors. After everyone has voted. Discuss how and why the factors have been rated.

  • c) How can your team address these factors? How would this improve your ability to do a good job?

2.3 Factors (identified prior to the focus group meetings)

• Competence / Work tasks

• Office location / physical proximity

• Seniority / Time with company

• Organizational changes (team split / merge)

• Organisation and work processes

• Attitude / culture

• Awareness of others

• Targeted products (similar technical domain)

• Job rotation

• Personality

• Interaction (frequency & extent)

• Size of targeted software component

• Team size

• Architectural layer / domain

• Agreement / Similar opinions