Conference PaperPDF Available

Do You Just Discuss or Do You Solve? Meeting Analysis in a Software Project at Early Stages

Authors:

Abstract and Figures

Software development is a very cooperative and communicative task. In most software projects, meetings are a very important medium to share information. However, these meetings are often not as effective as expected. One big issue hindering productive and satisfying meetings is inappropriate behavior such as complaining. In particular, talking about problems without at least trying to solve them decreases motivation and mood of the team. Interaction analyses in meetings allow the assessment of appropriate and inappropriate behavior influencing the quality of a meeting. Derived from an established interaction analysis coding scheme in psychology, we present act4teams-SHORT which allows real-time coding of meetings in software projects. We apply act4teams-SHORT in an industrial case study at Volkswagen Commercial Vehicles, a large German company in the automotive domain. We analyze ten team-internal meetings at early project stages. Our results reveal difficulties due to missing project structure and the overall project goal. Furthermore, the team has an intrinsic interest in identifying problems and solving them, without any extrinsic input being required.
Content may be subject to copyright.
Do You Just Discuss or Do You Solve?
Meeting Analysis in a Soware Project at Early Stages
Jil Klünder
Leibniz University Hannover,
Software Engineering Group
Hannover, Germany
jil.kluender@inf.uni-hannover.de
Nils Prenner
Leibniz University Hannover,
Software Engineering Group
Hannover, Germany
nils.prenner@inf.uni-hannover.de
Ann-Kathrin Windmann
TU Braunschweig, Dept. of Industrial,
Organizational and Social Psychology
Braunschweig, Germany
a.windmann@tu-braunschweig.de
Marek Stess
THI Investments GmbH
Stuttgart, Germany
m.stesss@thi-investments.de
Michael Nolting
Volkswagen Nutzfahrzeuge
Hannover, Germany
michael.nolting@volkswagen.de
Fabian Kortum
Leibniz University Hannover,
Software Engineering Group
Hannover, Germany
fabian.kortum@inf.uni-hannover.de
Lisa Handke
TU Braunschweig, Dept. of Industrial,
Organizational and Social Psychology
Braunschweig, Germany
l.handke@tu-braunschweig.de
Kurt Schneider
Leibniz University Hannover,
Software Engineering Group
Hannover, Germany
kurt.schneider@inf.uni-hannover.de
Simone Kaueld
TU Braunschweig, Dept. of Industrial,
Organizational and Social Psychology
Braunschweig, Germany
s.kaueld@tu-braunschweig.de
ABSTRACT
Software development is a very cooperative and communicative
task. In most software projects, meetings are a very important
medium to share information. However, these meetings are often
not as eective as expected. One big issue hindering productive and
satisfying meetings is inappropriate behavior such as complaining.
In particular, talking about problems without at least trying to solve
them decreases motivation and mood of the team.
Interaction analyses in meetings allow the assessment of appro-
priate and inappropriate behavior inuencing the quality of a meet-
ing. Derived from an established interaction analysis coding scheme
in psychology, we present act4teams-short which allows real-time
coding of meetings in software projects. We apply act4teams-short
in an industrial case study at Volkswagen Commercial Vehicles, a
large German company in the automotive domain. We analyze ten
team-internal meetings at early project stages. Our results reveal
diculties due to missing project structure and the overall project
goal. Furthermore, the team has an intrinsic interest in identify-
ing problems and solving them, without any extrinsic input being
required.
CCS CONCEPTS
Software and its engineering Programming teams
;
Col-
laboration in software development.
ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea
©2020 Association for Computing Machinery.
This is the author’s version of the work. It is posted here for your personal use. Not
for redistribution. The denitive Version of Record was published in IEEE/ACM 42nd
International Conference on Software Engineering Workshops (ICSEW’20), Oct 5–11, 2020,
Seoul, Republic of Korea, https://doi.org/10.1145/3387940.3391468.
KEYWORDS
Communication, development team, meetings, software projects,
human factors
ACM Reference Format:
Jil Klünder, Nils Prenner, Ann-Kathrin Windmann, Marek Stess, Michael
Nolting, Fabian Kortum, Lisa Handke, Kurt Schneider, and Simone Kaueld.
2020. Do You Just Discuss or Do You Solve? Meeting Analysis in a Software
Project at Early Stages. In IEEE/ACM 42nd International Conference on Soft-
ware Engineering Workshops (ICSEW’20), Oct 5–11, 2020, Seoul, Republic of
Korea. ACM, New York, NY, USA, 6 pages. https://doi.org/10.1145/3387940.
3391468
1 INTRODUCTION
Meetings are an essential part of most software projects [
9
]. How-
ever, these meetings are often not as eective as expected [
8
]. This
is often caused by inappropriate behavior such as complaining or
an insucient preparation. As eective team meetings are strong
facilitators for a successful project [
4
], they should be productive
and ecient in order to have motivated and satised developers [
8
].
Otherwise, the project will progress more slowly and the outcome
will not be as good as possible [
3
]. Since there are a lot of projects
struggling with dicult meetings, our objective is to assess interac-
tions in meetings in order to enable interventions from project leaders
or the management. These interventions help to keep the project on
track. In addition, as the discussion on problems without providing
solutions can lead to so-called complaining cycles [
5
]. They often
lead to unsuccessful meetings which lead to a negative inuence
on project success. In our case study, we analyze whether the team
only identies problems during the meeting or tries to solve them.
The contribution of our paper is two-fold. (1) We present the
coding scheme act4teams-short which emerged from the estab-
lished coding scheme act4teams [
4
]. Given the problems presented
by Prenner et al. [
8
] with the rst version of act4teams-short, we
ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea J. Klünder et al.
extended the coding scheme leading to the version presented in this
paper. (2) We apply the coding scheme in an industrial case study at
Volkswagen Commercial Vehicles, a large German company in the
automotive domain. Our results reveal diculties due to missing
project structure and the overall project goal. Furthermore, the
observed team has an intrinsic interest in identifying problems and
solving them, without any extrinsic input being required.
The rest of the paper is structured as follows: In Sec. 2, we present
the background and related work. In Sec. 3, we present the research
method, followed by the results in Sec. 4 which we discuss in Sec.
5. Section 6 concludes the paper.
2 BACKGROUND AND RELATED WORK
Interaction analyses are widely used in various domains of psychol-
ogy, e.g., such as developmental, social, and organizational psychol-
ogy. Accordingly, our study draws on psychological research, in
particular on the well-established act4teams coding scheme [
4
,
5
].
act4teams is a coding scheme designed for analyzing real team
meetings in organizations. The act4teams coding scheme has been
used in several studies. Kaueld and Lehmann-Willenbrock [
4
]
analyze the eect of team meetings on team and organizational
success. They show that teams with more functional interactions,
such as problem-solving and action planning, are more satised
after the meeting. In addition, team productivity is also associated
with functional interaction.
Using the act4teams coding scheme, Schneider et al. [
9
] investi-
gate the behavior of 155 student software developers in 32 teams
during the rst project meeting. Schneider et al.’s [
9
] results in-
dicate a signicant positive inuence of proactive statements on
group aect, i.e. developers have been more satised after meetings
with a lot of proactive statements. In case of supporting statements,
this eect was even larger.
Oshri et al. [
7
] investigate the relevance of face-to-face meetings
for socialization in globally distributed development teams. They
found meetings to be rather short and with limited space for social
informal exchanges [
7
]. Bless [
1
] presents an experience report
outlining possibilities to have dierent kinds of meetings in dis-
tributed teams including retrospectives and planning pokers. The
author clearly highlights the benets of meetings in distributed
teams, even if only video meetings are possible.
Already in 1992, Olson et al. [
6
] analyzed interactions in design
meetings in development teams. They recorded ten design meetings
in four projects on video and transcribed them afterwards. They
analyzed the meetings using a coding scheme focusing i.a. on activi-
ties for problem-solving and for organizing the project. The authors
developed the coding scheme during the analysis, leading to a total
number of 22 categories including “issue”, “project management”
and “meeting management”. Most of the categories used by Olson
et al. [
6
] can also be found in the act4teams-short coding scheme
we use for our analysis.
In order to facilitate interaction analyses in meetings, Prenner et
al. [
8
] present a simplication of the act4teams coding scheme. The
authors compare the results of the neutral meeting analysis with the
developers’ satisfaction after the meeting and the perceived amount
of shared information during the meeting. The results uncover the
need for a more ne-grained coding scheme of the simplication
of act4teams in order to draw adequate comparisons [8].
This paper presents, to some extend, the results of follow-up
work by Prenner et al. [
8
] by solving the indicated problems and
rening the coding scheme.
3 RESEARCH METHOD
The overall research design is visualized in Figure 1. In this section,
we describe the coding scheme act4teams-short and its applica-
tion in an industrial case study at a project center at Volkswagen
Commercial Vehicles.
3.1 Research Questions and Hypotheses
In order to meet our research goal, we want to answer the following
research questions:
RQ1:
How do software project team members interact in meetings
at early project phases? With this research question, we gain an
overview of the interactions in meetings. Furthermore, due to the
progress of the project, we investigate the changes of meeting
behavior over time. These changes indicate whether there is a need
for interventions or whether the meetings get better over project
duration automatically. In order to answer this research question,
we analyze the meetings with respect to the number of statements
about, i.a., problems, solutions, cooperation, as well as the amount
of destructive and proactive behavior.
RQ2:
Does the team only talk about problems or does it try to solve
them? Problems are often subject of meetings. However, these prob-
lems should not only be named but also arranged, i.e., solved. Con-
sequently, talking about problems should go along with talking
about solutions in a meeting. We assume the following alternative
hypothesis.
H11:
The number of statements about problems is related to the
number of statements about solutions.
However, it does not suce to talk a lot about problems and
solutions. Both should be connected in order to really solve a prob-
lem. Consequently, we expect a relationship between the number
of problem-focused or solution-focused statements and the number
of statements connecting solutions and problems. Consequently,
we assume the following:
H21:
The number of statements that are either related to problems or
to solutions is related to the number of statements connecting problems
and solutions.
3.2 Instrument Development
We base our research on the established coding scheme act4teams
which was developed to analyze interactions in meetings [
4
]. How-
ever, applying this coding scheme is very time-consuming and
requires a lot of knowledge and experience [
8
,
9
]. Therefore, we
developed a simplication of act4teams [
8
] where only events of
interest are coded (selective coding). This coding scheme consisted
of nine categories (result from stage 1 in Fig. 1), namely (1) naming
problems, (2) linking problems, (3) naming solutions, (4) linking
solutions, (5) linking and connecting, (6) counterproductivity, (7)
proactivity, (8) structuring and (9) information sharing [
8
]. We ap-
plied this reduced coding scheme in a case study in three agile
Do You Just Discuss or Do You Solve? Meeting Analysis in a Soware Project at Early Stages ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea
Stage 0: State of Practice act4teams
Established in psychology
Used for interaction analyses in meetings
44 categories
Too complex
No ad-hoc coding
Stage 1: Development of new coding scheme
Data base: 34 meetings of student software
projects, analyzed with act4teams
Identifying the most important categories
Derive a coding scheme with 9 categories
Tailored to software projects
Applicable in software project meetings
By software engineers
In real-time
Stage 2: Refinement of the coding scheme
act4teams-SHORT
Assessment of meeting behavior right
during the meeting
11 categories: (1) naming and (2) linking
problems, (3) naming and (4) linking
solution, (5) linking and connecting, (6)
counterproductivity, (7) proactivity, (8)
structuring, (9) knowledge transfer (10)
giving information, and (11) cooperation
Stage 1.x: Application in Industry
Necessity to divide one category
Information sharing was too coarse
Adding one category
Cooperation
Stage 2.x: Application in Industry
Case study at Volkswagen Commercial
Vehicles
Observing 10 team meetings with
act4teams-SHORT
Figure 1: Overview of the research design
working teams at a large company in Germany working in the eld
of web applications [8] (stage 1.x in Fig. 1).
This case study revealed the need for further adjustments: Due
to the nature of meetings in, e.g., the Scrum framework, which are
mainly used for planning and information exchange, particularly
the latter category occurred very often. Unfortunately, as informa-
tion exchange is very neutral, we cannot draw a lot of conclusions
when having counted this category at a high amount. Therefore,
we decided to dierentiate between information exchange and
knowledge transfer, and distinguish between giving information
and knowledge transfer. Furthermore, we noticed a high amount
of cooperative behavior, namely by praise or approval [
8
]. This
led to a completely new category called cooperation. This way, we
obtained a coding scheme consisting of eleven categories (result of
stage 2 in Fig. 1). This instrument was used in the present study.
Table 1 summarizes and describes the categories.
3.3 Data Collection
The data collection using act4teams-short was part of a case study
we conducted at Volkswagen Commercial Vehicles, which is a large
German company in the automotive domain. In the following, we
describe the case company and the project under investigation as
well as the meetings we observed.
3.3.1 Case Company. Volkswagen Commercial Vehicles has in-
troduced a project center in August 2017 for their Mobile Online
Services (MOD). The name MOD covers all activities related to
online services depending on vehicles. The most relevant project is
called Connect Fleet
1
. Connect Fleet is a mobile eet management
system for medium-sized enterprises with one to fty vehicles. It
enables users and companies to easily monitor their vehicles. For
example, in Connect Fleet the system can record a driver’s logbooks,
fuel logs or statistical reports to present it to the driver itself as
well as to the eet manager. Furthermore, collecting this data en-
ables Volkswagen to provide more complex but benecial services
to their customers. Hence the sub-project Predictive Maintenance
started as a part of Connect Fleet. Predictive Maintenance aims at
developing a method to determine the “health” of a car in real time
1For further information, look at https://connecteet.io/home.
by taking into account the driving behavior including speed, accel-
eration, braking behavior, motor revolutions, motor temperature
and more. By determining the car’s health beforehand, downtimes
can be minimized by informing the eet manager about potential
problems with the car allowing him to intervene.
3.3.2 Data Collection in Meetings. During August and December
2018, we collected data in ten team meetings of the project Predic-
tive Maintenance. In the meetings, the whole team comes together
to exchange information and to discuss the next steps as well as dif-
ferent topics and problems. The regular participants are the product
owner (also moderating the meeting), a data solution architect, two
UX designer, a quality assurance representative, and a hardware
specialist. This meeting is scheduled for one hour and the team is
determined to keep this time limit. The observed meetings had an
average duration of 55 minutes (min: 32min, max: 66min, SD: 10
min). The rst two authors of this paper coded the interactions in
these meetings using a software tool [
8
]. They counted the state-
ments in the meeting per category. The workload of the coding
process were equally divided between the rst and second author.
3.4 Data Analysis
Our data analysis consists of a descriptive analysis by looking at the
occurrences of the dierent categories and a quantitative analysis
by analyzing specic correlations between problem- and solution-
focused statements.
Since the length of the meetings and the number of codes vary,
we perform our analysis using the relative amount of codes, unless
otherwise stated.
3.4.1 Data Aggregation. In order to analyze the data quantitatively,
we aggregated some of the collected data and dened the following
variables. The number of problem-related statements is dened to
be the sum of statements related to category (1) naming problems
and (2) connecting problems. Analogue, the number of solution-
related statements is dened to be the sum of statements related
to category (3) naming solutions and (4) connecting solutions. The
number of statements connecting problems and solutions is given
by the number of statements related to category (5) linking and
interconnections.
ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea J. Klünder et al.
Table 1: Overview of the categories to assess interactions in meetings.
Category Description
(1) Naming problems Identifying/explaining a problem
(2) Linking problems Analyzing problem causes and consequences
(3) Naming solutions Gathering/elaborating solutions
(4) Linking solutions Analyzing requirements for solutions, comparing solutions
(5) Linking and connecting Showing links between problems and solutions
(6) Counterproductivity Backbiting, putting others down, mean remarks, complaining, blaming others, ...
(7) Proactivity Showing interest in ideas, engagement, taking responsibility for ideas/plans
(8) Structuring Prioritizing, procedural suggestions, allocating tasks/roles, summarizing
(9) Giving information Passing on information, giving information with reference to external sources
(10) Knowledge transfer Applying own knowledge to the discussion, explaining information
(11) Cooperation Praising others, thanking others, making an eort to be nice, ...
3.4.2 Descriptive Analysis. For analyzing changes in the occur-
rence of categories, we visualized the collected data as a bar chart
and as a pie chart. This way, we were also able to uncover varia-
tions in the sequence of each category. We interpreted the results
using Kaueld et al.’s [
4
] results on the inuence of each act4teams
category and adjusted them to the context of act4teams-short.
However, this step is part of future work and, at the moment, basi-
cally bases on experience.
3.4.3 Hypotheses Testing. We tested the hypotheses formulated in
Sec. 3.1. In order to identify the appropriate way of investigating on
the hypotheses, we rst applied the Shapiro-Wilk test for normal
distribution [
10
]. In the case of having normally distributed data,
we used Pearson’s correlation coecient
𝑟
to measure the relation
between the two variables. In the case of not normally distributed
data, we calculated Spearman’s 𝜌.
4 RESULTS
To answer RQ1, we performed descriptive analysis as described in
Sec. 3.4.2. RQ2 was answered by testing the hypotheses as presented
in Sec. 3.4.3.
4.1 Research Question 1
Figure 2 summarizes the results of all team meetings. On rst sight,
we see a huge amount of giving information (violet parts in Fig.
2). After a couple of weeks, this amount increases (meetings on
Sep, 05 and Sep, 10). This was a very intense time for the team
which is why all team members did not only meet once a week
but twice. Furthermore, owed by the little communication outside
the meetings, the meetings are meant to be used for information
sharing with the team. As the team does not often communicate
outside the meetings, they share the results of a whole week during
the meeting. As a lot of the results are new information (next to
faced problems), this category is highly present in the meetings.
In particular at the beginning of the project, there is only little
knowledge transfer (dark orange parts in Fig. 2). With an ongoing
project, the amount of this category increases.
Furthermore, we only observe a small amount of structuring
behavior in the meetings (dark blue parts in Fig. 2). Structuring
behavior occurs when somebody leads to meeting back to the in-
tended structure or the focus. However, in the observed meetings,
there was no structure to lead back to. This complicates having a
good and time-boxed meeting.
The amount of counterproductive and proactive behavior is visu-
alized in Fig. 2 (dark green resp. yellow parts) and in Fig. 3. In each
of the meetings, we only observe a small amount of counterproduc-
tive behavior. In particular in early meetings, having little or no
counterproductive behavior facilitates the project start. However,
in the rst two observed meetings, we observe a noticeable amount
of counterproductive behavior. At the beginning of a project, this
amount should be reduced as destructive behavior reduces the trust
between the team members [
4
]. Fortunately, there are some meet-
ings with a lot of proactive behavior which can – to some extent –
balance counterproductive behavior. This amount increases during
the project indicating that team members take responsibility for the
project and its progress. At the beginning of the project, we have
a rather small amount of proactive behavior as the tasks remain
unclear during the meetings: Content-related and process-related
discussions got mixed up during these meetings, resulting in tasks
that remain unclear and vague so that team members cannot take
responsibility for them since they do not know what to do and the
tasks remain undone. Therefore, having clear tasks and a to-do-list
for each team member at the end of a meeting facilitates project
progress. It also supports the next meeting since it can be structured
along the task list.
As visualized in Fig. 2 (red and light orange parts), problems
make up a notable amount of time in most of the meetings. Figure
4 concretises the statements from Fig. 2 by comparing the number
of problems and solutions as well as the connection of both. While
solutions indicate the progress of the project, just naming problems
does not. Expect a few meetings, there is little variance in the
number of statements concerning problems over time. Furthermore,
we often have a rather small amount of solutions indicating that
the problems are discussed and explained, but remain unsolved.
The evolution of problems can be explained by the still early
project phase. A lot of unexpected problems occur that need to
be discussed in order to continue working. At this project stage,
talking about problems is not necessarily bad. However, talking a
Do You Just Discuss or Do You Solve? Meeting Analysis in a Soware Project at Early Stages ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea
0,0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1,0
08.08. 22.08. 29.08. 05.09. 10.09. 26.09. 10.10. 14.11. 21.11. 07.12.
Relative frequencies
of the categories
Date of the observed meeting
Cooperation
Giving information
Knowledge transfer
Structuring
Proactivity
Counterproductivity
Linking and connecting
Linking solutions
Naming solutions
Linking problems
Naming problems
Figure 2: Overview of interactions in all team meetings
0
0,02
0,04
0,06
0,08
0,1
0,12
08.08. 22.08. 29.08. 05.09. 10.09. 26.09. 10.10. 14.11. 21.11. 07.12.
Relative frequencies
of the categories
Date of the observed meeting
Counterproductivity
Proactivity
Figure 3: Frequencies of counterproductive and proactive
statements in the observed meetings
0
0,05
0,1
0,15
0,2
0,25
0,3
0,35
0,4
0,45
08.08. 22.08. 29.08. 05.09. 10.09. 26.09. 10.10. 14.11. 21.11. 07.12.
Relative frequencies
of the categories
Date of the observed meeting
Problems
Solutions
Linking & Connecting
Figure 4: Frequency of statements about problems, solutions
and connections between both in the meetings
lot about problems without solving them usually has a negative
inuence on the team members’ satisfaction and mood.
4.2 Research Question 2
Before testing hypothesis H1, we ensured having normally dis-
tributed data. Applying the Shapiro-Wilk test for normal distri-
bution to both data sets of problem-focused and solution-focused
statements justied the use of Pearson’s R (
𝑊=
0
.
90382,
𝑝=.
24120
for problem-focused statements and
𝑊=
0
.
94206
, 𝑝 =.
57616 for
solution-focused statements)
2
. Calculating the Pearson correlation
between both variables shows a strong positive relationship be-
tween problems and solutions which is signicant at a signicance
level of
𝑝
0
.
05 (
𝑅=
0
.
7862,
𝑝=.
006999), leading to a rejection of
H1
0
. Consequently,
there is a correlation between the number
of problem-related and solution-related statements.
To test hypothesis H2, we ensured that the variable for linking
and interconnections is also normally distributed. Shapiro-Wilk
refutes the assumption of having normally distributed data (
𝑊=
0.67102,𝑝=.00039).
As the variable given by the number of links and connections
between problems and solutions is not normally distributed, we
calculated Spearman’s
𝜌
to analyze the relationship between all
statements on solutions and problems and the number of statements
connecting these statements (H2). A value of
𝜌=
0
.
51702 supports
the assumption of having at least a weak relationship between
these kinds of statements. This result is signicant (
𝑝
(2-tailed)
=
0
.
01958). Thus,
the team does not only talk about problems
and solutions but also interrelates them with each other.
5 DISCUSSION
We discuss our ndings with respect to the research questions,
the threats to validity and derive some lessons learned to support
software projects at early stages.
5.1 Answers to the Research Questions
In order to assess interactions in team meetings of software projects
at early stages, we formulated two research questions. These can
be answered as follows:
RQ1: Most of the time in the observed team meetings at Volkswa-
gen Commercial Vehicles was used for information exchange. The
identication of problems, discussing solutions and nally solving
problems also takes a lot of time in the meetings. Knowledge trans-
fer, structuring, and counterproductivity only take a little amount
2
We veried these results using two other tests for normal distribution (Kolmogorow-
Smirnow test and Anderson-Darling test) as well as the graphical visualisization of
the data, all supporting the statement of having normally distributed data.
ICSEW’20, Oct 5–11, 2020, Seoul, Republic of Korea J. Klünder et al.
of time in the meetings. Proactive behavior is also rather absent
during the meetings.
RQ2: Our results reveal a positive correlation between the num-
ber of statements about problems and solutions as well as a (weak)
correlation with the connection and linking with each other. Conse-
quently, the team does not only talk about problems but also talks
about how these problems can be solved: The more problems are
mentioned during the meeting, the more the team also talks about
solutions. The team started to work on solutions right from the
start of the project and did not just pile problems. The implication
is that other teams at an early project phase should show a simi-
lar behavior. Manager who observe that their team is just piling
problems without discussing their solutions, should fast intervene
because it indicates that something is going wrong in the team.
5.2 Limitations and Threats to Validity
The results of our case study are subject to some limitations that
threaten their validity and their generalizability.
The database for the analysis consists of 10 team meetings from
project start. This limits the statistical power of our ndings. How-
ever, since we wanted just to observe the team during the early
project phase, we consider this amount as sucient. Further, errors
in the coding process (e.g., due to misinterpreted categories) may
lead to wrong results. We addressed this threat by choosing two
experienced researcher with the use of act4teams-short.
Two researchers themselves have been present during data col-
lection. This can aect the results due to the Hawthorne eect.
In order to reduce the inuence on the meeting behavior of the
participants, we integrated the analyses in a long-term cooperation
between the Leibniz University Hannover and Volkswagen Com-
mercial Vehicles. The researchers visited the project center various
times before the data collection. Furthermore, the participants were
assured that we collect the data completely anonymized.
To ensure the reliability of the collected data (i.e., independence
of the researchers), we also calculated the interrater reliability,
namely the intraclass correlation coecient (ICC), of the two re-
searchers in one meeting. Obtaining an ICC of 0
.
86, which is almost
perfect according to Cicchetti [2] reduces the risk of this threat.
We analyzed 10 meetings to reduce the mono-operation bias.
However, only applying a single method to analyze the meetings,
reduces the reliability of the results due to the mono-method bias. Un-
fortunately, it was not possible to compare the results of act4teams-
short with the results of, e.g., act4teams, because we were not
allowed to video-record the meetings and act4teams is not applica-
ble in a live setting.
In this case study, we only observed meetings in one specic
team over a project period of four months. This decreases the gen-
eralizability of our results. In order to obtain more generalizable
results, this study should be repeated in other contexts. Further
research is required to support our results or to concretize them.
Even though other teams at early project stages may behave dier-
ently, we observed a team that shows a possible behavior during
the project. We expect other teams at early project stages to show
a similar behavior.
6 CONCLUSION
Meetings are a very important part of software projects. In par-
ticular at early project stages, most communication takes part in
meetings. However, these meetings are often not as eective and
as productive as expected, leading to dissatised software project
teams and demotivation. Assessing interactions in meetings can
help to reduce inappropriate behavior in meetings such as complain-
ing or losing the train of thoughts. act4teams-short is a coding
scheme enabling software engineers to assess this kind of inter-
actions in meeting. This way, the team gets an overview of its
behavior in meetings.
In a case study at Volkswagen Commercial Vehicles, we analyzed
ten team meetings at early stages in one project. Our results indi-
cate that the meetings are a very important medium to transport
information and to talk about problems. In addition, the number
of statements about problems is positively linked to the number of
statements about solutions and that both of them are connected.
In future work, we plan to extend our results and to increase their
reliability by conducting more case studies in other project teams,
at dierent project stages, and in other companies. In addition, we
plan to develop patterns that show which amount of behavior of
which category should occur during a meetings in dependence from
the intended outcome of the meeting.
ACKNOWLEDGMENTS
This work was funded by the German Research Foundation (DFG)
under grant number 263807701 (Project TeamDynamics, 2018-2020).
We also thank the team at Volkswagen Nutzfahrzeuge for partici-
pating in our case study.
REFERENCES
[1]
Marc Bless. 2010. Distributed meetings in distributed teams. In International
Conference on Agile Software Development. Springer, 251–260.
[2]
Domenic V Cicchetti. 1994. Guidelines, criteria, and rules of thumb for evaluating
normed and standardized assessment instruments in psychology. Psychological
assessment 6, 4 (1994), 284.
[3]
Daniel Graziotin, Fabian Fagerholm, Xiaofeng Wang, and Pekka Abrahamsson.
2017. Unhappy developers: Bad for themselves, bad for process, and bad for
software product. In 2017 IEEE/ACM 39th International Conference on Software
Engineering Companion (ICSE-C). IEEE, 362–364.
[4]
Simone Kaueld and Nale Lehmann-Willenbrock. 2012. Meetings matter: Eects
of team meetings on team and organizational success. Small Group Research 43,
2 (2012), 130–158.
[5]
Simone Kaueld and Renee A Meyers. 2009. Complaint and solution-oriented
circles: Interaction patterns in work group discussions. European Journal of Work
and Organizational Psychology 18, 3 (2009), 267–294.
[6]
Gary M Olson, Judith S Olson, Mark R Carter, and Marianne Storrosten. 1992.
Small group design meetings: An analysis of collaboration. Human–Computer
Interaction 7, 4 (1992), 347–374.
[7]
Ilan Oshri, Julia Kotlarsky, and Leslie P Willcocks. 2007. Global software develop-
ment: Exploring socialization and face-to-face meetings in distributed strategic
projects. The Journal of Strategic Information Systems 16, 1 (2007), 25–49.
[8]
Nils Prenner, Jil Klünder, and Kurt Schneider. 2018. Making meeting success
measurable by participants’ feedback. In Proceedings of the 3rd International
Workshop on Emotion Awareness in Software Engineering. ACM.
[9]
Kurt Schneider, Jil Klünder, Fabian Kortum, Lisa Handke, Julia Straube, and
Simone Kaueld. 2018. Positive aect through interactions in meetings: The role
of proactive and supportive statements. Journal of Systems and Software 143
(2018), 59–70.
[10]
Samuel Sanford Shapiro and Martin B Wilk. 1965. An analysis of variance test
for normality (complete samples). Biometrika 52, 3/4 (1965), 591–611.
... This application to meetings was motivated by the huge amount of communication in software project meetings, despite the frequent use of text-based communication channels. Although research has found meeting analysis to be of particular importance [48,28], there was, to the best of our knowledge, so far no attempt to apply sentiment analysis in meetings. In a first attempt to close this gap, we developed a tool, the so-called SEnti-Analyzer, which transcribes the statements made in a meeting in real-time and applies existing sentiment analysis tools to the statements. ...
... Klünder et al. [28] elaborate the coding scheme act4teams-SHORT, which they derived from an established interaction analysis scheme in psychology. Using act4teams-SHORT, statements in a meeting can be categorized in one of eleven different categories such as "naming problems" or "giving information". ...
... Using act4teams-SHORT, statements in a meeting can be categorized in one of eleven different categories such as "naming problems" or "giving information". According to the results of Klünder et al. [28], using this coding scheme and analyzing the resulting interactions in each category help identifying possible problematic behavior. Resolving this kind of behavior at early stages of a software project can lead to better overall team performance and project success [28]. ...
Preprint
Social aspects in software development teams are of particular importance for a successful project closure. To analyze sentiments in software projects, there are several tools and approaches available. These tools analyze text-based communication based on the used words to predict whether they appear to be positive, negative, or neutral for the receiver of the message. In the research project ComContA, we investigate so-called sentiment analysis striving to analyze the content of text-based communication in development teams with regard to the statement's polarity. That is, we analyze whether the communication appears to be adequate (i.e., positive or neutral) or negative. In a workshop paper, we presented a tool called SEnti-Analyzer that allows to apply sentiment analysis to verbal communication in meetings of software projects. In this technical report, we present the extended functionalities of the SEnti-Analyzer by also allowing the analysis of text-based communication, we improve the prediction of the tool by including established sentiment analysis tools, and we evaluate the tool with respect to its accuracy. We evaluate the tool by comparing the prediction of the SEnti-Analyzer to pre-labeled established data sets used for sentiment analysis in software engineering and to perceptions of computer scientists. Our results indicate that in almost all cases at least two of the three votes coincide, but in only about half of the cases all three votes coincide. Our results raise the question of the "ultimate truth" of sentiment analysis outcomes: What do we want to predict with sentiment analysis tools? The pre-defined labels of established data sets? The perception of computer scientists? Or the perception of single computer scientists which appears to be the most meaningful objective?
... There are other attempts to analyze interactions in meetings, including a coding scheme adjusted for software projects [8], [9], but these methods still require manual effort leading to subjective results. ...
... Meeting analysis and sentiment analysis have both been frequently applied to software projects. For example, Klünder et al. [9] elaborate the coding scheme act4teams-SHORT, which they derived from an established interaction analysis scheme in psychology. Using act4teams-SHORT, statements in a meeting can be categorized in one of eleven different categories such as "naming problems" or "giving information". ...
... Using act4teams-SHORT, statements in a meeting can be categorized in one of eleven different categories such as "naming problems" or "giving information". According to the results of Klünder et al. [9], using this coding scheme and analyzing the resulting interactions in each category help identifying possible problematic behavior. Resolving this kind of behavior at early stages of a software project can lead to better overall team performance and project success [9]. ...
Preprint
Sentiment analysis gets increasing attention in software engineering with new tools emerging from new insights provided by researchers. Existing use cases and tools are meant to be used for textual communication such as comments on collaborative version control systems. While this can already provide useful feedback for development teams, a lot of communication takes place in meetings and is not suited for present tool designs and concepts. In this paper, we present a concept that is capable of processing live meeting audio and classifying transcribed statements into sentiment polarity classes. We combine the latest advances in open source speech recognition with previous research in sentiment analysis. We tested our approach on a student software project meeting to gain proof of concept, showing moderate agreement between the classifications of our tool and a human observer on the meeting audio. Despite the preliminary character of our study, we see promising results motivating future research in sentiment analysis on meetings. For example, the polarity classification can be extended to detect destructive behaviour that can endanger project success.
... However, the application of the concept from psychology is time-consuming and requires profound knowledge that requirements engineers typically do not have [4]. Therefore, based on act4teams [6], we iteratively developed a coding scheme for interaction analysis in software project meetings [3], [7]. The resulting approach, act4teams-SHORT, allows software or requirements engineers to objectively analyze interactions in meetings in software projects. ...
... By applying act4teams-SHORT, it is possible to get a general overview of the interactions in a meetings. The results of a meeting analysis in a project in industry (cf. [7]) are visualized in Fig. 1. However, it is difficult to generalize which amount of the specific statements should be seen as a warning sign or which amount of different interactions a team should strive for [6]. ...
... Identifying these factors will be part of future research, but not presented in this vision paper. [7] Category Description (1) Naming problems Identifying/explaining a problem (2) Linking problems Analyzing problem causes and consequences (3) Naming solutions Gathering/elaborating solutions (4) Linking solutions Analyzing requirements for solutions, comparing solutions (5) Linking and connecting Showing links between problems and solutions (6) Counterproductivity Backbiting, putting others down, mean remarks, complaining, blaming others, ... (7) Proactivity Showing interest in ideas, engagement, taking responsibility for ideas/plans (8) Structuring Prioritizing, procedural suggestions, allocating tasks/roles, summarizing (9) Giving information Passing on information, giving information with reference to external sources (10) Knowledge transfer Applying own knowledge to the discussion, explaining information (11) Cooperation Praising others, thanking others, making an effort to be nice, ... ...
Conference Paper
Full-text available
In Requirements Engineering, a lot of communication takes place in conversations and meetings, such as workshops, focus groups, interviews, and review sessions. Research has shown that interactions in meetings influence the group affect after the meeting-and hence the participants' motivation for (further) contributing to the project. However, it remains unclear, how positive affect can be achieved. In this vision paper, we propose to analyze interactions in meetings to find relations between the participants' behavior and affect afterwards. This allows to identify "good" behavior in meetings to smooth the way to satisfied project team members and successful projects.
... This, in turn, has an influence on the project and the collaboration. To avoid inappropriate behavior in meetings, interaction analyses are an established medium in psychology [13,19] and gain increasing attention in software engineering [15,24,26]. ...
... This, in turn, influences the developers' productivity [8] and has several other consequences for the project [7]. Therefore, interaction analyses in meetings take into account the amount of positive, i.e., good and appropriate, as well as negative, i.e., bad and inappropriate, behavior during the meetings [13,15]. Since the frequency and duration of meetings tend to decrease with project progress, whereas the use of other communication channels increases [16], likely, the communication behavior in text messages can also influence team satisfaction and, thus, motivation and project progress. ...
Chapter
Software development encompasses many collaborative tasks in which usually several persons are involved. Close collaboration and the synchronization of different members of the development team require effective communication. One established communication channel are meetings which are, however, often not as effective as expected. Several approaches already focused on the analysis of meetings to determine the reasons for inefficiency and dissatisfying meeting outcomes. In addition to meetings, text-based communication channels such as chats and e-mails are frequently used in development teams. Communication via these channels requires a similar appropriate behavior as in meetings to achieve a satisfying and expedient collaboration. However, these channels have not yet been extensively examined in research.
... This, in turn, has an influence on the project and the collaboration. To avoid inappropriate behavior in meetings, interaction analyses are an established medium in psychology [13,19] and gain increasing attention in software engineering [15,24,26]. ...
... This, in turn, influences the developers' productivity [8] and has several other consequences for the project [7]. Therefore, interaction analyses in meetings take into account the amount of positive, i.e., good and appropriate, as well as negative, i.e., bad and inappropriate, behavior during the meetings [13,15]. Since the frequency and duration of meetings tend to decrease with project progress, whereas the use of other communication channels increases [16], likely, the communication behavior in text messages can also influence team satisfaction and, thus, motivation and project progress. ...
Conference Paper
Software development encompasses many collaborative tasks in which usually several persons are involved. Close collaboration and the synchronization of different members of the development team require effective communication. One established communication channel are meetings which are, however, often not as effective as expected. Several approaches already focused on the analysis of meetings to determine the reasons for inefficiency and dissatisfying meeting outcomes. In addition to meetings, text-based communication channels such as chats and e-mails are frequently used in development teams. Communication via these channels requires a similar appropriate behavior as in meetings to achieve a satisfying and expedient collaboration. However, these channels have not yet been extensively examined in research. In this paper, we present an approach for analyzing interpersonal behavior in text-based communication concerning the conversational tone, the familiarity of sender and receiver, the sender's emotionality, and the appropriateness of the used language. We evaluate our approach in an industrial case study based on 1947 messages sent in a group chat in Zulip over 5.5 months. Using our approach, it was possible to automatically classify written sentences as positive, neutral, or negative with an average accuracy of 62.97% compared to human ratings. Despite this coarse-grained classification, it is possible to gain an overall picture of the adequacy of the textual communication and tendencies in the group mood.
Article
Full-text available
This study follows the idea that the key to understanding team meeting effectiveness lies in uncovering the microlevel interaction processes throughout the meeting. Ninety-two regular team meetings were videotaped. Interaction data were coded and evaluated with the act4teams coding scheme and INTERACT software. Team and organizational success variables were gathered via questionnaires and telephone interviews. The results support the central function of interaction processes as posited in the traditional input-process-output model. Teams that showed more functional interaction, such as problem-solving interaction and action planning, were significantly more satisfied with their meetings. Better meetings were associated with higher team productivity. Moreover, constructive meeting interaction processes were related to organizational success 2.5 years after the meeting. Dysfunctional communication, such as criticizing others or complaining, showed significant negative relationships with these outcomes. These negative effects were even more pronounced than the positive effects of functional team meeting interaction. The results suggest that team meeting processes shape both team and organizational outcomes. The critical meeting behaviors identified here provide hints for group researchers and practitioners alike who aim to improve meeting success.
Article
Full-text available
The development of schemes to support group work, whether behavioral methods or new technologies like groupware, should be based on detailed knowledge about how groups work, what they do well, and what they have trouble with. Such data can be used to suggest what kinds of tools people might need as well as to provide a baseline for evaluating the effects of schemes for improvement. We present details of how real groups engage in a representative collaborative task- early software design meetings- to provide such knowledge. We studied 10 design meetings from four projects in two organizations. The meetings were videotaped, transcribed, and then analyzed using a coding scheme that looked at participants ' problem solving and the activities they used to coordinate and manage themselves. We also analyzed the structure of their design arguments. We found, to our surprise, that although the meetings differed in how many issues were covered they were strikingly similar in both how people spent their time and in the sequential
Article
Full-text available
In the context of the development of prototypic assessment instruments in the areas of cognition, personality, and adaptive functioning, the issues of standardization, norming procedures, and the important psychometrics of test reliability and validity are evaluated critically. Criteria, guidelines, and simple rules of thumb are provided to assist the clinician faced with the challenge of choosing an appropriate test instrument for a given psychological assessment. (PsycINFO Database Record (c) 2012 APA, all rights reserved)
Article
Software projects are dominated by meetings. For participants, not all meetings are useful and enjoyable. However, interaction within a meeting has an impact on individual and group affects. Group affect influences team performance and project success. Despite frequent yet vague dissatisfaction with some meetings, many software engineers are not aware of the crucial importance of their behavior in those meetings. This can set the tone for the entire project. By influencing group affect, meeting interaction influences success without participants even noticing. Due to this lack of awareness, it depends on good or bad luck whether software teams will adopt a promising meeting style. In a study of 32 student projects with 155 participants, we coded fine-grained interaction elements during the first internal meeting of each team. The analysis of resulting codes showed that constructive remarks had a positive impact on positive group affect tone (PGAT). However, this effect was only observed when constructive remarks were followed by supportive utterances. We were able to show a complete mediation of this statistically significant effect. Seemingly subtle behavior patterns influence group affect. Software projects could significantly benefit from supportive meeting behavior. We propose practical interventions to improve meeting quality.
Article
The study investigates interaction patterns in work group discussions, focusing specifically on complaining and solution-oriented statements. Thirty-three work group discussions in three German industrial enterprises were coded with the Cassel Competence Grid (CCG). Lag sequential analysis results showed that complaining begets further complaining statements, while simultaneously inhibiting the expression of solution-oriented statements. Likewise, when solutions are proposed they are followed by further discussion of solutions. If support is expressed for either complaint or solution statements, circles of these two types of interaction arise. To inhibit complaining, the results point to the importance of structuring statements.
Article
Socialization is one means through which globally distributed teams (GDTs) can improve collaboration. However, harnessing socializing processes to support globally distributed collaboration is not easy. In particular, infrequent and limited face-to-face (F2F) contact between remote counterparts might result in difficulties in sharing norms, attitudes and behaviours. In this paper we seek to understand how dispersed teams create socialization in globally distributed settings. Based on data collected at SAP, LeCroy and Baan we conclude that, while F2F meetings are important in socializing remote counterparts, other activities and processes employed before and after F2F meetings are no less important. In particular, the paper highlights the importance of re-socializing remote counterparts throughout a project lifecycle. Re-socializing means supporting the re-acquisition of behaviours, norms and attitudes that are necessary for participation in an organization. We offer a framework in which three phases of creating, maintaining and renewing socialization in GDTs are discussed. The paper concludes by offering managers some guidelines concerning socialization in GDTs.
Conference Paper
Emails and phone calls are insufficient and most inefficient for distributed communication and meetings. It is impossible to let a team improve by these means. This experience report presents how we dealt with the lack of communication in a distributed Scrum Team in three locations and two different time zones. We created a virtually colocated team by using video conferencing systems even for daily meetings and remote desktop systems for handling documents and tools. With such systems all necessary meetings and practices can be executed. It is even possible to support highly collaborative sessions like planning poker, pair programming, and retrospectives. The necessary budget to set up such systems is outweighed by the obtained effectiveness and efficiency of team communication.