# Communication in Teams - An Expression of Social Conflicts

Jil Klünder, Kurt Schneider, Fabian Kortum, Julia Straube, Lisa Handke, Simone Kauffeld

► To cite this version:

Jil Klünder, Kurt Schneider, Fabian Kortum, Julia Straube, Lisa Handke, et al. Communication in Teams - An Expression of Social Conflicts. 6th International Conference on Human-Centred Software Engineering (HCSE) / 8th International Conference on Human Error, Safety, and System Development (HESSD), Aug 2016, Stockholm, Sweden. pp.111-129, 10.1007/978-3-319-44902-9_8. hal-01647704

HAL Id: hal-01647704

https://inria.hal.science/hal-01647704

Submitted on 24 Nov 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Communication in Teams - An Expression of Social Conflicts

Jil Klünder¹, Kurt Schneider¹, Fabian Kortum¹, Julia Straube², Lisa Handke², and Simone Kauffeld²

¹ Software Engineering Group
Leibniz Universität Hannover
Welfengarten 1, 30167 Hannover, Germany

{jil.kluender, kurt.schneider, fabian.kortum}@inf.uni-hannover.de

² Dept. for Industrial/Organizational and Social Psychology
Technische Universität Braunschweig
Spielmannstraße 19, 38106 Braunschweig, Germany

{julia.straube, l handke, s kauffeld}@tu-bs.de

**Abstract.** The more members a team has, the more information needs to be shared with single team members or within the whole team. Sufficient information sharing is difficult to ensure, since a project leader will not be fully aware of all on-going information and communication within the team. In software engineering, information flow is essential for project success. In each part of the process, information like requirements or design decisions needs to be communicated with appropriate persons. Neither missing nor wrong implemented requirements are desirable, since extra working hours or incomplete working results need to be paid. Therefore, the right amount of information sharing is highly desirable. To ensure this, communication is a mandatory requisite. Furthermore, knowing about social conflicts is suitable, since these influence the information flow.

In an experiment with 34 student software projects, we collected data referring to internal team communication and mood. In these projects, we could show a correlation between chosen communication channels, social conflicts and mood. Since social conflicts foster an insufficient information flow, knowing about these helps software developing teams to reach higher quality and a higher customer satisfaction.

## 1 Introduction

Ensuring the right amount of information sharing with all involved persons is often difficult. Some information only needs to be communicated with a few team members, while other information needs to be shared within the whole team.

In software engineering, the impact of "appropriate" communication on project success has been discussed frequently (e.g. [28][23]). Both, the communication with the customer and the inner team communication require special attention to provide high quality project results with well performing functionalities [16]. Communication is important for working in groups. Furthermore,
motivated by the importance of information sharing within the project team, communication has been proven to be a determinant of project success [19].

In software developing teams, wrong or insufficiently transmitted requirements often cause wrong or not implemented parts of the software [27]. Therefore, insufficient communication can threaten project success. Otherwise, adequate communication can foster project success. Hence, a good working communication is desirable for all project members: The developer team that does not want to spend time on implementing unnecessary program code, the project leader who wants to complete the tasks, and lastly the customer who wants a successful project. But not only requirements need to be shared within the team. Also design decisions, customized standards, reports about bugs and many other information need to be transported to the relevant persons.

As Stapel [30] pointed out, not only the intensity of communication, but also the chosen communication channel is important for transmitting the desired information. In the "Modes of Communication", Cockburn [5] rated different kind of communication channels by their effectiveness and richness. Among other characteristics like synchronicity, the perceptions addressed by the media channels are one factor for the grading. For example, meetings with face to face communication – in physical support with a white board – are the most effective way to communicate [1][5]. As teams often do not have the opportunity to meet regularly and since meetings often do not suffice for conveying the entire information at hand, other ways of information sharing need to be used. In practice, common alternatives are services like email, video chat, telephone or group and single chat.

Schneider et al. [26] developed an approach to combine communication channels and the intensity. They used *FLOW distance*, which is defined to be a measure for the collaboration in teams.

In this contribution, we want to motivate the usage of FLOW distance by achieving a relationship between FLOW distance, and hence communication behavior, mood and social conflicts in software developing teams.

Along with the findings of Watson et al. [35], mood can be described using positive and negative affect. While persons in a state of high negative affect feel anger, disgust and fear, persons in a state of high positive affect feel active, enthusiastic and alert [35]. The affects of persons working in groups converge over time, meaning that the mood of all team members assimilate [6][32]. This assimilation influences team performance as well as important process variables: For example, Barsade [3] was able to prove that positive group mood is associated with better performance and less conflicts.

This paper concentrates on the positive affect dimension, as we assume that positive group mood facilitates action (cf. [21]) and will thus be beneficial, especially at the beginning of the project.

We are able to show that summarizing the chosen communication channels and the communication intensity using FLOW distance has a relation to social
conflicts and mood. The FLOW distance between two members measures the indirections and barriers hampering the information flow when they communicate. Given by the intuitive comprehension of distance, FLOW distance increases with a decreasing collaboration and with the usage of non-direct communication channels and vice versa.

