Conference PaperPDF Available

Human Factors and their Influence on Software Development Teams - A Tertiary Study

Authors:

Figures

Content may be subject to copyright.
Human Factors and their Influence on Soware Development
Teams - A Tertiary Study
Eliezer Dutra
UNIRIO
CEFET/RJ
Rio de Janeiro, RJ, Brazil
eliezer.goncalves@cefet-rj.br
Bruna Diirr
UNIRIO
Rio de Janeiro, RJ, Brazil
bruna.diirr@uniriotec.br
Gleison Santos
UNIRIO
Rio de Janeiro, RJ, Brazil
gleison.santos@uniriotec.br
ABSTRACT
Background:
Software organizations increasingly need developers
with high skills for social interactions. Managers, leaders, and aca-
demics need to know the human factors inuencing the individuals,
the development team, and the software project activities. Despite
the increasing number of secondary studies about human factors
in Software Engineering (SE) and in Agile Software Development
(ASD), there is no study synthesizing which human factors inu-
ence software development without a specic perspective from
SE or human factor thematic.
Objective:
We aim to summarise hu-
man factors and their inuence on SE development teams and
ASD teams.
Method:
We executed a tertiary study. We used the-
matic analysis to examine the resulting data.
Results:
We found
29 systematic literature reviews and systematic mapping studies
addressing the human perspective in SE teams. We identied 101
human factors and 79 inuences grouped in 4 categories (Team
member, Team, Project, and Organization). Also, we identied 71
human factors and 60 inuences on ASD. The most investigated
human factors are Communication, Collaboration, Knowledge, and
Motivation.
Conclusions:
The identied human factors and their
inuences can be considered most signicant by software organi-
zations, researchers, and academics in SE practices. Based on our
results, practitioners might propose activities that enhance human
capital behaviors that inuence individual motivation, agile mind-
set, team climate, software quality, or agile transition in traditional
organizations.
CCS CONCEPTS
Software and its engineering Programming teams
;
Agile
software development.
KEYWORDS
Tertiary study, Human Factor Inuence, Software Engineering
ACM Reference Format:
Eliezer Dutra, Bruna Diirr, and Gleison Santos. 2021. Human Factors and
their Inuence on Software Development Teams - A Tertiary Study. In
Permission to make digital or hard copies of all or part of this work for personal or
classroom use is granted without fee provided that copies are not made or distributed
for prot or commercial advantage and that copies bear this notice and the full citation
on the rst page. Copyrights for components of this work owned by others than the
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or
republish, to post on servers or to redistribute to lists, requires prior specic permission
and/or a fee. Request permissions from permissions@acm.org.
SBES ’21, September 27-October 1, 2021, Joinville, Brazil
©2021 Copyright held by the owner/author(s). Publication rights licensed to ACM.
ACM ISBN 978-1-4503-9061-3/21/09.. .$15.00
https://doi.org/10.1145/3474624.3474625
Brazilian Symposium on Software Engineering (SBES ’21), September 27-
October 1, 2021, Joinville, Brazil. ACM, New York, NY, USA, 10 pages. https:
//doi.org/10.1145/3474624.3474625
1 INTRODUCTION
Organizations, academics, and researchers in the software devel-
opment area increasingly need to have a broad knowledge of the
human capital involved in Software Engineering (SE) activities.
After all, software is developed by humans, read by humans, and
maintained by humans [
8
]. Practitioners must know and enhance
human factors that inuence the software development team mem-
bers, the team activities, and, consequently, the product quality
[
13
,
43
]. However, sometimes human factors do not receive the
same attention as technical factors by managers, team members,
and academics in SE [20, 35].
The term human factor (HF) represents a person’s physical or
cognitive feature, or social behavior [
25
]. Human factors are often
denominated in dierent ways, such as soft factors, human aspects,
social factors, or non-technical factors. We use the term human
factor because it allows the binding identication of behaviors,
sentiments, or attitudes in the software development team member,
the team, and other organizational roles. Human factors have been
extensively studied and expressed through personality, cognition,
motivation, communication, cohesion, and the decision-making of
the developers in carrying out their activities [31].
Most Systematic Literature Reviews (SLR) and Systematic Map-
ping Studies (SMS) regarding human factors in SE have a specic
perspective for a development process (e.g., Agile Software Devel-
opment (ASD) [
10
]), an inuence on the particular human topic
(e.g., motivation [
7
]) or SE topic (e.g., software quality [
23
] and team
productivity [
9
]), or specic research methodology (e.g., empirical
studies [
17
]). Concerning the growing use of agile methods and the
amount of published research, Ahmed et al. [
1
] claim that sooner or
later, agile methodologies will become the most adopted techniques
globally, and there is a need to systematize existing knowledge in
the ASD area. A way to systematize such knowledge is by perform-
ing a tertiary study to provide an overview on how human factors
aect SE and ASD. A tertiary study is a systematic investigation
that involves a review of existing secondary studies (such as SLR
and SMS) that is expected to answer broader research questions
[
29
]. We did not nd a tertiary study that summarizes the human
factors inuences on software development activities without de-
limiting a specic theme (such as motivation or decision-making)
or perspective (i.e., team roles or project activities).
This study aims to elicit human factors and their inuence on SE
development teams and in ASD teams in particular. To achieve this
SBES ’21, September 27-October 1, 2021, Joinville, Brazil Dutra et al.
goal, we executed a tertiary study. The main contribution of this
paper is oering a comprehensive overview of the human factors
and their inuence on SE. We expect the results to sensibilize man-
agers, leaders, and academics to propose actions that corroborate
the establishment of more healthy social interactions. Fostering
these social interactions can increase motivation, recognition, and
satisfaction in the software engineers, besides contributing directly
to increase the team productivity and the quality of the software
developed.
The paper is organized as follows: Section 2 details the study
planning and execution; in Section 3, we present the results and
discuss them in Section 4; Section 5 addresses limitations and threats
to validity; nally, Section 6 presents our nal considerations.
2 METHOD
This tertiary study uses the same methodology of SLR and SMS, fol-
lowing the guidelines proposed by [
28
,
38
]. We devised the protocol
based on both guidelines and an exemplary tertiary study [29].
2.1 Research questions, inclusion/exclusion
criteria, and the search string
To achieve the objective described in the introduction, the search
questions (RQ) were dened as follows:
RQ1. Which human factors are investigated?
RQ2. How do human factors inuence software development?
RQ3. How do human factors inuence Agile Software Develop-
ment?
A broad inclusion criterion was dened in the scope of the tertiary
study: SLR/SMS must investigate human factors that aect software
development teams. We also dened 8 exclusion criteria to ensure
the quality of the ndings, which are: Written in a language other
than English; Duplicates; Outside Computer Science area; Not peer-
reviewed; Not accessible; Research Proposal; SLR/SMS that present
results from another SLR/SMS identied in this tertiary study and
do not report new human factor or inuence; and SLR/SMS that do
not meet the inclusion criteria. To capture the largest number of
studies, an initial period was not dened in the exclusion criteria.
Before executing the tertiary study, we searched Scopus and
Compendex for other studies with similar goals. Through this non-
systematic literature review, we identied the two control studies
(i.e., [
10
,
11
]) and several synonyms to the terms used in the search
string (e.g., [
10
,
11
,
24
]). Based on the study goal, we derived the
rst version of the search string containing the terms human factor,
systematic literature review, Software Engineering, and teams. After
several tests, the canonical search expression was dened as:
(("human factor*" OR "human aspect*" OR "social factor*" OR
"behavior*" OR "skill*" OR "soft factor*" OR "non-technical factor"
OR "personality" OR "attitude*") AND ("systematic review" OR
"systematic literature review" OR "systematic map" OR "systematic
mapping" OR "mapping study") AND (("software engineering" OR
"software development" OR "software system*" OR "software life
cycle" OR "software process" OR "software maintenance" OR
"software project*") OR ("software developer*" OR "software
professional*" OR "software engineer*") OR ("software team*" OR "SE
team*" OR "IS team*" OR "programming team*" OR "team project*"
OR "project team*")))
2.2 The search process and study selection
After the approval of the protocol, we performed the search on
selected search engines. For each search engine, the string was
adapted and executed. The results were recorded and analyzed in a
Google Sheets spreadsheet. The spreadsheet with the full protocol
and all the steps and extractions performed can be found at https:
//doi.org/10.6084/m9.gshare.14572365.v1.
The selection of papers was executed using two lters. In the
rst lter, the title, abstracts, and keywords were read. For each
study, the considered exclusion or inclusion criteria were indicated.
Each study was evaluated by both the rst and the third authors
independently. Comments were recorded and analyzed in case of
divergence of the criteria used by each researcher. In the second l-
ter, the rst author read the papers’ full-text. Studies were included
if they met one of the inclusion criteria, or excluded if they met
specic exclusion criteria. This study was planned and executed
from October 2018 to March 2021. We searched the online databases
in Nov/2018, May/2020, and Jan/2021. We performed snowballing
in Mar/2021. The results cover publications until the year 2020.
The search and analysis of results were executed in two phases, as
depicted in Fig. 1.
Phase 1:
We run the search expression in the most used online
databases for software engineering, i.e., IEEEXplore, Scopus, En-
gineering Village, and ISI Web of Science [
24
]. In the rst lter,
364 documents were analyzed, and 320 studies were rejected. To
apply the second lter, 44 full-text studies were read. In the end,
we identied 23 SLR/SMS.
Phase 2:
In this phase, we performed a forward snowballing
using as seeds the 23 SLR/SMS identied in Phase 1 using Google
Scholar. We limited the results to the rst 100 studies referencing
each SLR/SMS. In total, other 724 documents were scrutinized by
applying the inclusion and exclusion criteria in the two lters. In
the end, we identied 6 new relevant SLR/SMS.
Figure 1: Phases to SLR/SMS selection
Human Factors and their Influence on Soware Development Teams - A Tertiary Study SBES ’21, September 27-October 1, 2021, Joinville, Brazil
2.3 Extraction and analysis
We used the spreadsheet mentioned above to collect the information
needed to address the quality criteria and research information
(references, search string, and research in human and ES topic).
According to Kitchenham and Brereton [
28
], quality assessment
is important to classify the articles for review studies. Table 1
presents the questions and quality criteria considered. The rst
four were based on [
29
]. The quality score was only informative.
No SLR/SMS were excluded.
Thematic analysis was used to identify the human factors and
their inuences [
12
]. We used ATLAS.ti as a supporting tool. The
rst author identied the codes associated with the origin text.
To analyze the human factors inuences, the rst author dened
categories to group similar codes. All codes and categories were
discussed, revised, and audited by the third author. Examples of the
coding process are presented in Section 3.
Table 1: Questions and quality criteria
Question Criteria Quality (Points)
Are the inclusion (IC) and
exclusion criteria (EC) de-
scribed and appropriate?
IC and EC are explicit (1); IC and EC are
implicit (0.5); IC and EC are not dened
and cannot be readily inferred (0)
Is the literature search
likely to have covered all
relevant studies?
The search covered more than 4 bases
plus an additional search strategy (1); The
search covered 3 to 4 bases (0.5); The
search covered 2 bases or a restricted set
of journals (0)
Did the research ques-
tions involve quality is-
sues that are addressed by
the study?
The use of quality criteria is reported (1);
The research questions mention quality
aspects (0.5); No (0);
Were the base studies ade-
quately described?
Relevant data from each selected paper is
presented (1); Human factors are grouped
for analysis (0.5); Primary studies are not
detailed (0)
Were the results analyzed
critically?
The results were compared with other
studies (1); Few results were discussed
(0.5); No (0)
3 RESULTS
Table 2 summarizes the 29 selected SLR/SMS, including their quality
score and the SE topics investigated. The most investigated “Human
Topic” in the selected studies were Personality and Motivation. Each
topic is the subject of ve studies. Seven studies approach dozens
of human factors in the perspective of “Individual Factors” and
“Human Aspects.” The other “Human Topics” are examined from
dierent perspectives for eective use in ASD, such as Capability
[
45
], Sustainability [
41
], Diversity [
30
], Human Challenges [
42
],
Human Factor [10], and Mindset [37].
Motivation [
1
,
2
,
7
,
15
,
21
] and Personality [
4
,
5
,
11
,
22
,
44
] were
the main research topic in ten studies. Beecham et al. [
7
] analyze
that Motivation is dicult to measure. Besides, learning, exploring
new techniques, and problem-solving appear to be motivating as-
pects in SE [
7
]. Cruz et al. [
11
] state that Personality is generally
seen through the person’s behaviors, thoughts, and feelings. In gen-
eral, the studies aim to assess the Personality type preferences for
team roles or in software development activities. The Myers–Briggs
Type Indicator (MBTI), a questionnaire that indicates dierent traits
of personality, was the most used test [11].
Table 2: Summary of the identied SLR/SMS
Study Human Topic Software Engineering
Topic
Quality
Score
[45] Capability ASD 5
[3] Communication SE; GSD 5
[17] Critical Factors ASD 5
[27] Decision-making Software Project 3.5
[33] Diversity SE 2.5
[30] Diversity ASD 3.5
[40] Emotional SE 5
[9] Human Aspects SE; Productivity 3
[39] Human Aspects ASD 2.5
[42] Human Challenges ASD; GSD 5
[10] Human Factor ASD 5
[18] Human Factor SE; Code Review 3.5
[36] Human Factor SE; Productivity 3.5
[23] Human Factor Software Quality 3
[19] Individual Factor Modern Code Review 4,5
[26] Knowledge sharing SE 3.5
[37] Mindset ASD 3
[15] Motivation ASD; Productivity 3.5
[21] Motivation SE 5
[7] Motivation SE 5
[1] Motivation ASD 4
[2] Motivation ASD 4
[5] Personality SE 5
[22] Personality SE 4.5
[4] Personality Requirement Engineering 3
[44] Personality Performance 5
[11] Personality SE 5
[14] Sentiment Software Practice; Artifacts 2.5
[41] Sustainability ASD 4.5
In recent years, the academy’s interest in deepening studies
on the inuence of Emotion [
14
,
40
] and Diversity [
30
,
33
] in the
development team has been observed. Sánchez-Gordón and Colomo-
Palacios [
40
] identied 40 emotions investigated in team members,
e.g., anger, fear, disgust, sadness, joy, love, and happiness. Diversity
in the SE presents multiple dimensions regarding ethnicity, age,
gender, and disabilities [33].
Table 2 shows that 11 studies are specic for ASD, and 9 studies
have a specic perspective in SE. Moreover, some studies also in-
vestigated other types of factors, e.g., organizational [
36
] or task
characteristics [
27
]. Productivity and Performance were studied
in four studies. Two recent reviews address the Global Software
Development (GSD) [
3
,
42
] and the Modern Code Review Process
[
18
,
19
]. Regarding the “Quality Score”, 11 studies had an excellent
evaluation with a score of 5 (see the fourth column in Table 2).
Approximately 76% of the studies (22) got a score bigger or equal
to 3.5. Hence, most of the studies achieved good quality [24].
The following sections show the 101 human factors identied
(Table 3) associated with the 79 inuences (Tables 4, 5, 7, 6), thus
answering the research questions. The character “*” (Tables 3, 4,
5, 7, 6) denotes human factors and their inuences on ASD. The
large number of human factors and inuences prevents us from
analyzing all data due to the lack of space in this article.
3.1 RQ1: Human factors investigated
To answer RQ1, we coded the human factor investigated in each
study (see Table 3). The number in parentheses refers to the num-
ber of SLR/SMS in which the human factor was discussed. We
group only human factors with the same semantic radical, for ex-
ample, motivation and (de)motivation were grouped in Motivation.
SBES ’21, September 27-October 1, 2021, Joinville, Brazil Dutra et al.
Table 3: Human Factors inuencing software development
Age* (3) [30, 33, 44] Empowerment* (5) [7, 21, 27, 37, 41]
Motivation* (15) [
1
,
2
,
7
,
9
,
10
,
15
,
17
,
18
,
21
,
23
,
36, 37, 41, 42, 45]
Anger (3) [14, 18, 40] Enjoy (2) [21, 40] Need for Stability (3) [7, 21, 44]
Anticipation (1) [40] Enterprising* (2) [21, 45] Openness* (3) [37, 44, 45]
Autonomy* (11) [
1
,
2
,
7
,
10
,
15
,
17
,
21
,
27
,
36
,
37
,
45]
Enthusiasm* (2) [44, 45] Orientation (2) [21, 44]
Balance Work/life* (9) [
1
,
2
,
7
,
15
,
17
,
21
,
27
,
44
,
45
]
Equity* (3) [2, 15, 27] Ownership* (4) [1, 17, 21, 23]
Boredom (2) [7, 21] Ethics* (3) [1, 30, 45] Participative Safety* (5) [2, 18, 21, 27, 44]
Calm/relaxation* (2) [17, 40] Ethnicity* (3) [30, 33, 44] Passion* (2) [17, 41]
Challenge* (5) [2, 7, 15, 21, 44] Excited (1) [40] Perseverance* (1) [45]
Changing Adaptability* (9) [
2
,
7
,
15
,
17
,
21
,
39
,
41
,
44, 45]
Experience* (12) [
1
,
2
,
4
,
9
,
15
,
17
19
,
23
,
36
,
37
,
45]
Persistence* (1) [2]
Cohesion* (5) [9, 11, 36, 44, 45] Fairness (1) [36]
Personality* (13) [
4
,
5
,
7
,
11
,
17
,
21
23
,
30
,
33
,
36
,
44, 45]
Collaboration* (17) [
2
,
5
,
7
,
9
,
10
,
15
,
17
,
19
,
21
,
23
,
27, 37, 39, 41, 42, 44, 45] Fatigue (1) [23] Politeness (1) [14]
Collective Thinking (1) [44] Fear (2) [21, 40] Pressure* (3) [15, 17, 23]
Commitment* (9) [1, 2, 17, 27, 36, 37, 42, 44, 45] Feedback* (9) [1–3, 7, 15, 17, 21, 27, 37] Pride (1) [23]
Communication* (21) [
1
4
,
7
,
9
11
,
15
,
17
19
,
21
,
23, 26, 27, 36, 37, 42, 44, 45] Flexibility* (3) [7, 44, 45] Proactivity* (3) [21, 23, 45]
Competency* (9) [4, 7, 17, 18, 21, 23, 41, 44, 45] Friendship (1) [18] Race* (2) [30, 41]
Competition* (1) [45] Frustration (2) [18, 40] Recognition* (6) [1, 7, 15, 27, 41, 44]
Concentration* (2) [17, 45] Fulllment* (3) [15, 41, 44] Relevance* (3) [7, 15, 44]
Conicts Resolution* (3) [11, 44, 45] Gender* (6) [22, 23, 30, 33, 41, 44] Respect* (4) [17, 27, 36, 44]
Conscious Sensitivity* (1) [45] Happiness (3) [14, 23, 40] Responsibility* (8) [2, 17, 21, 37, 41, 42, 44, 45]
Consistency (1) [18] Honesty* (4) [2, 37, 41, 45] Rigidity (1) [18]
Contentment (1) [40] Initiative* (1) [45] Rudeness (1) [14]
Conviction* (1) [45] Innovation* (4) [21, 37, 41, 44] Sadness (2) [14, 40]
Coordination* (7) [2, 3, 7, 15, 17, 21, 44] Integrity* (2) [37, 45] Satisfaction* (8) [2, 5, 15, 17, 19, 21, 27, 36]
Creativity* (8) [5, 7, 21, 23, 26, 27, 37, 45] Intelligence (2) [18, 36] Sense of Belonging* (3) [7, 15, 27]
Cultural Aspects* (7) [3, 10, 17, 18, 23, 26, 41] Interaction (2) [3, 18] Sharing* (8) [2, 17–19, 23, 26, 42, 44]
Decision-making* (8) [2, 7, 11, 23, 27, 39, 41, 44] Interest* (2) [1, 40] Social Support* (2) [41, 44]
Depression (1) [40]
Involvement* (13) [
2
,
3
,
7
,
10
,
15
,
17
,
21
,
23
,
33
,
37
,
42, 44, 45] Stress* (6) [7, 15, 17, 21, 27, 40]
Disability* (2) [30, 33] Joy (3) [14, 21, 40] Surprise (1) [40]
Disgust (1) [40]
Knowledge* (17) [
1
4
,
7
,
9
,
10
,
15
,
17
19
,
23
,
26
,
27, 36, 41, 45]
Team working* (11) [
1
,
2
,
7
,
15
,
21
,
23
,
27
,
36
,
37
,
44, 45]
Education* (5) [4, 17, 23, 41, 45] Language (2) [3, 26]
Trust* (14) [
2
,
3
,
7
,
10
,
17
,
18
,
23
,
26
,
27
,
36
,
37
,
40
,
41, 44]
Eectiveness* (5) [7, 23, 36, 41, 45]
Leadership* (11) [
5
,
7
,
10
,
15
,
17
,
21
,
36
,
37
,
41
,
44
,
45]
Vision* (3) [23, 44, 45]
Eciency* (2) [44, 45]
Learning* (11) [
2
,
4
,
10
,
15
,
17
,
19
,
21
,
23
,
37
,
41
,
45
]
Wellness* (2) [7, 10]
Emotionally Resilient (1) [21] Love (2) [14, 40] Willingness* (2) [26, 45]
Empathy* (3) [18, 36, 37] Moral* (2) [44, 45]
Personality traits were grouped in Personality. We decided not to
categorize the human factors due to the dierences in the theo-
retical constructs they can represent. The most common human
factor were Communication (21), Collaboration (17), Knowledge (17),
Motivation (15), Trust (14), Personality (13), Involvement (13), Experi-
ence (12), Leadership (11), Team working (11), Autonomy (11), and
Learning (11). The less investigated human factor in the studies,
with one citation each, involved mainly emotions, e.g., Emotionally
Resilient, Conscious Sensitivity, Contentment, Disgust, Friendship, and
Pride.
Notice that in Table 3, some human factors represent individual
aspects, such as physical and cognitive characteristics, feelings,
or behaviors. Behaviors represent employee interactions manifest
with the other developer, team, work, or organization.
Individual characteristics can be represented by Age, Gender,
Personality, Disability, Ethnicity, or Race. Two studies [
30
,
33
] in-
vestigated “Diversity” factors in the team composition and task
assignment. Cognitive characteristics correspond to the way the
software developer reasons. In this sense, human factors can be
represented by Learning, Decision-Making, or Intelligence.
Some human factors represent behaviors related to the team
member’s interaction with the team or the work. Usually, activities
inherent to software development are performed as a team. In this
sense, we identied human factors to represent the necessary be-
haviors to ensure interaction between members, e.g., Collaboration,
Communication, Coordination, or Collective thinking.
Dyba and Dingsøyr [
17
] reported that in ASD is necessary to
establish negotiation to explore and agree on the progress of the
tasks. The negotiation involves Communication and Collaboration
between the members of the agile team and the product owner for
the planning of iterations and the execution of tasks. Vishnubhotla
et al. [
45
] classied Collaboration as an individual attribute of de-
velopers and an attribute that allows understanding the integrated
perspectives to innovation.
Other human factors represent behaviors of development team
members regarding the organization’s culture. Organizations dene
their processes, rules, and practices through their mission, vision,
and values. Thus, the way the organization operates generates feel-
ings or behavioral reactions in their employees. Melo et al. [
15
]
and Beecham et al. [
7
] state that reward and incentive policies
Human Factors and their Influence on Soware Development Teams - A Tertiary Study SBES ’21, September 27-October 1, 2021, Joinville, Brazil
Table 4: Inuence on Team Member
Inuence Human Factor
Team Member At-
tributes* [
4
,
5
,
7
,
17
,
21, 22, 27, 41, 45]
Collaboration, Communication, Motivation,
Leadership, Ethics, Creativity, Personality, Bal-
ance Work/life, Team working, Empowerment,
Commitment, Trust, Responsibility, Knowledge,
Integrity, Autonomy, Learning, Involvement,
Experience, Conicts Resolution, Decision-
making, Flexibility, Concentration, Compe-
tency, Need for Stability, Challenge, Willing-
ness, Stress, Conviction, Education, Persever-
ance, Proactivity, Gender, Satisfaction, Partici-
pative Safety, Enthusiasm, Equity, Enjoy
Team Member Motiva-
tion* [1, 2, 7, 15, 21]
Collaboration, Communication, Motivation,
Leadership, Creativity, Personality, Changing
Adaptability, Balance Work/life, Team working,
Empowerment, Trust, Responsibility, Knowl-
edge, Relevance, Autonomy, Learning, Involve-
ment, Wellness, Experience, Sense of Belong-
ing, Recognition, Innovation, Decision-making,
Ownership, Eectiveness, Coordination, Com-
petency, Need for Stability, Challenge, Feedback,
Stress, Satisfaction, Participative Safety, Hon-
esty, Sharing, Joy, Boredom, Enjoy, Fulllment
Team Member Satisfac-
tion [5, 11, 21, 44]
Motivation, Personality, Satisfaction, Enthusi-
asm
Team Member
Decision-making*
[4, 10, 11, 27]
Collaboration, Communication, Leadership,
Creativity, Personality, Balance Work/life, Team
working, Empowerment, Commitment, Trust,
Responsibility, Knowledge, Autonomy, Learn-
ing, Sense of Belonging, Recognition, Respect,
Competency, Feedback, Satisfaction, Participa-
tive Safety, Equity
Team Member Emo-
tion* [15, 17, 21, 45]
Communication, Motivation, Leadership, Ethics,
Passion, Team working, Competency, Initiative,
Willingness, Stress, Enthusiasm, Boredom
Team Member Educa-
tion* [11, 17]
Collaboration, Communication, Personality,
Commitment, Competency
Team Member Prob-
lem Solving* [15, 21] Motivation
Team Member Work
Ethics* [45]
Motivation, Ethics, Commitment, Responsibil-
ity, Integrity, Flexibility, Honesty
Team Member Inter-
personal Attributes*
[45]
Collaboration, Team working, Involvement,
Conicts Resolution, Proactivity
Team Member Innova-
tion* [45]
Collaboration, Creativity, Enterprising, Chang-
ing Adaptability, Vision, Disability, Innovation,
Openness, Eciency
Team Member Agile
Attitudes* [41]
Collaboration, Passion, Responsibility, Learning,
Honesty
Team Member Agile
Mindset* [37]
Collaboration, Communication, Motivation,
Leadership, Creativity, Team working, Empow-
erment, Commitment, Trust, Responsibility,
Knowledge, Integrity, Autonomy, Learning, In-
volvement, Experience, Innovation, Openness,
Feedback, Honesty, Empathy
contribute to feelings and behaviors of Recognition. The way the
organization operates, presents its objectives, or expresses possibil-
ities of articulation, is internalized and then externalized through
behaviors that show work Relevance, Participative Safety, Openness,
and Coordination as part of the development team member.
3.2 RQ2: HF inuencing software development
To answer RQ2, we analyzed the research structure of each study
and the discussions to relate human factors and their inuences.
After coding the human factors, we associated the 79 identied
Table 5: Inuence on Team
Inuence Human Factor
Team Attributes*
[10, 27, 45]
Collaboration, Communication, Motivation, Leader-
ship, Creativity, Personality, Enterprising, Chang-
ing Adaptability, Balance Work/life, Team work-
ing, Empowerment, Trust, Responsibility, Knowl-
edge, Relevance, Cultural Aspects, Autonomy, Learn-
ing, Involvement, Experience, Cohesion, Recognition,
Decision-making, Social Support, Moral, Orientation,
Eectiveness, Respect, Competency, Need for Sta-
bility, Challenge, Feedback, Eciency, Proactivity,
Fear, Satisfaction, Emotionally Resilient, Competi-
tion, Conscious Sensitivity
Team Motivation*
[1, 2, 15, 18, 41]
Collaboration, Communication, Motivation, Leader-
ship, Ethics, Changing Adaptability, Commitment,
Balance Work/life, Team working, Knowledge, Rel-
evance, Autonomy, Learning, Involvement, Experi-
ence, Sense of Belonging, Recognition, Social Support,
Ownership, Eectiveness, Coordination, Challenge,
Feedback, Stress, Satisfaction, Interest, Fulllment
Team Agile Capa-
bility* [
1
,
10
,
17
,
41
,
45]
Collaboration, Communication, Motivation, Lead-
ership, Personality, Changing Adaptability, Bal-
ance Work/life, Empowerment, Trust, Responsibility,
Knowledge, Cultural Aspects, Autonomy, Involve-
ment, Respect, Competency, Conscious Sensitivity,
Team Performance
[4, 5, 11, 26, 44]
Collaboration, Communication, Motivation, Person-
ality, Team working, Commitment, Trust, Knowl-
edge, Relevance, Cultural Aspects, Learning, Ethnic-
ity, Recognition, Disability, Decision-making, Collec-
tive thinking, Respect, Openness, Coordination, Age,
Gender, Satisfaction, Participative Safety
Team Training and
Learning* [
1
,
2
,
15
,
41, 45]
Motivation, Knowledge, Learning, Feedback, Educa-
tion, Sharing
Team Leadership*
[10, 17, 45]
Collaboration, Communication, Leadership, Team
working, Commitment, Competency, Feedback
Teamwork* [
5
,
15
,
33, 44]
Motivation, Personality, Disability, Age, Gender, En-
thusiasm
Team Diversity* [
7
,
30, 33]
Motivation, Ethics, Personality, Ethnicity, Race, Dis-
ability, Age, Gender
Team Collabora-
tion* [10, 14, 17]
Collaboration, Communication, Involvement, Polite-
ness
Team Composi-
tion* [11, 41, 45]
Personality, Knowledge, Cultural Aspects, Ethnicity,
Race, Decision-making, Competency, Eciency, Gen-
der
Team Climate* [
26
,
44]
Collaboration, Communication, Motivation, Lead-
ership, Creativity, Changing Adaptability, Balance
Work/life, Team working, Commitment, Fulll-
ment, Trust, Responsibility, Knowledge, Relevance,
Autonomy, Learning, Involvement, Vision, Cohe-
sion, Recognition, Innovation, Conicts Resolution,
Decision-making, Social Support, Collective thinking,
Moral, Orientation, Respect, Openness, Coordination,
Competency, Challenge, Feedback, Satisfaction, Par-
ticipative Safety, Enthusiasm, Sharing, Interaction
Team Knowledge
Sharing* [19, 26]
Communication, Creativity, Trust, Knowledge, Cul-
tural Aspects, Learning, Language, Willingness
Self-organized
Team* [10, 17, 37]
Knowledge, Cultural Aspects, Autonomy, Experience,
Empowerment, Decision-making, Ownership, Coor-
dination, Calm/relaxation
Team Innovation*
[44, 45]
Collaboration, Motivation, Creativity, Vision, Inno-
vation, Orientation, Participative Safety
Team Business Ex-
cellence* [45] Eectiveness, Openness
Team Commit-
ment* [1] Motivation, Commitment
Team Emotion [
40
] Trust, Stress, Fear, Anger, Anticipation, Contentment,
Depression, Calm/relaxation, Disgust, Excited, Hap-
piness, Frustration, Interest, Joy, Love, Sadness, Sur-
prise, Enjoy
Team Experience*
[45]
Knowledge, Experience
Team Social
Attributes* [45]
Collaboration, Communication, Motivation, Cohe-
sion, Competition
Team Ownership*
[1]
Motivation, Ownership
Team Operational
Excellence* [45]
Competency, Eciency
SBES ’21, September 27-October 1, 2021, Joinville, Brazil Dutra et al.
inuences into four categories: Team Member (Table 4), Team (Table
5), Project (Table 7), and Organization (Table 6).
The inuences on Team Member Attributes (Table 4) and Team
Attributes (Table 5) group the human factors authors did not asso-
ciate with specic SE activities. Vishnubhotla et al. [
45
] elicited the
i) individual engineer attributes and ii) attributes for the team in
the category denominated professional. The authors classied, for
instance, Enthusiasm as aective (Table 4) and active Learning and
improvement as growth (Table 5). The authors also identied fac-
tors that impacted Innovation from the perspective of professionals
(see Team Member Innovation inuence in Table 4) and the team
(see Team Innovation inuence in Table 5). Inuences in dierent
perspectives (e.g., team member and team) also occurred in the
other factors (e.g., Motivation).
We identied 5 studies that investigated Motivation in the Team
Member (Table 4) and Team (Table 5). França et al. [
21
], in an up-
date of the review performed by Beecham et al. [
7
], investigated
external signs and aspects that (de)motivate software engineers.
Learning opportunities, experimentation to gain Knowledge, Auton-
omy, and eective Communication (Table 4) are human factors that
(de)motivate software engineers to be more or less productive [
21
].
Melo et al. [
15
] identied factors that inuence Team Member Moti-
vation (Table 4) and Team Motivation (Team 5) on ASD. Autonomy
and Feedback were factors that motivate the team member [15].
The Team Member Decision-making inuence (Table 4) represents
the behaviors of each individual that will inuence the behavior of
other team members and the project results [
27
]. Jia et al. [
27
] iden-
tied environmental factors inuencing individual Decision-Making
behavior in software projects. The authors show team character-
istics, e.g., Communication, Trust, Respect, and Feedback, inuence
Team Member Decision-making (Table 4) [27].
The Team Climate inuence (Table 4) represents factors that can
be dened as a combination of its team members’ interactions to
share their perceptions of the team’s work procedures and practices
[
44
]. Soomro et al. [
44
] investigated several factors that inuence
the Team Climate. The authors reported that Collaboration, Coopera-
tion, Coordination, Collective Thinking, and Cohesion can potentially
inuence the Organizational Climate of the team.
In the comprehensive SLR, Sanchez-Gordon and Colomo-Palacios
[
40
] identied 7172 articles related to Team Emotions (Table 5) on
SE. The authors reported 40 discrete emotions, the most frequent
being Anger, Fear, Disgust, Sadness, Joy, Love, and Happiness. As per
the authors, the study of emotions has received growing attention
from the research community in recent years, but the management
of emotions has always been challenging in practice [40].
Analyzing Table 7 (Inuence on Project), it is possible to observe
that the most frequent factors are Communication and Collabora-
tion. Ammad et al. [
3
] state that, in recent years, many software
organizations are doing their development practices in the GSD
environment. The SLR results showed that Communication is one
of the critical issues in GSD and is becoming more complicated over
time. Askarinejadamiri [
4
] claimed the requirement gatherer train-
ing in Communication skills is fundamental to increase Software
Quality (Table 7). Barroso et al. [
5
] identied a study that showed
the Inuence of Personality on Software Quality. Guveyi et al. [
23
]
identied that individual factors are the most important category
of human factors aecting people and will directly aect software
quality. The most researched factors were Communication, Collabo-
ration, Experience, and Education [
23
]. The authors concluded that
investing in people will aect the success and quality of the project
positively [23].
Project Requirements Engineering and Project Construction (Table
7) are two of the most performed activities in software development.
Communication is the most inuential human factor in that activi-
ties. However, we identied other human factors less investigated,
e.g., diversity [
30
,
33
]. Menezes and Prikladnicki [
33
] reported that
“although the project was a success in the delivery phase, a transgen-
der developer was not comfortable in technical visits in loco. Due to
physical limitations, some members with Disabilities avoid moving
to the customer because there is no adaptation in the workplace
environment.” For that reason, the human factors Gender and Dis-
ability were associated with the Project Requirements Engineering,
Project Construction, and Allocation Process inuence [33].
Fatima et al. [
18
] identied the individual, social, and personal
factors inuencing the Code Review Process (Table 7). They classied
the factors, for instance, by individual characteristics (Communi-
cation, Trust, and Competence), emotion (Anger, Frustration, and
Empathy), and social factors (Trust, Interaction, and Friendship) [
18
].
Table 6 presents the HF inuences in the Organization category.
The Organization Management inuence is most frequent in the
studies. When the organization presents a benecial environment,
through eective Organization Management, team members tend
to increase Motivation and Commitment [
2
,
27
]. Motivation is the
most frequent HF in (Table 6). França et al. [
21
] reported that Mo-
tivation is the level of employee involvement with the company,
as evidenced by the Organizational Commitment.Motivation also
impacts Organization’s Job retention, Organizational Absenteeism,
and Organization Rewards and Incentives inuence [7, 21].
3.3 RQ3: Human factors inuence on ASD
We identied 70 human factors and 69 inuences concerning ASD.
These human factors are listed with “*” in Table (3, 4, 5, 7, 6). The
high number of inuences is explained by 11 of the selected studies
concerned ASD specically. Motivation, Communication, Collabora-
tion, and Trust are the most cited factors when describing human
factors in ASD [
1
,
2
,
10
]. ASD diers from traditional methodologies
through principles, values, frameworks, or practices that contribute
to forming an autonomous and self-organized team [6, 17, 37].
Many human factors investigated are based on the Agile Mani-
festo [
6
,
10
,
37
]. We identied that Autonomy, Empowerment, Change,
Communication, Collaboration, Learning, Feedback, customer Involve-
ment, Motivation, and Trust are explicitly supported by the Agile
Manifesto [
10
,
37
] and inuence the team member, team, project, or
organization in dierent aspects. E.g., Chagas et al. [
10
] argue that
the value of interaction between people is made explicit in the sixth
agile manifesto principle: “The most ecient and eective method
of conveying information to and within a development team is
face-to-face conversation.” Therefore, Communication inuence on
Customer Involvement and Agile Practices (Table 7) [10].
Ozkan and Gok [
37
] reported that eective agile individuals,
teams, and organizations require a particular attitude, way of think-
ing, and behavior, so-called as agile mindset. Regarding the Team
Member Agile Mindset inuence (Table 4), the authors [
37
] argued
Human Factors and their Influence on Soware Development Teams - A Tertiary Study SBES ’21, September 27-October 1, 2021, Joinville, Brazil
Table 6: Inuence on Organization
Inuence Human Factor
Organization Manage-
ment* [
7
,
10
,
15
,
17
,
21
,
27, 41, 42, 45]
Collaboration, Communication, Motivation,
Leadership, Personality, Team working, Com-
mitment, Trust, Knowledge, Recognition, In-
novation, Decision-making, Coordination,
Competency
Organization Rewards
and Incentives* [
1
,
7
,
15, 21]
Motivation, Recognition
Organizational Cul-
ture* [2, 17, 27]
Collaboration, Motivation, Changing Adapt-
ability, Cultural Aspects, Autonomy,Decision-
making, Ownership, Coordination, Feedback
Organization’s Job re-
tention [7, 11, 21]
Motivation, Personality
Organization Struc-
ture* [1, 15, 17]
Collaboration, Motivation, Cultural Aspects,
Autonomy, Ownership, Equity
Organizational Absen-
teeism* [1, 7, 21]
Motivation
Organizational Agile
Transition* [39]
Involvement, Collaboration, Changing Adapt-
ability, Decision-making, Communication,
Team working
Organization’s
Methodology Cham-
pion* [41]
Leadership, Learning
Organizational Devel-
opment [4]
Education
Organizational Com-
mitment [21, 27]
Motivation, Commitment, Decision-making
Organizational Envi-
ronment [27, 33]
Ethnicity, Disability, Decision-making, Age,
Gender
that Autonomy, Empowerment, and self-organizing (Table 5), along
with Teamwork, enable teams to respond to varying cases of com-
plexity. Teamwork with powerful Commitment, dedicated focus on
and oriented to a shared goal, and creating value to the customer
with high quality are the main drivers for success.
Many human factors impact the Team Member Motivation (Table
4) and Team Motivation (Table 5). Melo et al. [
15
] showed that a
lack of bureaucracy during the development process Motivates agile
teams. Moreover, constant Learning and Knowledge Sharing are
necessary to the adoption of agile practices. The Sense of Belonging
and Recognition are other main factors inuencing Motivation on
ASD teams [
1
,
2
]. In the other direction, the human factor Motivation
impacted other factors such as Organization Rewards and Incentives
[1, 7, 15, 21] and Organizational Absenteeism [1, 7, 21].
Senapathi and Srinivasan [
41
] identied factors that impact sus-
tained agile use. Some HF were extracted through the discussions or
reports proposed by the authors. For instance, the authors reported
“teams with mixed attitudes, (where some were very passionate
about agile practices and others who were not very keen on agile
resulted in an attitude of ‘us vs. agilists’ ).” Based on that, we coded
that Passion inuences Sustainable Agile Use (Table 7).
Pinton and Torres [
39
] investigated the human aspects of agile
transition (see Organizational Agile Transition inuence in Table 6).
The HF identied were client Involvement, Collaboration, Changing
Adaptability, and Decision-making. The authors argued that the
project manager should act only as a facilitator and be part of
the nal decision along with the team, no longer maintaining the
planning and controlling roles of the traditional model. Teamwork
is the key, so Collaboration is of paramount relevance. The entire
team is responsible for work completion, so both project ownership
and benets are shared among all members. When the team fails to
embrace this mindset, the transition becomes much more arduous.
Customers should be dedicated to the project and have the same
Collaborative and Communicative roles as any other team members.
It is also worth mentioning that the development team requests
customers’ Feedback Collaboratively to adjust the process towards
its optimization continually [39].
4 DISCUSSION
The 29 selected SLR/SMS provided us a helpful insight into the
state of the art of human factor research in Software Engineering
(SE). In general, most of the studies have a good quality score. We
identied 101 human factors and 79 inuences on SE. We grouped
the inuences into 4 categories. We identied 70 human factors
and 69 inuences on ASD. These factors and inuences possibly
represent the most signicant ones to be considered by software
organizations and SE researchers.
A quick search for “human factors” on online databases shows
that the number of studies on human factors increases each year.
In many studies, researchers consistently report the need for fur-
ther studies (e.g., see [
10
,
11
]). However, Capretz [
20
] reported that
“others might think that there’s no place for the discussion of soft
skills in an area that’s so driven by logic and based on a mathe-
matical foundation. These misconceptions discourage educators
and researchers willing to work in this interdisciplinary area.” The
researcher also states that “from the management’s perspective and
for the majority of software practitioners, human factors are still
considered marginal and treated as common sense [
20
].” Based on
this statement [
20
], we decided to discuss possible uses of human
factors and their inuence identied from a perspective for the
management, researchers, and academics.
Our results might help those in charge of management activities
to identify suitable human factors for specic activities. Managers
and team leaders can use the human factors list and their inu-
ences as input to manage project risks and the team. For instance,
to reduce Organizational Absenteeism or increase Organization’s
Job Retention (Table 6), the management must guarantee a Moti-
vated Team (Table 5). Team leaders can identify and execute actions
limiting or impairing the Self-organized Team or Team Agile Capa-
bility (Table 5). For this, the enhancement of human factors (e.g.,
Coordination, Empowerment, and Autonomy) must be considered.
Also, a human resource professional can use our results as input
to dene processes such as those related to People Involvement
and Competency Acquisition (as described in ISO 10018 [
25
]) or
to Human Resource Recruitment by, for instance, ensuring Team
Diversity Diversity (age, gender, disability, or Ethnicity) due to its
positive inuence to Team Member Innovation.
Our results might interest researchers studying behaviors, emo-
tions, or personal characteristics in SE. Whereas the outcomes are a
catalog of papers, human factors, and their inuence on how human
factors are being discussed in SE. For instance, researchers with in-
terest in Motivation can nd i) 5 SLR in which Motivation is the main
topic (Table 2), ii) other 15 studies that discuss Motivation (Table
3), and iii) more than 50 inuences Motivation has on other human
factors and SE activities. Researchers can also use human factors
to create specic instruments to measure a psychological construct
SBES ’21, September 27-October 1, 2021, Joinville, Brazil Dutra et al.
Table 7: Inuence on Project
Inuence Human Factor
Agile Project* [
1
,
2
,
10
,
11
,
15
,
17
,
30, 41, 42, 45]
Collaboration, Communication, Motivation, Leadership, Ethics, Creativity, Personality, Enterprising, Passion, Chang-
ing Adaptability, Balance Work/life, Team working, Empowerment, Commitment, Trust, Responsibility, Knowledge,
Integrity, Cultural Aspects, Autonomy, Learning, Involvement, Wellness, Experience, Vision, Ethnicity, Cohesion,
Sense of Belonging, Recognition, Innovation, Conicts Resolution, Decision-making, Social Support, Flexibility,
Concentration, Collective thinking, Moral, Ownership, Orientation, Eectiveness, Respect, Openness, Coordination,
Competency, Challenge, Feedback, Eciency, Initiative, Willingness, Stress, Conviction, Education, Perseverance,
Proactivity, Gender, Satisfaction, Participative Safety, Competition, Honesty, Enthusiasm, Conscious Sensitivity,
Sharing, Calm/relaxation, Interest, Equity, Boredom, Fulllment
Maintenance Project* [
2
,
11
,
15
,
33
]
Motivation, Personality, Gender
GSD Project* [42] Collaboration, Communication, Motivation, Commitment, Responsibility, Involvement, Sharing
Software Quality* [
1
,
2
,
4
,
5
,
15
,
18
,
21, 23, 44]
Collaboration, Communication, Motivation, Creativity, Personality, Balance Work/life, Team working, Empowerment,
Trust, Knowledge, Cultural Aspects, Autonomy, Learning, Involvement, Experience, Vision, Decision-making, Own-
ership, Eectiveness, Respect, Competency, Feedback, Education, Proactivity, Gender, Enthusiasm, Sharing, Pressure,
Happiness, Fatigue, Pride
Project Success* [
4
,
7
,
10
,
11
,
15
,
17
,
21, 45]
Collaboration, Communication, Motivation, Personality, Cultural Aspects, Knowledge, Leadership, Involvement,
Experience, Satisfaction
Project Success* [10, 15, 17, 45] Communication, Motivation, Leadership, Knowledge, Cultural Aspects, Involvement, Satisfaction
Engineering Practices* [
1
,
10
,
15
,
17, 33, 41]
Collaboration, Communication, Motivation, Leadership, Creativity, Personality, Knowledge, Involvement, Experience,
Ethnicity, Disability, Age, Gender, Satisfaction, Fulllment
Agile Practices* [1, 10, 15, 17, 41]
Collaboration, Communication, Motivation, Knowledge, Cultural Aspects, Autonomy, Learning, Involvement, Experi-
ence, Concentration, Ownership, Eectiveness, Coordination, Feedback, Satisfaction, Sharing
Customer Involvement* [
2
,
3
,
10
,
17, 42]
Collaboration, Communication, Motivation, Team working, Commitment, Cultural Aspects, Involvement, Respect,
Competency, Stress, Satisfaction
Productivity [4, 7, 9, 14, 36]
Collaboration, Communication, Motivation, Leadership, Personality, Team working, Commitment, Trust, Knowledge,
Autonomy, Experience, Cohesion, Fairness, Eectiveness, Respect, Education, Satisfaction, Happiness, Empathy,
Intelligence
Allocation Process* [9, 11, 33, 45] Personality, Knowledge, Cultural Aspects, Ethnicity, Cohesion, Disability, Decision-making, Gender
Budget* [1, 2, 7, 17, 44] Motivation, Eciency
Project Management* [
1
,
7
,
15
,
45
]
Collaboration, Communication, Motivation, Personality, Commitment, Recognition, Need for Stability, Satisfaction,
Participative Safety
Project Construction* [
10
,
11
,
14
,
15, 33]
Communication, Motivation, Leadership, Personality, Knowledge, Involvement, Gender, Anger, Joy, Love, Sadness,
Rudeness, Politeness
Code Review Process [11, 18, 19]
Collaboration, Communication, Motivation, Personality, Trust, Knowledge, Cultural Aspects, Learning, Experience,
Competency, Participative Safety, Sharing, Anger, Frustration, Interaction, Empathy, Intelligence, Rigidity, Consistency,
Friendship
Project Testing [2, 5, 11, 15, 33] Motivation, Personality, Gender
Project Requirements Engineering*
[1, 17, 45]
Collaboration, Communication, Motivation, Personality, Changing Adaptability, Team working, Commitment, Knowl-
edge, Cultural Aspects, Involvement, Experience, Respect, Competency, Stress, Gender, Satisfaction, Sharing
Project Software Process* [1, 15] Motivation
Project Models and Methods* [33] Disability
Sustainable Agile Use* [17, 41]
Collaboration, Communication, Motivation, Leadership, Passion, Changing Adaptability, Empowerment, Trust,
Responsibility, Knowledge, Cultural Aspects, Learning, Experience, Ethnicity, Recognition, Innovation, Decision-
making, Social Support, Eectiveness, Competency, Education, Gender, Satisfaction, Honesty, Fulllment
Communication in GSD Project [
3
]
Communication, Trust, Knowledge, Cultural Aspects, Involvement, Language, Coordination, Feedback, Interaction
Decision Time* [2] Communication, Motivation, Decision-making, Satisfaction
Delivery Time [7] Motivation
Project Diversity* [30] Ethics, Personality, Ethnicity, Race, Disability, Age, Gender
Documentation* [1] Motivation
Resources* [1] Motivation
Risk Management* [1] Motivation
Project Sponsorship* [1] Motivation
Project Team Size* [2] Communication, Motivation, Coordination
Project Tracking* [1] Motivation
Technically Challenging Tasks*
[15]
Motivation, Relevance, Challenge
Reduced Rework Repetition* [1] Motivation
Changes Prioritization* [1] Motivation
Project Protability* [21, 30] Motivation, Ethnicity, Gender
Project Team Distribution* [2] Communication, Motivation
Agile Logistic* [1] Motivation
(e.g., Team Member Decision-making, see Table 4) or technical ac-
tivities (e.g., Code Review Process, see Table 5). Machuca-Villegas et
al. [
32
] used the results of Canedo and Santos [
9
] to create an in-
strument for measuring perception about social and human factors
that inuence software development productivity.
Concerning the academic perspective, Oguz and Oguz [
35
] re-
ported that academia needs to balance hard and soft skills with
realistic projects to decrease the gap between the software industry
and software engineering education. In line with that, Dyba and
Dingsøyr [
17
] reported the student perceptions about participating
in the empirical study at an university. The students’ found that
Human Factors and their Influence on Soware Development Teams - A Tertiary Study SBES ’21, September 27-October 1, 2021, Joinville, Brazil
working in agile teams helped them develop professional skills
such as Communication, Commitment, Collaboration, and Changing
Adaptability [
17
]. We believe that the lecturer is responsible for
developing educational activities involving human factors, e.g., Col-
laboration, Communication, resolutions of conict, and Motivation
of the future software engineer. Thereby, it is necessary to propose
activities in realistic projects, involving phases of requirements,
analysis, design, coding, and tests. These activities should simulate
the roles and tasks of real software development teams.
5 LIMITATION AND THREATS TO VALIDITY
It is essential to notice that we do not foresee to indicate the in-
uence of the human factors using statistical concepts, such as
correlations (positive/negative) or causalities. Moreover, several
primary studies identied by the selected SLR/SMS are case studies,
had small or regional samples, and did not use psychometrically
validated instruments to measure the psychological constructs in-
vestigated (e.g., Motivation). Thus, it is dicult to generalize the
inuence of the construct. Thereby, a reader has to access the origi-
nal SLR/SMS and, often, the cited primary studies to understand (i)
whether the human factor or their inuence represents a positive
or negative feature and (ii) possible generalizations.
Petersen et al. [
38
] proposed 4 threat types to assess the validity
of SMS. For each identied threat, we planned and executed control
actions as follows.
Regarding the descriptive validity, two researchers carried out
the denition of questions, extraction elds, and assembly of the
search expression. Some adjustments were made during the exe-
cution of the research. However, the extraction and coding into
categories were performed only by the rst author with supervision
and correction by the third author. To minimize this threat, a report
was generated (using a feature of Atlas.ti) indicating the categories
and the associated original text, so the researchers expressed and
resolved interpretative doubts.
To treat threats related to theoretical validity and potential bias,
two researchers participated in this study selection process. The
researchers performed the two lters observing the inclusion and
exclusion criteria. Interpretive divergences in applying the inclusion
or exclusion criteria were inserted in a collaborative spreadsheet,
which allowed the researchers to review the ndings. A possible
common limitation to SLR/SMS is related to the possibility of not
nding relevant articles [
29
]. To address this limitation, (i) the
construction of the search expression was performed iteratively
and incrementally considering the terms and synonyms used in
other SLR [
10
,
11
,
24
], and (ii) we opted to use four online databases
and complement the search results performing forward snowballing.
For instance, Morão et al. [
34
] claim that using only Scopus and
forward snowballing may be appropriate to execute reviews in SE.
Interpretive validity is achieved when the conclusions are rea-
sonable given the data, and hence maps to conclusion validity
[
38
]. A threat in interpreting the data is researcher bias. To reduce
this threat, we rst extracted the human factors from studies that
presented them categorized on lists or tables. By doing that, the
thematic analysis process was made easier since a new category
was created only when a human factor could not be associated
with an existing one. Besides that, the authors have experience in
SLR/SMS and thematic analysis.
Regarding the repeatability of this research, the entire review
protocol is described in detail, and the spreadsheet with all the steps
performed is available (see Section 2).
6 CONCLUSIONS AND FUTURE WORK
Our primary motivation was to investigate the state of the art on
human factors in ES teams to elicit the human factors and their
inuence. We believe this study is the rst, by means of a tertiary
study, to systematize the inuence of human factors through cat-
egories, regardless of the subject or specic practices in SE. We
selected 29 SLR/SMS to review and summarize information about
human factors. As a result, we identied 101 human factors that
inuence software development activities from dierent perspec-
tives. The 79 inuences were grouped based on their eects into
Team Members, Teams, Projects, and Organizations. Furthermore,
we identied 71 human factors and 60 inuences in ASD.
The results can be used to support human resources managers,
project managers, and team leaders to identify and develop actions
to support the management of performance, climate, and risk. In
an academic context, we noticed a growing interest by the SE re-
search community on ASD, mainly in perspective about motivation,
diversity, and GSD. Many SLR/SMS approached the human topic
personality. However, the authors indicated the need for more re-
search on this topic. Educators can use lists of human factors and
inuence to propose more practical learning activities, promoting
more social interactions between students.
Based on the identied human factors and their inuences, we
are executing studies to design an organizational climate assessment
instrument adapted for agile teams [16].
ACKNOWLEDGMENTS
We thank UNIRIO (PPQ-UNIRIO 04/2020 and PPINST-UNIRIO 05/2020)
for their nancial support.
REFERENCES
[1]
Shahbaz Ahmed, Salman Ahmed, Mukhtar Ali, Adnan Naseem, Abdul Razzaq,
and Naveed Ahmed. 2018. A Systematic Literature Review of Success Factors
and Barriers of Agile Software Development. International Journal of Advanced
Computer Science and Applications 9, 3 (2018), 1–14. https://doi.org/10.14569/
IJACSA.2018.090339
[2]
Shahbaz Ahmed, Salman Ahmed, Adnan Naseem, and Abdul Razzaq. 2017. Moti-
vators and Demotivators of Agile Software Development: Elicitation and Analysis.
International Journal of Advanced Computer Science and Applications 8, 12 (2017),
1–11. https://doi.org/10.14569/IJACSA.2017.081239
[3]
Ghana Ammad, Uzair Iqbal Janjua, Tahir Mustafa Madni, Muhammad Faisal
Cheema, and Ahmed R. Shahid. 2019. An Empirical Study to Investigate the
Impact of Communication Issues in GSD in Pakistan’s IT Industry. IEEE Access 7
(2019), 171648–171672. https://doi.org/10.1109/ACCESS.2019.2953008
[4]
Zahra Askarinejadamiri. 2016. Personality requirements in requirement en-
gineering of web development: A systematic literature review. In 2016 Second
International Conference on Web Research (ICWR). IEEE, Tehran, Iran, 183–188.
https://doi.org/10.1109/ICWR.2016.7498465
[5]
Anderson S. Barroso, Jamille S. Madureira, Michel S. Soares, and Rogerio P. C.
do Nascimento. 2017. Inuence of Human Personality in Software Engineering -
A Systematic Literature Review. In Proceedings of the 19th International Confer-
ence on Enterprise Information Systems. SCITEPRESS - Science and Technology
Publications, Porto, Portugal, 53–62. https://doi.org/10.5220/0006292000530062
[6]
K Beck, M Beedle, and et al. Bennekum, A Van. 2001. Manifesto for Agile Software
Development. https://agilemanifesto.org/
[7]
Sarah Beecham, Nathan Baddoo, Tracy Hall, Hugh Robinson, and Helen Sharp.
2008. Motivation in Software Engineering: A systematic literature review.
SBES ’21, September 27-October 1, 2021, Joinville, Brazil Dutra et al.
Information and Software Technology 50, 9-10 (aug 2008), 860–878. https:
//doi.org/10.1016/j.infsof.2007.09.004
[8]
Pierre Bourque and Richard E. Fairley. 2014. SWEBOK: Guide to the Software
Engineering Body of Knowledge (v 3.0 ed.). IEEE, Piscataway, NJ. 735 pages.
[9]
Edna Dias Canedo and Giovanni Almeida Santos. 2019. Factors Aecting Software
Development Productivity. In Proceedings of the XXXIII Brazilian Symposium on
Software Engineering. ACM, New York, NY, USA, 307–316. https://doi.org/10.
1145/3350768.3352491
[10]
Aline Chagas, Melquizedequi Santos, Celio Santana, and Alexandre Vasconcelos.
2015. The Impact of Human Factors on Agile Projects. In 2015 Agile Conference.
IEEE, National Harbor, MD, USA, 87–91. https://doi.org/10.1109/Agile.2015.11
[11]
Shirley Cruz, Fabio Q.B. da Silva, and Luiz Fernando Capretz. 2015. Forty years of
research on personality in software engineering: A mapping study. Computers in
Human Behavior 46 (may 2015), 94–113. https://doi.org/10.1016/j.chb.2014.12.008
[12]
Daniela S. Cruzes and T. Dyba. 2011. Recommended Steps for Thematic Synthesis
in Software Engineering. In 2011 International Symposium on Empirical Software
Engineering and Measurement. IEEE, Ban, AB, Canada, 275–284. https://doi.
org/10.1109/ESEM.2011.36
[13]
Bill Curtis, William E. Heey, and Sally A Miller. 2009. People Capability Maturity
Model (P-CMM ) Version 2.0, Second Edition. Technical Report. Carnegie Mellon
University.
[14]
Glauco de Figueiredo Carneiro and Rui Carigé Júnior. 2020. Investigating the
Impact of Developers Sentiments on Software Projects. In 38th Euromicro Confer-
ence on Software Engineering and Advanced Applications. Springer, Cesme, Turkey,
257–263. https://doi.org/10.1007/978-3- 030-43020-7_34
[15]
Claudia de O. Melo, Celio Santana, and Fabio Kon. 2012. Developers Motivation
in Agile Teams. In 2012 38th Euromicro Conference on Software Engineering and
Advanced Applications. IEEE, Cesme, Turkey, 376–383. https://doi.org/10.1109/
SEAA.2012.45
[16]
Eliezer Dutra, Patricia Lima, and Gleison Santos. 2020. An Instrument to Assess
the Organizational Climate of Agile Teams - A Preliminary Study. In SBQS’20:
19th Brazilian Symposium on Software Quality. ACM, São Luis, MA, Brazil, 1–10.
https://doi.org/10.1145/3439961.3439968
[17]
Tore Dybå and Torgeir Dingsøyr. 2008. Empirical studies of agile software
development: A systematic review. Information and Software Technology 50, 9-10
(aug 2008), 833–859. https://doi.org/10.1016/j.infsof.2008.01.006
[18]
Nargis Fatima, Sumaira Nazir, and Suriayati Chuprat. 2019. Individual, Social
and Personnel Factors Inuencing Modern Code Review Process. In 2019 IEEE
Conference on Open Systems (ICOS). IEEE, Pulau Pinang, Malaysia, 40–45. https:
//doi.org/10.1109/ICOS47562.2019.8975708
[19]
Nargis Fatima, Sumaira Nazir, and Suriayati Chuprat. 2019. Knowledge sharing,
a key sustainable practice is on risk: An insight from Modern Code Review. In
2019 IEEE 6th International Conference on Engineering Technologies and Applied
Sciences (ICETAS). IEEE, Kuala Lumpur, Malaysia, 1–6. https://doi.org/10.1109/
ICETAS48360.2019.9117444
[20]
Luiz Fernando Capretz. 2014. Bringing the Human Factor to Software Engineering.
IEEE Software 31, 2 (2014), 104–104. https://doi.org/10.1109/MS.2014.30
[21]
A.C.C. Franca, T.B. Gouveia, P.C.F. Santos, C.A. Santana, and F.Q.B. da Silva. 2011.
Motivation in software engineering: a systematic review update. In 15th Annual
Conference on Evaluation and Assessment in Software Engineering (EASE 2011).
IET, Durham, UK, 154–163. https://doi.org/10.1049/ic.2011.0019
[22]
Abdul Rehman Gilal, Jafreezal Jaafar, Ahsanullah Abro, Mazni Omar, Shuib
Basri, and Muhammad Qaiser Saleem. 2017. Eective personality preferences of
software programmer: A systematic review. Journal of Information Science and
Engineering 33, 6 (2017), 1399–1416. https://doi.org/10.6688/JISE.2017.33.6.1
[23]
Elcin Guveyi, Mehmet S. Aktas, and Oya Kalipsiz. 2020. Human Factor on
Software Quality: A Systematic Literature Review. In ecture Notes in Computer
Science (including subseries Lecture Notes in Articial Intelligence and Lecture
Notes in Bioinformatics), Springer Science Media and Business (Eds.). Springer,
Germany, 918–930. https://doi.org/10.1007/978- 3-030-58811-3_65
[24]
Rashina Hoda, Norsaremah Salleh, John Grundy, and Hui Mien Tee. 2017. Sys-
tematic literature reviews in agile software development: A tertiary study. Infor-
mation and Software Technology 85 (may 2017), 60–70. https://doi.org/10.1016/j.
infsof.2017.01.007
[25]
ISO. 2012. ISO 10018: Quality management - Guidelines on people involvement
and competence. International Standards Organization., Switzerland. 23 pages.
https://www.iso.org/standard/46233.html
[26]
Nima Jafari Navimipour and Yeganeh Charband. 2016. Knowledge sharing
mechanisms and techniques in project teams: Literature review, classication,
and current trends. Computers in Human Behavior 62 (sep 2016), 730–742. https:
//doi.org/10.1016/j.chb.2016.05.003
[27]
Jingdong Jia, Pengnan Zhang, and Luiz Fernando Capretz. 2016. Environmental
factors inuencing individual decision-making behavior in software projects. In
Proceedings of the 9th International Workshop on Cooperative and Human Aspects
of Software Engineering. ACM, New York, NY, USA, 86–92. https://doi.org/10.
1145/2897586.2897589
[28]
Barbara Kitchenham and Pearl Brereton. 2013. A systematic review of systematic
review process research in software engineering. Information and Software
Technology 55, 12 (dec 2013), 2049–2075. https://doi.org/10.1016/j.infsof.2013.07.
010
[29]
Barbara Kitchenham, Rialette Pretorius, David Budgen, O. Pearl Brereton, Mark
Turner, Mahmood Niazi, and Stephen Linkman. 2010. Systematic literature
reviews in software engineering – A tertiary study. Information and Software
Technology 52, 8 (aug 2010), 792–805. https://doi.org/10.1016/j.infsof.2010.03.006
[30]
Karina Kohl Silveira and Rafael Prikladnicki. 2019. A Systematic Mapping Study of
Diversity in Software Engineering: A Perspective from the Agile Methodologies.
In 2019 IEEE/ACM 12th International Workshop on Cooperative and Human Aspects
of Software Engineering (CHASE). IEEE, Montréal, QC, Canada, 7–10. https:
//doi.org/10.1109/CHASE.2019.00010
[31]
Per Lenberg, Robert Feldt, and Lars Göran Wallgren. 2015. Behavioral software
engineering: A denition and systematic literature review. Journal of Systems
and Software 107, September 2015 (sep 2015), 15–37. https://doi.org/10.1016/j.
jss.2015.04.084
[32]
Liliana Machuca-Villegas, Gloria Piedad Gasca-Hurtado, Solbey Morillo Puente,
and Luz Marcela Restrepo Tamayo. 2021. An Instrument for Measuring Per-
ception about Social and Human Factors that Inuence Software Development
Productivity. JUCS - Journal of Universal Computer Science 27, 2 (feb 2021),
111–134. https://doi.org/10.3897/jucs.65102
[33]
Álvaro Menezes and Rafael Prikladnicki. 2018. Diversity in software engineering.
In Proceedings of the 11th International Workshop on Cooperative and Human
Aspects of Software Engineering. ACM, New York, NY, USA, 45–48. https://doi.
org/10.1145/3195836.3195857
[34]
Erica Mourão, João Felipe Pimentel, Leonardo Murta, Marcos Kalinowski, Emilia
Mendes, and Claes Wohlin. 2020. On the performance of hybrid search strate-
gies for systematic literature reviews in software engineering. Information and
Software Technology 123 (jul 2020), 106294. https://doi.org/10.1016/j.infsof.2020.
106294
[35]
Damla Oguz and Kaya Oguz. 2019. Perspectives on the Gap Between the Software
Industry and the Software Engineering Education. IEEE Access 7 (2019), 117527–
117543. https://doi.org/10.1109/ACCESS.2019.2936660
[36]
Edson Oliveira, Tayana Conte, Marco Cristo, and Natasha Valentim. 2018. In-
uence Factors in Software Productivity - A Tertiary Literature Review. In
Proceedings of the International Conference on Software Engineering and Knowl-
edge Engineering, SEKE. World Scientic, San Francisco, USA, 68–103. https:
//doi.org/10.18293/SEKE2018-149
[37]
Necmettin Ozkan and Mehmet Sahin Gok. 2020. Investigation of Agile Mindset
Elements by Using Literature Review for a Better Understanding of Agility. In
2020 Turkish National Software Engineering Symposium (UYMS). IEEE, İstanbul /
Turkey, 1–6. https://doi.org/10.1109/UYMS50627.2020.9247073
[38]
Kai Petersen, Sairam Vakkalanka, and Ludwik Kuzniarz. 2015. Guidelines for
conducting systematic mapping studies in software engineering: An update.
Information and Software Technology 64 (aug 2015), 1–18. https://doi.org/10.
1016/j.infsof.2015.03.007
[39]
Mariângela Pinton and Alvair Silveira Torres Junior. 2020. Human Aspects
of Agile Transition in Traditional Organizations. Journal of technology man-
agement and innovation 15, 3 (oct 2020), 62–73. https://doi.org/10.4067/S0718-
27242020000300062
[40]
Mary Sánchez-Gordón and Ricardo Colomo-Palacios. 2019. Taking the emotional
pulse of software engineering — A systematic literature review of empirical
studies. Information and Software Technology 115 (nov 2019), 23–43. https:
//doi.org/10.1016/j.infsof.2019.08.002
[41]
Mali Senapathi and Ananth Srinivasan. 2013. Sustained agile usage. In Proceedings
of the 17th International Conference on Evaluation and Assessment in Software
Engineering - EASE ’13. ACM Press, New York, New York, USA, 119. https:
//doi.org/10.1145/2460999.2461016
[42] Mohammad Shameem, Bibhas Chandra, Rakesh Ranjan Kumar, and Chiranjeev
Kumar. 2018. A systematic literature review to identify human related challenges
in globally distributed agile software development: towards a hypothetical model
for scaling agile methodologies. In 2018 4th International Conference on Computing
Communication and Automation (ICCCA). IEEE, India, 1–7. https://doi.org/10.
1109/CCAA.2018.8777533
[43]
SOFTEX. 2016. SPI General Guide for People Management - In portuguese. Softex,
Brazil. 50 pages. https://softex.br/mpsbr/guias/#guia-rh
[44]
Arjumand Bano Soomro, Norsaremah Salleh, Emilia Mendes, John Grundy, Giles
Burch, and Azlin Nordin. 2016. The eect of software engineers’ personality traits
on team climate and performance: A Systematic Literature Review. Information
and Software Technology 73, May 2016 (2016), 52–65. https://doi.org/10.1016/j.
infsof.2016.01.006
[45]
Sai Datta Vishnubhotla, Emilia Mendes, and Lars Lundberg. 2018. An Insight
into the Capabilities of Professionals and Teams in Agile Software Development.
In Proceedings of the 2018 7th International Conference on Software and Computer
Applications - ICSCA 2018. ACM Press, New York, New York, USA, 10–19. https:
//doi.org/10.1145/3185089.3185096
... The Information Systems (IS) area community shows growing interest in investigating human factors and their effects on agile software development teams , Ahmed et al. 2017, Ahmed et al. 2018, Kakar 2020, Dutra et al. 2021] and the organizational climate [Soomro et al. 2016, Serrador et al. 2018, Vishnubhotla et al. 2020, Dutra et al. 2021]. Curtis et al. [Curtis et al. 2009] suggested in the People Capability Maturity Model (P-CMM) that companies could use organizational climate surveys to identify each person's opinion on their working conditions. ...
... The Information Systems (IS) area community shows growing interest in investigating human factors and their effects on agile software development teams , Ahmed et al. 2017, Ahmed et al. 2018, Kakar 2020, Dutra et al. 2021] and the organizational climate [Soomro et al. 2016, Serrador et al. 2018, Vishnubhotla et al. 2020, Dutra et al. 2021]. Curtis et al. [Curtis et al. 2009] suggested in the People Capability Maturity Model (P-CMM) that companies could use organizational climate surveys to identify each person's opinion on their working conditions. ...
... In the Tertiary Study [Dutra et al. 2021], the authors identified 29 studies to review and summarize information about human factors. As a result, the authors identified 101 human factors that influence software development activities from different perspectives. ...
Article
Full-text available
Background: Trust, Knowledge, Learning, and Motivation influence the organizational environment of agile teams. Organizational climate surveys can provide concrete evidence of how the process, project activities, people, and culture work in practice. Using assessment climate instruments that do not consider agile values, principles, practices, and roles in a proper context may create difficulties in analyzing possible causes of problems and the execution of corrective actions within organizational climate management. Objective: We present a preliminary evaluation of TACT, which is an instrument to assess the organizational climate of agile teams, comprising four dimensions, Trust, Knowledge, Learning, and Motivation. Method: We planned and executed a case study considering eight development teams from three organizations. We evaluated TACT using open-ended questions, quantitative methods, and TAM dimensions of Intention to Use, Perceived Usefulness, and Output Quality. Results: TACT captured that the product owner's lack of knowledge and experience probably influenced the adverse climate in team trust and that unrealistic deadlines may have generated a lack of team motivation due to an absence of autonomy to plan the iteration. The team leaders reported intention of future use. Contributions and Impact in the IS area: TACT was grounded in scientific literature and industry observations. TACT items regarding Trust, Knowledge, Learning, and Motivation are grounded in the "agile philosophy'' and consider the most common agile practices. At the same time, it allows reflections on the behaviors of the prominent involved roles in agile projects. Based on the evidence gathered, we inferred that TACT captured the organizational climate of the teams correctly and can be used to identify issues better and improve actions aligned with the agile values, principles, and practices while developing Information Systems.
... Despite being an under-researched topic in SE, empathy is one of the human factors influencing software development activities [1,13,18] and is a required non-technical skill in the software development market [34]. The need for research addressing this topic was reinforced by Gunatilake et al. [18], who recently presented a preliminary taxonomy of empathy in SE. ...
... To answer the RQs, we performed a thematic synthesis [4] of GL [24]. We decided to use GL, as we found papers in SE scientific literature mentioning empathy as a relevant skill for software practitioners [1,13,34]. These papers cited the need for a proper taxonomy, but they did not investigate the topic as we did. ...
Conference Paper
Context: Empathy is the ability to understand and share the emotions of others. Despite its relevance for research and practice in software engineering, it is still an under-researched topic. Aims: To investigate the meaning, importance, practices, and effects of empathy from the perspective of software practitioners. Method: We apply a thematic synthesis of grey literature. We analyzed 22 articles from DEV, an online community used by software developers. Results: We found that empathy has different meanings for software practitioners. The word is used to express understanding, compassion, and perspective-taking, among other meanings. Practitioners consider empathy important, undervalued, needed, and wanted. The study points out 19 empathetic practices in SE, such as adopting good programming practices, understanding others, being compassionate, and being mindful. It also lists 28 effects of these practices, including quality improvement, better products, and build trust. Conclusion: We organize this body of knowledge in a framework supporting new research efforts. The framework may also support software professionals to develop empathetic skills in SE.
... It appears three times in our literature review, but one paper defined it clearly. In [19], the authors Table 3 Types and definition of corporal ownership in software engineering state of the art (RQ1). ...
Preprint
Full-text available
Effective ownership of software artifacts, particularly code, is crucial for accountability, knowledge sharing, and code quality enhancement. Researchers have proposed models linking ownership of software artifacts with developer performance and code quality. Our study aims to systematically examine various ownership models and provide a structured literature overview. Conducting a systematic literature review, we identified 79 relevant papers published between 2005 and 2022. We developed a taxonomy of ownership artifacts based on type, owners, and degree of ownership, along with compiling modeling variables and analytics types used in each study. Additionally, we assessed the replication status of each study. As a result, we identified nine distinct software artifacts whose ownership has been discussed in the literature, with "Code" being the most frequently analyzed artifact. We found that only three papers (3.79%) provided code and data, whereas nine papers (11.4%) provided only data. Using our systematic literature review results, we replicated experiments on nine priority projects at \texttt{Brightsquid}. The company aimed to compare its code quality against ownership factors in other teams, so we conducted a replication study using their data. Unlike prior studies, we found no strong correlation between minor contributors and bug numbers. Surprisingly, we found no strong link between the total number of developers modifying a file and bug counts, contrasting previous findings. However, we observed a significant correlation between major contributors and bug counts, diverging from earlier research.
... 3,4 It is also one of the key interpersonal capabilities for many software development roles, affecting team members' mindset and productivity. 5,6 Reduced empathy is associated with neurological disorders, failures of social cognition, impaired social perception, and abnormal social behavior, leading to poor quality of life, mental health problems, unemployment, and loneliness. 7 . ...
Article
Empathy is a human aspect essential for understanding and sharing the emotions of others. It is a critical ability for effective communication. In this article, we aim to highlight how practicing empathy in software engineering can impact software practitioners’ well-being and mental health. We pay special attention to the value of practicing empathy to learn, enhance, and refine this human skill. Our findings lead us to recommend that team members practice empathy by being mindful, being open, understanding others, and taking care, which can reduce blame, improve job motivation, prevent burnout, and create a better work environment. Our key takeaway is that empathy is an important skill for software practitioners, supporting them to build better products and improve their work environment.
... This effective collaboration links to improved decision quality [75], the promotion of valuable insights, and the facilitation of resolving complex challenges within a team context. Furthermore, collaboration to foster integrated perspectives in innovation [80]. In this sense, collaboration consists of working together, especially in an intellectual endeavor [81]. ...
... A study [13] identified 101 human factors and 79 influences influencing the individuals, the development team, and the software project activities. The authors concluded that the most investigated human factors in software development teams are: ...
... In accordance with the guidelines presented by Kitchenham and Charters [7], we conducted a tertiary study. In addition, we took inspiration from exemplary tertiary studies in SE (e.g., [3,5]). ...
Conference Paper
Full-text available
Context Bayesian networks (BNs) have been used to tackle several software engineering (SE) problems, such as risk management and effort estimation. They enable reasoning under uncertainty and have the advantage of incorporating expert knowledge to build more accurate models when sufficient historical data are not available. Software practitioners often encounter a lack of substantial evidence concerning the usability, limitations, risks, and benefits of BNs, as is the case with many other topics in the SE literature. Therefore, there is a need to organize and systematize the existing knowledge in this area. Objective This paper aims to provide researchers and practitioners with an overview of the techniques for building BNs in SE. Method We conducted a tertiary study following the guidelines available in the SE literature. Results We examined six secondary studies. Our findings revealed that expert knowledge emerges as the predominant technique for structure learning and, in conjunction with learning from data using automated tools, is widely employed for parameter learning in BNs. Conclusion Despite the attention given to data-driven approaches in SE, it is worth acknowledging the significant value that expert knowledge continues to hold in constructing more accurate and robust models. This observation underscores potential opportunities for developing expert-driven solutions to enhance model building and foster the adoption of BNs in the software industry.
Article
As society's reliance on software systems escalates over time, so too does the cost of failure of these systems. Meanwhile, the complexity of software systems, as well as of their designs, is also ever‐increasing, influenced by the proliferation of new tools and technologies to address intended societal needs. The traditional response to this complexity in software engineering and software architecture has been to apply rationalistic approaches to software design through methods and tools for capturing design rationale and evaluating various design options against a set of criteria. However, research from other fields demonstrates that intuition may also hold benefits for making complex design decisions. All humans, including software designers, use intuition and rationality in varying combinations. The aim of this article is to provide a comprehensive overview of what is known and unknown from existing research regarding the use and performance consequences of using intuition and rationality in software design decision‐making. To this end, a systematic literature review has been conducted, with an initial sample of 3909 unique publications and a final sample of 26 primary studies. We present an overview of existing research, based on the literature concerning intuition and rationality use in software design decision‐making and propose a research agenda with 14 questions that should encourage researchers to fill identified research gaps. This research agenda emphasizes what should be investigated to be able to develop support for the application of the two cognitive processes in software design decision‐making.
Article
Full-text available
In terms of productivity in software development, there is specific interest in identifying its influencing factors. For this purpose, several classification approaches have been previously used, which have already recognized technical factors, organizational factors, product factors, project factors, and personal factors. However, these approaches often focus on technical factors over social and human factors (SHFs). Nevertheless, in addition to the obvious technical aspects, the software development process involves problem-solving skills and cognitive aspects and social interaction. In this sense, determining SHFs can lead to software organizations designing strategies for improving team productivity. In this study, we first conducted a preliminary classification of the SHFs identified in the literature. Because this study seeks to assess the factors from the standpoint of software development professionals, we developed and validated an instrument to measure the perception of software development team members about SHFs that may be affecting their productivity. For this purpose, the first four stages of survey-based research were followed: objective definition, survey design, instrument construction, instrument validity, and reliability assessment. The instrument included 79 items assessing 13 different SHFs. After assessing both their validity and reliability, the results demonstrated that the instrument is a valid and reliable tool for measuring SHFs perception among software development team members.
Article
Full-text available
The agile transition is crucial for traditional organizations to remain competitive in the current market, which is characterized by a fast-pace and a constant need for innovation. In order to implement this transition, organizations must adjust their mindset to the new agile values. Despite its evident benefits, the transition to agile model is complex and time-consuming, posing many challenges to organizations. Since the agile philosophy is people-centered, rather than process-centered, most challenges are related to the human aspects of this transition and they demand a large transformation in all areas of the organization. This article provides a Systematic Literature Review (SLR) of the human aspects of agile transition and summarizes the existing literature into three categories: People, Management and Organization. Its main objective is to assist organizations undergoing agile transition in reducing risks related to this process, by acquiring knowledge on the challenges involved and implementing the proposed recommendations.
Chapter
Full-text available
Ensuring software quality is an important step towards a successful project. Since software development is a human-oriented process, it is possible to say that any factor affecting people will directly affect software quality and success. The aim of this study is to reveal which factors affect humans. For this purpose, we conducted a systematic literature review. We identified 80 related primary studies from the literature. We defined 7 research questions. For answering research questions, we extracted data from the primary studies. We researched human factors, methods for data collection and data analysis, publication types and years. Factors are grouped into 3 main groups: Personal factors, interpersonal factors, and organizational factors. The results show that personal factors are the most important category of human factors. It is seen that the most researched factors among personal factors are “experience” and “education”.
Conference Paper
The Agile Software Development movement itself emerged from practice just like most of the works in the Agile Software Development is evolved through practice. Thus, the creators and consultants of the Agile world may evangelize it with commercial concerns, resulting in "selling agility" to organizations as an object in a form of packaged practices (of methods/models/frameworks). As a result, agile mindset may easily lag behind the "sold" practices. However, effective agile individuals, teams and organizations require a particular attitude, way of thinking and behavior so called as agile mindset, beyond the given set of procedures, techniques and rituals, which makes it essential and primary before any practice (of any methods or frameworks). Despite its importance, the number of studies aiming to cover the elements of the agile mindset is surprisingly few, which calls for more study on this subject. By considering this gap and as an alternative to the limitations and monopoly of Agile Manifesto in being regarded as the dominant source of the mindset and to "selling agility" with a set of practices, this study provides the elements/factors/items of the agile mindset for a proper agility, by reviewing the literature to reach most comprehensive and up-to-date list, along with their categorization, relationships and discussions Thus, this study can serve as a basis to identify in what ways a particular entity (team, organization, or method) differs from the mindset.
Article
[Context] When conducting a Systematic Literature Review (SLR), researchers usually face the challenge of designing a search strategy that appropriately balances result quality and review effort. Using digital library (or database) searches or snowballing alone may not be enough to achieve high-quality results. On the other hand, using both digital library searches and snowballing together may increase the overall review effort. [Objective] The goal of this research is to propose and evaluate hybrid search strategies that selectively combine database searches with snowballing. [Method] We propose four hybrid search strategies combining database searches in digital libraries with iterative, parallel, or sequential backward and forward snowballing. We simulated the strategies over three existing SLRs in SE that adopted both database searches and snowballing. We compared the outcome of digital library searches, snowballing, and hybrid strategies using precision, recall, and F-measure to investigate the performance of each strategy. [Results] Our results show that, for the analyzed SLRs, combining database searches from the Scopus digital library with parallel or sequential snowballing achieved the most appropriate balance of precision and recall. [Conclusion] We put forward that, depending on the goals of the SLR and the available resources, using a hybrid search strategy involving a representative digital library and parallel or sequential snowballing tends to represent an appropriate alternative to be used when searching for evidence in SLRs.