In an experimental study on 34 student software projects, we show a correlation between FLOW distance, social conflicts and mood at certain stages of the project. Therefore, an increasing FLOW distance can be seen as indication for difficulties within the team. Therefore, observing FLOW distance may be helpful for the project leader. It helps assuming problems within the developing team and working against lack of information sharing. In the case of a well-working communication, the project leader finds out that there is no reason to modify or adjust the used media channels.

The structure of this article is as follows: In the following section 2, we give an overview of related work in similar topics. In section 3, we motivate and give the definition of FLOW distance with its properties and the way of calculation. Afterwards, we validate our approach in section 4, followed by section 5, in which we discuss the results. Section 6 summarizes our work.

## 2 Related Work

The relationship between communication intensity, communication channels and project success has been studied for a long time in software engineering. This chapter gives an overview about already existing approaches in certain topics which are related to this paper: The combination of social network analysis with the FLOW method to analyze information flows and the distance, i.e. collaboration, within the team referring to the communication intensity of a co-located working software developing team.

The idea of combining social network analysis and communication intensities is not entirely new. In the context of the collaboration within a team, Damian et al. [8] studied the awareness among team members in global software development teams using methods of social network analysis. They found a positive correlation between communication and awareness within so-called requirements-centered social network analysis.

Additional work often refers to team communication centralization that indicates the degree to which communication is focused on a subset of participants or even a single person. High centralization can be considered as an indication of unequal communication participation (for other network measures of participation, such as Maverick score, see [24]). Centralization of communication compiles structural and quantitative elements (weights) into an indicative number. It is a widely-used metric in social network analysis.

Sauer et al. [25] applied social network analysis to team interaction. They investigated the calculation of centralization for various kinds of small group
interactions. After having conceptualized group discussions as networks, they
were able to present a metric calculating a centralization for these networks
using extensions of Freeman's metrics for centrality measures [11]. In the end,
they examine the relationship between team performance and centralization of
the interactions during the meeting.

In software engineering, Wolf et al. [38] also applied social network analysis
to team communication structures. They wanted to indicate the importance of
developer communication for software integrations. In order to reach this aim,
they used well-elaborated measures like density and centrality in general as met-
rics.

The *FLOW method* serves for visualizing and analyzing information flows in project teams. It was introduced and presented by Stapel et al. [31]. The general structure of communication within the team is extended about the state of information flow: *Solid* information summarize all information that is repeatable, long term accessible and comprehensible for third parties, whereas *fluid* information is everything which is not solid.

Although most research concerning the *distance* in teams refer to distributed
software developing teams, there are some approaches that are comparable to
our approach, which focuses on co-located teams.

Bjarnason [4] identified different variants of distance in software engineering
literature. She stated that distance plays an important role in both, distributed
and co-located software development. In her systematic literature review, she
found eight different distances between people, i.e. within the team, also includ-
ing the geographical distance. In the context of this contribution, Bjarnason's
results concerning the *socio-cultural distance* including among other things or-
ganizational and national culture, language and individual motivations, *opinion
distance* and *organizational distance* are important. The most important results
are those related to the *psychological distance*. Prikladnicki [24] has denoted
psychological distance as a "measure of the perceived psychological (subjective)
effort of an actor to communicate with another actor" [4].

There have already been various researches relating to *FLOW distance*. Schneider et al. [26] presented a first approach of defining and using FLOW distance. The authors evolved the idea of a "perceived distance" generated by the communication intensity and a certain weighting of the used communication media. Schneider et al. considered FLOW distance as "the number of weighted indications between source and target of an information flow" [28]. In the present contribution, we will refine the definition and motivate this approach by pointing out a relation between FLOW distance, social conflicts and mood.
## 3 FLOW distance

FLOW distance is a metric combining communication intensity and used media. Exploring the information flow within a project, FLOW distance simplifies the detection of the wrong amount of communication and therefore indicates problems in information sharing. Considering the FLOW distance enables strategic changes in the way of communication (for example by adding an obligatory meeting each week) and hence a better flow of relevant information.

In this contribution, we want to elaborate the already existing definition of FLOW distance (cf. [28][26]) restricted to a static network of a single software developing team consisting of three to five co-located working members. We want the measure to consider the used media and the subjective communication intensity between two persons within these teams. FLOW distance can also be used to analyze the structure of a team using social network analysis.

The requests and restrictions can be summarized as follows:

- FLOW distance should consider the communication intensities and the used media.

- It shall increase with a decreasing collaboration and vice versa.

- It has to be practicable, i.e. it needs to be easy to calculate and the input data need to be collectable with low effort.

- For later research, it needs to be extendable towards bigger software developing teams and to FLOW models<fnref n="3" />.

Fulfilling these requests yields to a few more definitions and analyses before giving the definition of FLOW distance.

1. Creating a mathematical model of FLOW distance which allows a precise and well-founded definition.

2. Weighting the used media with respect to their effectiveness and richness. This needs to be done at least for the common used communication channels "meetings (F2F)", "video chats", "chats", "emails" and "phone calls".

3. Defining and calculating the communication intensity only using easily collectable data.

4. Giving the definition of FLOW distance and using it for calculation.

These steps will be executed in the course of this chapter.

### 3.1 Mathematical View

We consider FLOW distance as a mapping $d: A \times A \rightarrow [0, 1]$, where A denotes the set of all team members and [0, 1] is the unit interval<fnref n="4" />. We understand FLOW

<footnote n="3">³ This extension will not be part of this contribution.</footnote>

<footnote n="4">⁴ The restriction of the image of $d$ to the unit interval helps comparing the FLOW distances of different teams.</footnote>
distance as a metric from a mathematical point of view, i.e. it is (i) positive definite, (ii) symmetric and (iii) the triangle-inequality holds:

(i) *positive definite*: The measure is always greater than or equal to zero. It vanishes if and only if the two persons are the same, i.e. $d(i, i) = 0$ and $d(i, j) \neq 0 \forall i \neq j$.

This is useful, since there is no interpretation for negative distances between two members and having a FLOW distance of zero between to different members would mean that they spend the whole time together exchanging each thought.

(ii) *symmetric*: Along the lines of Watzlawick's findings [36], one cannot not communicate, meaning that also if only $i$ sends many emails to $j$ without receiving an answer, $j$ communicates with $i$ by receiving the emails. Therefore, the mapping $d$ should be symmetric, even if the communication is one-directional.

(iii) *triangle-inequality*: The FLOW distance between two team members $i$ and $k$ should be greater than or equal to the sum of the FLOW distances between $i$ and $j$ and $k$ and $j$ and $k$, i.e. $d(i, k) \ge d(i, j) + d(j, k)$. In the context of communication, this means that communicating via a third person let the distance between the two other persons increase.

## 3.2 Media Richness and Effectivity

We consider the common used communication media "email", "phone call", "video chat", "chat" and "meeting". Intuitively, the intensity and efficiency are the largest in meetings, followed by video chat, chat, phone and email. There are proper justifications to use this or a very similar grading of the media [10].

First of all, the more human senses the media addresses, the more information can be transported. One does not only communicate by speaking; the facial expression, the gestures and the voice are not less important than the used words [7]. In meetings and video chats, most senses are addressed. In chats, emails and in phone calls, there is only written or heard text. This way, we get the following weighting:

$$ meetings = video\ chat > email = chat = phone\ call $$

Furthermore, we should consider the synchronicity of the media [9]. Meanwhile meetings, chats, video chats and phone calls are instantaneous, emails often need much time until the receiver answers them. Therefore, the weighting of emails should be smaller than the weighting of chat and phone calls, i.e.

$$ meetings = video\ chat > chat = phone\ call > email $$

Due to the direct face-to-face communication without screens or bandwidth (potentially limiting the information flow) and the interactions of team members in one room, the importance of meetings should be bigger than the importance
of video chats. Therefore, we get the following final order of the efficiency and effectivity of the media:

meetings > video chat > chat = phone call > email

Table 1 reflects the weighting of media gained by starting with 1 and increasing the weighting about one unit at each jump in the previous ordering. These weights will be used for calculating FLOW distance.

<table><caption>**Table 1.** Media weighting for calculating FLOW distance</caption><tr><td>meeting</td><td>4</td></tr><tr><td>video chat</td><td>3</td></tr><tr><td>chat</td><td>2</td></tr><tr><td>phone call</td><td>2</td></tr><tr><td>email</td><td>1</td></tr></table>

Cockburn's [5] and Ambler's [1] reflections support this ordering. In his "Modes of Communication", Cockburn proposes a grading of various communication channels referring to their "richness" and "effectiveness". Figure 1 represents these findings, which can be retrieved in the grading above.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** Modes of Communication [1]</figcaption></figure>
## 3.3 Communication Intensity

Calculating the FLOW distance requires a certain kind of communication intensity. Therefore, each team member is asked to estimate the intensity of communication with respect to each other team member. This way, we gain a matrix of the following structure:

$$ \begin{bmatrix} 0 & a_{12} & a_{13} & a_{14} & a_{15} \\ a_{21} & 0 & a_{23} & a_{24} & a_{25} \\ a_{31} & a_{32} & 0 & a_{34} & a_{35} \\ a_{41} & a_{42} & a_{43} & 0 & a_{45} \\ a_{51} & a_{52} & a_{53} & a_{54} & 0 \end{bmatrix} $$

where each $a_{ij}$ has a value between 0 and $4^5$. Ideally, this matrix is symmetric, i.e. $a_{ij} = a_{ji}$ for all team members $i, j \in A$. But since the statements concerning the intensity are all subjective and there does not exist a (non-technical) objective reference, this matrix will probably never be symmetric. Therefore, we calculate the average of each $a_{ij}$ and $a_{ji}$ to gain the resulting communication intensity between $i$ and $j$.

## 3.4 Calculation

To simplify the calculation of FLOW distance, let $d_{ij} = d(i, j)$ denote the FLOW distance between two team members $i$ and $j$. To gain a comparability between FLOW distances of different teams, we want to restrict the image of $d$ to the unit interval. Therefore, we need a certain kind of normalization.

As variables, we only need a list of used communication channels written by person $i$ respectively $j$ and the perceived communication intensity.

In a first step, we calculate the product $c_{ij}$ of the communication intensity and the sum of the weightings of all used media. For example, if two persons have communicated using chats (2), emails (1) and a face-to-face meeting (4) with an average perceived intensity of 4, we would calculate

$$ 4 \cdot (2 + 1 + 4) = 28, $$

where 2, 1 and 4 represents the weightings of the used media (see table 1). Then, FLOW distance $d_{ij}$ is given by

$$ d_{ij} = 1 - \frac{c_{ij}}{c^*}, $$

where $c^*$ denotes the theoretical maximum of $c_{ij}$ within the regarded team constellation. In a team with five members using meetings, video chats, chats, phone calls and emails, $c^*$ would be calculated as

$$ c^* = 4 \cdot (4 + 3 + 2 + 2 + 1) = 48, $$

<footnote n="5">⁵ This area was fixed by the study design and may be adapted to other study designs.</footnote>
where 4 is the maximal possible communication intensity. Looking at the example of above, the FLOW distance is

$$d_{ij} = 1 - \frac{28}{48} \approx 0,4167.$$

The FLOW distance of the whole team, d, is given by the average of the FLOW distances of the team members, i.e.

$$d = \text{avg}\{d_{ij} : i \neq j \in A\}.$$

## 3.5 FLOW centralization

Using FLOW distance calculation, we can create the FLOW centralization which gives an overview for the structure of the team. As centralization and centrality are common measures in psychology and social network analysis to analyze team structures and the collaboration, FLOW centralization can be applied to further calculations in social network analysis.

We start with an upper triangular matrix D, where the entry $d_{ij}$ is given by the FLOW distance between the members i and j. The FLOW centralization is then calculated as follows:

We get the FLOW centrality of a person j by summing up over all FLOW distances between this person and all other team member, i.e.

$$\text{centrality}(j) = \sum_{i \in A} d_{ij},$$

where A again denotes the set of all team members and $d_{ij}$ is the FLOW distance (respectively the entries in D). The higher a person's centrality, the closer he or she is generally to the other team members.

Let now centrality$_{max}$ denote the score of the team member who has the maximum centrality, i.e.

$$\text{centrality}_{\max} = \max\{\text{centrality}(j) : j \in A\}.$$

Then, we calculate the FLOW centralization by

$$\text{centralization} = \sum_{j \in A} \frac{\text{centrality}_{\max} - \text{centrality}(j)}{\text{centrality}^*}, \quad (*)$$

where centrality* denotes the theoretical maximum of centrality.

Calculating centrality* bases on considering the star shape as network [11]. The star network has the largest centralization, which is why it is used to normalize the FLOW centralization. In this network, we weight each edge with $c^*$, which is defined to be the most possible communication interaction (gained by using all media with the most perceived intensity). Figure 2 shows the star shape network with five persons.
<figure><img src="image_3.png" /><figcaption>**Fig. 2.** The star shape network with five persons. In this example, person E is the most central team member.</figcaption></figure>

Considering not an individual's centrality, but the group centralization allows conclusions about the team internal structure<fnref n="6" />: The higher the centralization, the more individual members communicate via one dominant actor rather than directly to one another.

# 4 Empirical Validation

To motivate the use of FLOW distance and FLOW centralization, we want to show the relationship between communication channels, perceived communication intensity and social conflicts.

As several studies have shown, a low degree in centralization appears to be beneficial for team performance [28][25]. As software projects are considered to be highly dynamic entities, communication structures may also be expected to vary over time [2]. The project's midpoint may be particularly relevant in this case, as teams have been shown to display increased effort at this time [12][34]. Furthermore, at this stage of the project, team structures also seem to change, as individual expectations and perceptions transform into shared group goals and understandings [13][12]. Considering that team development during this point in time also involves conflict resolutions [15], we assume that it will be influential on how teams deal with relationship conflicts throughout the rest of the project. We thus hypothesize that a higher degree of FLOW centralization in the middle of the project will also be associated with increased social conflicts later on.

<footnote n="6">⁶ The benefit of using FLOW centralization will be outlined in section 5.2.</footnote>
H1: The degree of FLOW centralization at midpoint will be positively related to the degree of social conflict at the end of the project.

Positive affect has been known to increase social integration, i.e. the extent to which people are positively linked to one another, as it can be linked to approach-oriented and cooperative behaviors [18]. Furthermore, group affect seems to influence how members regulate their behaviors when facing a deadline [17], such as a quality gate<fnref n="7" /> at project's midpoint.

Interactions in early project stages have been shown to consist of long-lasting effects [12][39]. We thus assume that the degree to which the team's positive affect after their first meeting will influence the degree of FLOW centralization at midpoint.

H2: The degree of the team's positive affect after the first meeting will negatively influence the degree of FLOW centralization at midpoint.

In line with Totterdell et al.'s [33] assertion that social networks act like conduits for affect to flow and converge through, we furthermore assume that positive group affect after the first team meeting will decrease the incidence of social conflicts at the end of the project via decentralized communication structures at midpoint.

H3: Centralization will mediate the relationship between positive affect after the first team meeting and social conflicts at the end of the project.

To validate these hypotheses, we conducted a study with 34 student software projects.

## 4.1 Student software projects

At Leibniz Universität Hannover, the Software Engineering Group offers a yearly repeating course called Software-Project (SWP), which is scheduled in the last (third) year of the computer science bachelor curriculum. Participating in this course is a requisite in order to complete the undergraduate studies.

In this course, the teams mostly consist of five students developing a software for a customer, who is usually part of the software engineering group and who has a real interest in project success. The projects resemble industrial projects, but also consider the academic environment<fnref n="8" />. The students need to organize themselves, i.e. they need to coordinate the meetings with the customer, within their team, and with the advisors at the right time and in an appropriate way.

<footnote n="7">⁷ Within a quality gate in project course, a responsible person, the so-called gate keeper, decides about the release of the next project step on the basis of clearly determined quality criteria [29].</footnote>

<footnote n="8">⁸ A german description of all tasks can be found at http://www.se.uni-hannover.de/pages/de:lehre_fungate.</footnote>
The teams get supported by a coach who is part of the software engineering group.

Within the 15 weeks of the fall semester, the students learn to work in a team, talk to the customer and organize the internal communication. To support them and to get the ability to obtain feedback, the teams had to pass three quality gates – after the requirements elicitation, after the design and at the end of the project.

The students are free to choose time and location for their meetings. They also autonomously decide on how often they meet and which communication channels they use.

With regards to the technical experiences in executing a project, teams need to elicit requirements, design, implement, and test their product. Thus, they pass through all common phases of the waterfall model. They need to write a requirements specification and either create a design or implement a prototype of the product. Co-located in the process, they furthermore make a review of the design respectively the prototype of another team. In the last step, they develop the software, which needs to be approved by the customer.

## 4.2 Study Design

In 2012 and 2013, a total of 165 students participated in the Software-Project. They worked in 34 teams mostly consisting of five persons. There was only one team consisting of four students, and two teams with three students. Each team worked together for a period of 15 weeks. Due to missing data, we had to exclude one team from the analyses. The final sample therefore consisted of 33 teams (160 individuals).

During the course, the students were asked to fill in questionnaires at three specific dates: after the initial meeting with the customer, after half of the project duration and at the end of the project. Questionnaires contained items on e.g. positive affect and social conflicts. We did not ask the students to report on the cause of conflict, but the mostly arising conflicts have been caused by different attitudes to work, reliability and different abilities to work in a team. Additionally, the team members filled out a weekly online-questionnaire referring to the interactions with other team members.

To assess the communication within the teams, we asked each team member to record his or her communication with each other member of the team. They were free to choose gradations between "not communicated at all" and "very high". We did not raise the frequency of the used communication media. During a whole week, the frequency influences the perceived intensity, so that measuring perceived intensity is sufficient for our approach. Furthermore, each team member stated the used communication media with respect to every other team member. The channels "in one room", "video", "chat", "telephone" and "email" were available. Additionally, the project leader was asked to state the duration of all meetings and the presence of each team member.
## 4.3 Ethics Committee

The ethics committee at Leibniz Universität Hannover authorized this elevation of data. We informed the students about the collection of data and the further usage. All data records were anonymized and the data did not influence the success of passing the course.

## 4.4 Methodology

**Measures.** Within the scope of this contribution, we used the following data:

*FLOW centralization* at midpoint of each project's total duration was measured using a communication score derived from data obtained via the self-report in week 7. Using the individual ratings of intensity and media, an undirected communication matrix for each team and for every week was obtained by averaging the two scores for communication intensity and by determining the maximum value for media use for each communication pair, and then multiplying these two scores (see section 3.5). As described by the formula (*) in section 3.5, FLOW centralization was computed in adding up the differences between the most central team member's centrality and centralities of all other team members and subsequently dividing them by the theoretical maximum score of 576 (288 and 96 for the teams with four or three members respectively).

*Social conflict* was measured using the German version of Jehn's [14] ingragroup conflict scale by Lehmann-Willenbrock, Grohmann and Kauffeld [22], adapted to the context of teams. The scale consisted of four items with a six-level range from 1 = "never/none" to 6 = "very often/very much". An exemplary item was "How much friction is there among members in your team?" The measurement was taken at the end of the project. The reliability value for this scale was $\alpha = .87$.

*Positive affect* was measured using the German translation of the positive and negative affect scale (PANAS) [35] by Kroehne et al. [20]. The response format ranged from 1 = "not at all" to 5 = "extremely". The questions were answered after the first team meeting in week 1. The scale, which consisted of ten items, showed a reliability of $\alpha = .85$.

To obtain group level constructs for social conflict and positive affect, individual scores were mean-aggregated to the team level.

**Data Analysis.** Statistical procedures were performed using SPSS 22 (IBM Corp.). In order to avoid alpha error inflation, all three hypotheses were tested in one mediation model. The PROCESS-macro for SPSS by Andrew F. Hayes<fnref n="9" /> was employed for the mediation analysis.

While the path from the mediator (FLOW centralization) to the dependent variable (social conflict) was used to test the first hypothesis, the path from the predictor (positive affect) to the mediator (FLOW centralization) served to test the second. As both of these hypotheses are directed, we will later report

<footnote n="9">⁹ For further information see http://www.afhayes.com.</footnote>
the results of one-tailed hypothesis tests. The third hypothesis was tested in calculating the indirect effect from positive affect via FLOW centralization to social conflict. Figure 3 shows the hypothesized mediation model<fnref n="10" />.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Mediation model</figcaption></figure>

## 4.5 Results

Table 2 shows descriptive statistics and intercorrelations among the variables under study. As table 3 shows, the unstandardized coefficient between FLOW

<table><thead><tr><th></th><th>M</th><th>SD</th><th>Min</th><th>Max</th><th>1</th><th>2</th><th>3</th></tr></thead><tbody><tr><td>1 Pos. Affect</td><td>3.16</td><td>0.33</td><td>2.60</td><td>3.86</td><td>-</td><td></td><td></td></tr><tr><td>2 Centralization</td><td>0.15</td><td>0.11</td><td>0.01</td><td>0.51</td><td>-.31†</td><td>-</td><td></td></tr><tr><td>3 Social Conflict</td><td>2.36</td><td>0.75</td><td>1.35</td><td>4.19</td><td>-.22</td><td>.50**</td><td>-</td></tr></tbody></table>

<caption>Table 2. Descriptive statistics and intercorrelations among variables</caption>

centralization and social conflict was statistically significant ($p = .007/2 \approx .004$). The first hypothesis was thus supported. Showing a clear negative tendency, the relationship between positive affect and FLOW centralization also reached statistical significance ($p = .063/2 \approx .03$). The second hypothesis was thus also

<footnote>†p < .1, *p < .05, **p < .01</footnote>

<footnote n="10">¹⁰ In order to ensure a better understanding of the results, coefficients are also included in the model.</footnote>
corroborated. The relationship between positive affect and social conflict was mediated by FLOW centralization. We tested the significance of this indirect effect using bootstrapping procedures. Unstandardized indirect effects were computed for each of 1000 bootstrapped samples, and the 95% confidence interval was computed by determining the indirect effects at the 2.5th and 97.5th percentiles. The bootstrapped unstandardized indirect effect was -.3551, and the 95% confidence interval ranged from -.9553 to -.0169. Thus, the indirect effect was statistically significant, supporting hypothesis 3.

<table><thead><tr><th rowspan="2"></th><th colspan="4">Centralization</th><th colspan="4">Social Conflict</th></tr><tr><th>Coeff.</th><th>SE</th><th>t</th><th>p</th><th>Coeff.</th><th>SE</th><th>t</th><th>p</th></tr></thead><tbody><tr><td>Pos. Affect</td><td>-0.11<sup>†</sup></td><td>0.05</td><td>-1.93</td><td>.063</td><td>-0.14</td><td>0.37</td><td>-0.38</td><td>.705</td></tr><tr><td>Centralization</td><td>-</td><td>-</td><td>-</td><td>-</td><td>3.37<sup>**</sup></td><td>1.16</td><td>2.90</td><td>.007</td></tr><tr><td>Constant</td><td>0.48<sup>**</sup></td><td>0.17</td><td>2.78</td><td>.009</td><td>2.31<sup>†</sup></td><td>1.26</td><td>1.84</td><td>.076</td></tr></tbody></table>

<caption>**Table 3.** Results of the mediation analysis</caption>

# 5 Discussion

In this section, we consider the study's limitations and threats to validity before interpreting and discussing our findings.

## 5.1 Limitations and Threats to Validity

Referring to our evaluation with students, we had to make some limitations with regards to the real world. These limitations may threaten the validity of the collected data and therefore influence the results of our calculations. Along with the classifications of threats to validity by Wohlin et al. [37], we divide the threats into *construct*, *external* and *internal* validity and *reliability*.

*Internal validity:* We wanted to consider the changes over the course of the projects. Therefore, all threats concerning the internal validity (e.g. maturation, internal interactions and talking about the project, the questionnaires and the collected data) were desired and to some extent even necessary.

*External validity:* Although there are some modifications of the student projects towards industrial standards, the academic environment still influences the scope and the duration of the projects. The ability of working together in a room each week was supported by the academic environment, since all students mostly worked at university and have been there five days per week. Project leader were not able to access to a big pool of experiences, since they possessed the same

<footnote>†*p* < .1, *p* < .05, **p* < .01</footnote>
amount of experiences as the rest of their team. Therefore, a coach of the software engineering group supported the teams, when any social, i.e. interpersonal, problems occurred. Furthermore, we only considered projects with a duration of 15 weeks with small teams (3-5 members). Almost all participants had the same background in theory and the team internal experiences and knowledge was comparable in all teams. This was given by forming the teams deliberately. Beside these threats, there are no more relating to the external validity.

*Construct validity:* We formulated the questionnaires for the students in a general manner and used reliable gradations and items. But we still cannot ensure that our comprehension of the items correspond with the student's comprehension. We tried to minimize the impact of this wrong understanding through the presence of one of the researchers involved in the project while the students filled out the extensive questionnaires. This threats arose by comparing the perceived communication intensities (the communication matrices have not been symmetric), for instance. We respected these irregularities in the definition of FLOW distance. The weekly report was formulated in a very general manner, so that we do not expect any deviations in the understanding.

*Reliability:* The study's results are statistically significant. But there are still a few threats concerning the reliability of the study. Different projects have different scopes and the knowledge and experience base of each team is different from the other teams. These factors can restrict the reliability of this study.

## 5.2 Interpretation

With our approach of using FLOW distance, we propose a way to comprehend the influences of different communication channels on project success. Along with the findings of our study, we are able to show two things:

(i) The mediation model consisting of FLOW centralization, social conflicts and mood.

(ii) The appropriateness of using FLOW distance to combine the communication channels and the perceived communication intensity.

The experiment supports our three hypotheses:

1. The degree of FLOW centralization at midpoint is positively related to the degree of social conflict at the end of the project. (H1)

2. The degree of the team's positive affect after the first meeting negatively influences the degree of FLOW centralization at midpoint. (H2)

3. Centralization mediates the relationship between positive affect after the first team meeting and social conflicts at the end of the project. (H3)

A suitable amount of information sharing is necessary for project success. Therefore, ensuring information flow is very important for the project leader. Exchanging information goes along with communication – often in meetings, via e-mail, phone or in (video) chats.
Using certain communication channels can foster and ensure information sharing. Obligatory meetings each week can guarantee a minimum of information exchange. Phone calls, e-mails, conversations and chats in addition to the meetings are also mandatory, since they can minimalize loss of information.

Along with our findings, asking each team member about the perceived com-
munication intensity and the used communication channels is a good way to
monitor the information flow.

Combining these data using FLOW distance also indicates social problems
and conflicts at the end of project. As shown in H1 and H2, high positive mood
influences FLOW centralization, which depends on FLOW distance and thus
on communication behavior. The FLOW centralization again has an impact on
social conflicts which can influence the project success.

As the deadline approaches, collaboration is very important. Social conflicts at this point may impair project success, i.e. the successful completion of the overall project. FLOW distance is an indicator for that kind of conflicts. Knowing about conflicts arising with an increasing probability can help solving them before they occur.

Therefore, we are not only able to support the hypothesis that communica-
tion is important for project proceeding, for example because of its influence on
information sharing. Our approach of using FLOW distance as a metric for the
collaboration in teams is also target-oriented with respect to ensure an appro-
priate amount of information flow.

6 Conclusions

This work introduces an approach of using FLOW distance to foster a suitable
amount of information flow in software development teams and therefore project
success.

Internal team communication is very important for project success: In each
part of the project, information needs to be shared within the whole team or
with certain team members.

FLOW distance is a measure combining communication intensities and the
used communication channels, which is much easier to assess than surveying
every interaction between two or more team members. Furthermore, based on
the calculation of FLOW distance, FLOW centralization can be calculated. It
can be applied to methods in social network analysis supporting the recognition
of team internal structures.

Using the data collection of 33 comparable software projects with 160 par-
ticipants, we are able to show the relationship between FLOW centralization,
social conflicts and mood at certain stages of the project. The degree of FLOW
centralization at midpoint is positively related to the degree of social conflicts
at the end of the project, which means that the chosen communication chan-
nels and the perceived communication intensity at midpoint are indicators for
social conflicts at project's end. Furthermore, the degree of the positive affect
negatively influences the degree of FLOW centralization at midpoint: Positive
mood in the developing team (for example reducible to a successful start of the project) has a negative impact on FLOW centralization which depends on communication in the middle of the project. Moreover, the FLOW centralization mediates the relationship between positive affect after the first team meeting and social conflicts at the end of the project meaning that FLOW centralization – and hence communication – links good mood at the start of the project and social conflicts at project’s end.

Therefore, considering FLOW distance helps the project leader to get an overview about possibly existing social conflicts and mood, which influence the information flow and therefore project success. Considering the FLOW distance can foster project success with respect to different metrics: requirement compliance [27], customer satisfaction, and the team mood by preventing unnecessary work through a sufficient information flow.

Future work will inter alia focus on the application of FLOW distance and FLOW centralization in social network analysis to analyze internal team structures and indicate critical interpersonal combinations.

## Acknowledgements

This work was funded by the German Research Society (DFG) under grant number 263807701 (Project TeamFLOW, 2015-2017).

## References

1. Ambler, S.W., et al.: Agile modeling (2002)

2. Balijepally, V.: Collaborative software development in agile methodologies – Perspectives from small group research. AMCIS 2005 Proceedings p. 511 (2005)

3. Barsade, S.G.: The ripple effect: Emotional contagion and its influence on group behavior. Administrative Science Quarterly 47(4), pp. 644–675 (2002)

4. Bjarnason, E.: Distances between requirements engineering and later software development activities: A systematic map, pp. 292–307. Springer Berlin Heidelberg, Berlin, Heidelberg (2013), http://dx.doi.org/10.1007/978-3-642-37422-7_21

5. Cockburn, A.: Agile software development: The cooperative game. Pearson Education (2006)

6. Collins, A.L., Lawrence, S.A., Troth, A.C., Jordan, P.J.: Group affective tone: A review and future research directions. Journal of Organizational Behavior 34, pp. 43–62 (2013)

7. Daft, R.L., Lengel, R.H.: Information richness. A new approach to managerial behavior and organization design. Tech. rep., DTIC Document (1983)

8. Damian, D., Marczak, S., Kwan, I.: Collaboration patterns and the impact of distance on awareness in requirements-centred social networks. In: Requirements Engineering Conference, 2007. RE’07. 15th IEEE International. pp. 59–68. IEEE (2007)

9. Dennis, A.R., Fuller, R.M., Valacich, J.S.: Media, tasks, and communication processes: A theory of media synchronicity. MIS quarterly 32(3), pp. 575–600 (2008)

10. Figl, K.: Team and media competencies in information systems. Oldenbourg Verlag (2010)
11. Freeman, L.C., Roeder, D., Mulholland, R.R.: Centrality in social networks: II. Experimental results. Social networks 2(2), pp. 119–141 (1979)

12. Gersick, C.J.: Time and transition in work teams: Toward a new model of group development. Academy of Management journal 31(1), pp. 9–41 (1988)

13. Jarvenpaa, S.L., Shaw, T.R., Staples, D.S.: Toward contextualized theories of trust: The role of trust in global virtual teams. Information systems research 15(3), pp. 250–267 (2004)

14. Jehn, K.A.: A multimethod examination of the benefits and detriments of intra-group conflict. Administrative science quarterly pp. 256–282 (1995)

15. Jehn, K.A., Mannix, E.A.: The dynamic nature of conflict: A longitudinal study of intragroup conflict and group performance. Academy of management journal 44(2), pp. 238–251 (2001)

16. Kauffeld, S., Lehmann-Willenbrock, N.: Meetings matter effects of team meetings on team and organizational success. Small Group Research 43(2), pp. 130–158 (2012)

17. Knight, A.P.: Mood at the midpoint: Affect and change in exploratory search over time in teams that face a deadline. Organization Science 26(1), pp. 99–118 (2013)

18. Knight, A.P., Eisenkraft, N.: Positive is usually good, negative is not always bad: The effects of group affect on social integration and task performance. Journal of Applied Psychology 100(4), p. 1214 (2015)

19. Kraut, R.E., Streeter, L.A.: Coordination in software development. Communications of the ACM 38(3), pp. 69–82 (1995)

20. Krohne, H.W., Egloff, B., Kohlmann, C.W., Tausch, A.: Untersuchungen mit einer deutschen Version der "Positive and Negative Affect Schedule" (PANAS). DIAGNOSTICA-GOTTINGEN- 42, pp. 139–156 (1996)

21. Kuhl, J., Kazén, M.: Volitional facilitation of difficult intentions: Joint activation of intention memory and positive affect removes stroop interference. Journal of Experimental Psychology: General 128(3), p. 382 (1999)

22. Lehmann-Willenbrock, N., Grohmann, A., Kauffeld, S.: Task and relationship conflict at work. European Journal of Psychological Assessment (2011)

23. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., Still, J.: The impact of agile practices on communication in software development. Empirical Software Engineering 13(3), pp. 303–337 (2008)

24. Prikladnicki, R.: Propinquity in global software engineering: examining perceived distance in globally distributed project teams. Journal of Software: Evolution and Process 24(2), pp. 119–137 (2012)

25. Sauer, N.C., Kauffeld, S.: Meetings as networks: Applying social network analysis to team interaction. Communication Methods and Measures 7(1), pp. 26–47 (2013)

26. Schneider, K., Liskin, O.: Exploring FLOW distance in project communication. In: Proceedings of 8th International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE ’15), ICSE 2015 (2015)

27. Schneider, K., Liskin, O., Paulsen, H., Kauffeld, S.: Requirements compliance as a measure of project success. In: Proceedings of the 4th IEEE Global Engineering Education Conference (EDUCON 2013) (2013)

28. Schneider, K., Liskin, O., Paulsen, H., Kauffeld, S.: Media, mood, and meetings: Related to project success? ACM Transactions on Computing Education (TOCE) 15(4), 21 (2015)

29. Sondermann, J.P.: Interne Qualitätsanforderungen und Anforderungsbewertung. Handbuch Qualitätsmanagement/Masing, München 2007, pp. 387–404 (2007)

30. Stapel, K.: Informationsflusstheorie der Softwareentwicklung. Dissertation, Gottfried Wilhelm Leibniz Universität Hannover, München (Apr 2012)
31. Stapel, K., Knauss, E., Schneider, K.: Using FLOW to improve communication of requirements in globally distributed software projects. In: Collaboration and Intercultural Issues on Requirements: Communication, Understanding and Softskills, 2009. pp. 5–14. IEEE (2009)

32. Totterdell, P.: Catching moods and hitting runs: Mood linkage and subjective performance in professional sport teams. Journal of Applied Psychology 85(6), p. 848 (2000)

33. Totterdell, P., Wall, T., Holman, D., Diamond, H., Epitropaki, O.: Affect networks: A structural analysis of the relationship between work ties and job-related affect. Journal of applied psychology 89(5), p. 854 (2004)

34. Waller, M.J., Zellmer-Bruhn, M.E., Giambatista, R.C.: Watching the clock: Group pacing behavior under dynamic deadlines. Academy of Management Journal 45(5), pp. 1046–1055 (2002)

35. Watson, D., Clark, L.A., Tellegen, A.: Development and validation of brief measures of positive and negative affect: The PANAS scales. Journal of personality and social psychology 54(6), p. 1063 (1988)

36. Watzlawick, P., Bavelas, J.B., Jackson, D.D., O'Hanlon, B.: Pragmatics of human communication: A study of interactional patterns, pathologies and paradoxes. WW Norton & Company (2011)

37. Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B., Wesslén, A.: Experimentation in software engineering. Springer Science & Business Media (2012)

38. Wolf, T., Schroter, A., Damian, D., Nguyen, T.: Predicting build failures using social network analysis on developer communication. In: Proceedings of the 31st International Conference on Software Engineering. pp. 1–11. IEEE Computer Society (2009)

39. Zijlstra, F.R., Waller, M.J., Phillips, S.I.: Setting the tone: Early interaction patterns in swift-starting teams as a predictor of effectiveness. European Journal of Work and Organizational Psychology 21(5), pp. 749–777 (2012)