![Summary of the employed onboarding strategy [12].](https://www.researchgate.net/profile/Ricardo-Britto/publication/342430983/figure/fig1/AS:914918584889344@1595144997434/Summary-of-the-employed-onboarding-strategy-12_Q320.jpg)
![The authority matrix [53] showing the maturity levels A-D.](https://www.researchgate.net/profile/Ricardo-Britto/publication/342430983/figure/fig2/AS:914918584885248@1595144997565/The-authority-matrix-53-showing-the-maturity-levels-A-D_Q320.jpg)
Content uploaded by Ricardo Britto
Author content
All content in this area was uploaded by Ricardo Britto on Jul 19, 2020
Content may be subject to copyright.
Evaluating and Strategizing the Onboarding of Software
Developers in Large-Scale Globally Distributed Projects
Ricardo Brittoa,b,∗
, Darja Smiteb, Lars-Ola Damma, J¨urgen B¨orstlerb
aEricsson AB, ¨
Olandsgatan, 371 73, Karlskrona, Sweden
bDepartment of Software Engineering (DIPT)- Blekinge Institute of Technology (BTH), 371
79, Karlskrona, Sweden
Abstract
The combination of scale and distribution in software projects makes the on-
boarding of new developers problematic. To the best of our knowledge, there
is no research on the relationship between onboarding strategies and the per-
formance evolution of newcomers in large-scale, globally distributed projects.
Furthermore, there are no approaches to support the development of strategies
to systematically onboard developers. In this paper, we address these gaps by
means of an industrial case study. We identified that the following aspects seem
to be related to the observed onboarding results: the distance to mentors, the
formal training approach used, the allocation of large and distributed tasks in
the early stages of the onboarding process, and team instability. We conclude
that onboarding must be planned well ahead and should consider avoiding the
aspects mentioned above. Based on the results of this investigation, we pro-
pose a process to strategize and evaluate onboarding. To develop the process,
we used business process modeling. We conducted a static validation of the
proposed process utilizing interviews with experts. The static validation of the
process indicates that it can help companies to deal with the challenges associ-
ated with the onboarding of newcomers through more systematic, effective, and
repeatable onboarding strategies.
∗Corresponding author
Email addresses: ricardo.britto@[ericsson.com, bth.se] (Ricardo Britto),
darja.smite@ericsson.com (Darja Smite), lars-ola.damm@ericsson.com (Lars-Ola Damm),
jurgen.borstler@bth.se (J¨urgen B¨orstler)
Preprint submitted to Journal of Systems and Software June 28, 2020
Keywords: Onboarding; Global Software Engineering; Large-scale software
development.
1. Introduction
Companies worldwide develop software in a globally distributed manner
(Global Software Engineering – GSE) to achieve benefits such as reduced time-
to-market and access to skilled people all over the world [1, 2, 3, 4]. However,
geographical, temporal, and cultural distances make coordination and commu-5
nication more challenging in GSE environments.
GSE projects often involve a large number of people (large-scale projects1)
and the scale amplifies the distribution-related challenges [5]. The combination
of scale and global distribution may lead to problems, such as more software
defects [6], and schedule and budget overruns [7].10
In addition to the challenges imposed by scale and global distribution, GSE
projects are often associated with the development of products with long life cy-
cles [8, 9]. Long life cycles are associated with large amounts of (often complex)
legacy code [8] and the onboarding of many different developers.
Onboarding of new developers (newcomers) may occur for different reasons:15
to replace retired developers, to replace developers that left the company for
another job, or to increase the existing workforce. Developers may also be re-
located within the company and, thus, onboarded to perform different types
of tasks that require new competence build-up. While developers may be on-
boarded at multiple occasions during the life cycle of a large-scale GSE project,20
the onboarding processes may be more challenging in this context, due to the
scale and distribution challenges mentioned above, and the difficulty to learn
and change legacy code [10, 11].
1Based on the findings of a systematic literature review, Dikert et al. define large-scale
software undertakings as the ones that involve at least 50 human resources – not necessarily
only developers, but also other staff collaborating in software development – or at least six
teams [5].
2
In our previous study [12], we investigated how the onboarding of software
developers was carried out in three different globally distributed industrial cases.25
We learned that the companies employed onboarding strategies that are semi-
formalized and that distance, distribution, and legacy code challenge the on-
boarding of software developers [12]. However, the performance evolution of
offshore newcomers onboarded in large-scale, globally distributed projects and
how it relates to the employed onboarding strategies remains an unanswered30
question.
To address the gap mentioned above, we dove deeper in one of the cases
investigated in our previous study [12]. More specifically, we selected a case from
Ericsson. The case is a large-scale software product that has been developed
over the last 20 years. We investigated the onboarding of software developers35
located in a remote site. We aimed at identifying how the performance evolution
of the newcomers relates to the employed onboarding strategy. Based on the
findings of this investigation and previous research conducted by us, we aimed
at developing a process to strategize and evaluate the onboarding of software
developers.40
In this paper, we address the following research questions:
•RQ1 - How does the performance evolution of newcomers relate to the
followed onboarding strategy in a large-scale globally distributed project?
•RQ2 - How can companies systematically strategize and evaluate the on-
boarding of software developers in large-scale, globally distributed projects?45
The main contribution of this paper is two-fold:
•Performance implications associated with the onboarding of offshore new-
comers in a large-scale globally distributed project.
•A process to support the development of onboarding strategies and eval-
uation of onboarding results.50
The remainder of this paper is organized as follows: Section 2 describes the
background and related work. Section 3 presents the research design. Section 4
3
presents the results of the exploratory study. Section 5 presents the developed
process, along with an illustration of its use. The results of a preliminary val-
idation of the process are presented in Section 6. A discussion is presented in55
Section 7. Validity threats are discussed in Section 8. Finally, a summary of
our conclusions and view on future work is provided in Section 9. Note that
this paper is an extension of our previous work [13]. While we have improved
our previous work as a whole, the main contribution of this paper is the process
that answers question RQ2.60
2. Background and related work
In large-scale distributed projects, the onboarding of software developers oc-
curs many times during a project’s life cycle. Given the known challenges that
are faced by developers in globally distributed software projects, onboarding de-
velopers in this context is also very challenging [12, 14, 15, 16]. In this section,65
we present some important concepts related to onboarding and related litera-
ture. Note that we have provided a very detailed background on onboarding to
facilitate the understanding of the process proposed in this paper.
2.1. Onboarding
Onboarding refers to the mechanism through which newcomers acquire the70
required knowledge, skills, and behaviors to become effective employees [17, 18].
Klein et al. [19] affirm that the research on onboarding can be divided into four
distinct perspectives:
•Stages through which newcomers progress [20, 21].
•Actors involved with the onboarding of newcomers [22, 23].75
•Tactics and practices employed by organizations for onboarding newcom-
ers [24, 18, 25].
•Content to be learned by newcomers during the onboarding [21, 26].
4
Considering that the main focus of this paper is on onboarding tactics and
practices and how they relate to the performance evolution of newcomers, we80
elaborate further on this perspective, describing the main models of onboarding:
Van Maanen and Shein’s model [18], Jones’ model [27] and Bauer’s model [24].
Van Maanen and Shein’s Model and Jones’ Model
Van Maanen and Shein [18] proposed a theoretical explanation regarding
role orientation in the context of onboarding. Jones’ model [27] was built upon85
Van Maanen and Shein’s Model [18].
The original model, proposed by Van Maanen and Shein, categorizes on-
boarding tactics in six dimensions:
•Collective vs. individual – Collective onboarding occurs when a group
of newcomers go through onboarding activities and acquire experiences to-90
gether (e.g., boot camps). Individual onboarding occurs when newcomers
go through separate from other newcomers (e.g., apprenticeship).
•Formal vs. informal – Formal onboarding relates to tactics in which
newcomers are segregated from other employees. In contrast, informal
onboarding relates to tactics that have no or little separation between95
newcomers and other employees.
•Sequential vs. random – Sequential onboarding refers to the extent to
which discrete steps regarding the onboarding phases are specified for the
newcomers. In contrast, random onboarding tactics do not specify any
sequence of steps.100
•Fixed vs. variable – Fixed onboarding occurs when there is a timetable
(fixed time) associated with each step of the onboarding process. In con-
trast, in variable onboarding, there is no time associated with the on-
boarding steps.
•Serial vs. disjunctive – Serial onboarding takes place when experi-105
enced employees serve as models for newcomers. In contrast, disjunctive
5
onboarding refers to the tactics wherein no guidelines or models are pro-
vided to newcomers.
•Investiture vs. divestiture – Investiture onboarding takes place when
the newcomers should keep their personal characteristics (own skills, val-110
ues, and attitudes). In contrast, divestiture takes place when an organi-
zation rejects and removes the personal characteristics of newcomers.
Jones [27] reduced the original six dimensions of Van Maanen and Shein’s
Model [18] to two:
•In institutionalized onboarding, there is a structured program, and new-115
comers receive formal orientation and mentoring. This dimension merged
the following dimensions from the original model: collective, formal, se-
quential, fixed, and serial investiture.
•In individualized onboarding, newcomers start working directly and
learn the norms, values, and expectations on-the-fly. This dimension com-120
bines the following dimensions: individual, informal, random, variable,
disjunctive, and divestiture.
Companies considered as successful regarding the onboarding of newcomers
have more formal onboarding programs (institutionalized onboarding) [25, 28,
29].125
Bauer’s Model
Bauer et al. proposed an onboarding model based on a series of empirical
studies [24, 30, 31, 17, 28]. It supports the design of onboarding programs,
capitalizing on the fact that institutionalized onboarding is more successful than
individualized onboarding [25, 28, 29].130
Bauer’s model has a finer grain level than the previous models than Van
Maanen and Shein’s and Jones’ models; it aggregates practices, techniques,
methods, and technologies (functions) that are related to successful onboarding.
We used Bauer’s model as part of the process proposed in this paper.
6
According to Bauer, onboarding has four distinct levels (Four Cs), which are135
the building blocks of successful onboarding [24]:
•Compliance is related to teaching employees basic legal and policy-
related rules and regulations.
•Clarification is related to ensuring that newcomers understand their new
jobs and related expectations.140
•Culture is related to providing newcomers with a sense of organizational
norms, including both formal and informal.
•Connection is related to the interpersonal relationships and information
networks that newcomers must establish.
The extent to which an organization focuses on each C determines its on-145
boarding strategy. The combination of functions (tools, practices, recommenda-
tions, performance goals, and measurement milestones) constitutes an onboard-
ing strategy, which is often formalized in an onboarding plan [24]. The success of
an onboarding strategy is related to short-term and long-term outcomes. Short-
term outcomes are associated with the adjustment of new employees to their150
new jobs [24]. Short-term results are related to high job satisfaction and low
turnover [28]. Long-term outcomes of onboarding are related to attitudes and
behaviors. Long-term successful onboarding is related to higher job satisfaction,
organizational commitment, low staff turnover, high performance levels, career
effectiveness, and low stress levels[24, 32, 33].155
Bauer [24] categorizes the onboarding functions as follows:
•Recruiting – In many organizations, recruiting is not integrated with the
onboarding plans and is treated as a separate function. However, exist-
ing literature [24, 17] shows that integration (e.g., through realistic job
previews or early involvement of stakeholders) gives candidates more ac-160
curate information about the company and the job. As a result, functions
of this category facilitate the adjustment of new employees, especially self-
efficacy, role clarity, and knowledge of culture [34].
7
•Orientation – Formal orientation programs help newcomers to under-
stand important aspects of their jobs and organizations, as the company’s165
culture and values [35]. Moreover, they also help newcomers feel wel-
come by presenting them to other individuals within the organization.
Computer-based orientation programs can help to keep consistency in the
program in different locations.
•Support tools and processes – Tools and formal processes are of great170
value for onboarding success. According to Bauer [24], there are three
tools/processes that are related to successful onboarding: a written on-
boarding plan, stakeholder meetings, and onboarding online.
•Coaching and support – Mentors can teach newcomers about the com-
pany, provide advice, and help with job instruction. According to existing175
research, new employees with mentors acquire more knowledge about their
new company than the ones without mentors [36]. Moreover, mentoring
programs and opportunities for informal interaction with colleagues help
the new employees to adapt more easily to the new work environment.
•Training – Training is essential to give the newcomers the confidence,180
clarity, and skills required for their job. Newcomers can receive training
in hard skills and soft skills.
•Feedback – Newcomers need regular feedback and guidance to under-
stand and interpret the reactions of their co-workers. Feedback can be
mainly provided in two ways [24]: performance appraisals and 360-degree185
feedback, wherein the new employees are evaluated and receive develop-
mental feedback; and employee-initiated information and feedback-seeking,
wherein the new employees proactively seek feedback.
2.2. Onboarding in Globally Distributed Projects
Studies with some relationship with the onboarding of newcomers in globally190
distributed projects often focus on comparing offshore teams with the original
8
experienced developers in the prime development location. Time to acquire the
required knowledge to perform as expected is of particular interest for compa-
nies that make decisions to onboard developers and teams in offshore locations.
Mockus and Weiss [37] studied individual developers working on non-trivial195
modification requests and found that offshore developers may reach full produc-
tivity in approximately 15 months, after three months of project training before
the actual work. Perception-based studies and experience reports suggest that
the learning process may take from 12 months [38], up to three [39] and five
years [40, 41] or even longer [42], leading to longer onboarding than in collocated200
projects.
Most research related to onboarding/team performance either focuses only
on the performance of teams in distributed projects or on how developers are
onboarded, but not in how both things relate to each other or how developers
can be onboarded systematically.205
Researchers have compared productivity or quality performance of collocated
and distributed teams, as summarized by Nguyen-Duc et al. [43]. The results of
their study suggest that geographical dispersion harms team productivity [44]
and software quality [45, 46, 47]. Another relevant finding of studies in this line
of research is that it may take long periods for developers in offshore sites to210
achieve full productivity [37, 48]
Some studies focused on the role of mentoring when onboarding newcomers.
They identified that this practice relates to more active newcomers when they
start contributing to open source projects [15, 14], although it may not be
enough to ensure they provide to those projects in the long run [49]. It may215
also support overcoming many challenges that are faced by newcomers when
they start contributing to open source projects [50, 51]. Mentoring and support
are also related to successful onboarding [52]. It was identified as indispensable
to onboard newcomers on offshore locations in globally distributed projects with
a high amount of complex legacy code [53, 12]. Mentoring and peer-learning220
was also identified as an effective practice to avoid the isolation of newcomers,
improving their job satisfaction [54].
9
Another vein of research focuses on holistically researching onboarding. Em-
pirical evidence shows that some onboarding practices are planned and executed
locally, making it hard to avoid onboarding strategy fragmentation in projects225
with multiple sites [12].
In summary, existing literature shows that:
•Newcomers face many barriers before they can start working.
•To support overcoming the challenges faced by newcomers, mentoring
seems to be a good practice as it is related to successful onboarding. It230
also promotes learning, which is essential for newcomers to achieve proper
levels of performance.
•Together with practices such as mentoring, literature shows that more
time is required to onboard newcomers in globally distributed projects,
and it may be hard to keep control of how newcomers are onboarded in235
projects with many sites.
•There are no approaches to support the systematic development of on-
boarding strategies in globally distributed projects.
Although existing literature suggests that onboarding of developers in glob-
ally distributed projects is more challenging than in other contexts (as detailed240
above), many of the studies related to performance in global software projects
have focused on comparing distributed teams to collocated teams. In contrast,
the number of longitudinal studies of performance evolution of newcomers on-
boarded in remote locations is still scarce. Moreover, none related work in-
vestigated the implications of the employed onboarding strategies to the per-245
formance evolution of newcomers in large-scale, globally distributed projects.
Finally, there are no approaches to support the development of strategies to on-
board developers/teams and systematically evaluate onboarding results, which
is found as very important to be successful when carrying out the onboarding
of other roles (e.g., managers) [24]. This paper fills these gaps. Finally, The250
context of large-scale software pro jects involving a large amount of legacy code
10
adds an original perspective, which has not been addressed explicitly in GSE
onboarding/performance-related studies before.
3. Research design
To address RQ1, we have conducted an exploratory longitudinal case study255
[55]. To address RQ2, we employed business process modeling (BPM) to create
a process. In this section, we describe the case and the research design of our
investigation.
3.1. The case and unit of analysis
We selected the case investigated in this paper through convenience sampling260
in consultation with Ericsson representatives as a case suitable to answer our
research question. The other cases investigated in our previous study [12] were
not included in this investigation due to the lack of quantitative data.
The selected case and unit of analysis is a large-scale distributed endeavor
associated with the development and maintenance of a large telecommunication265
software product in Ericsson. Its degree of distribution increased significantly
during the period covered in our investigation. The product originated in Swe-
den and has evolved for more than 20 years; it comprises a considerable amount
of complex legacy code. It was subject to many technical and methodological
changes over the years (e.g., the introduction of agile practices).270
Offshore locations were added to address the growing demands for resources
and to implement market-specific customizations (USA, Italy, China, Turkey,
India, and Poland). The developers in India and Poland were onboarded later
in the product life cycle. The sites in China and Turkey were closed down due to
business reasons and are not included in the analysis. The company transferred275
the primary responsibility for the product to India in 2017.
The software development teams are cross-functional and use agile practices
in their daily work (e.g., daily stand meetings, sprints, and continuous integra-
tion). The teams have four to seven developers and receive tasks that can be
11
product customizations, maintenance, product improvements, standardizations280
of market features, and business use cases. Each task resembles an independent
project with a specific start and end date and expected results. One or more
development teams are assigned to each task.
We based our analysis on a subset of the collected data, focusing on product
customization tasks carried out by newcomers located in India. We chose prod-285
uct customization tasks mainly because it was the only task type for which we
were able to track performance (productivity and autonomy), due to the avail-
ability of the data. External customers drive product customization tasks, and
this demands a stricter effort/cost control by Ericsson, i.e., the associated data
is audited regularly. Furthermore, Product customization tasks are adequate290
for this study because the newcomers mainly work with this type of task (90%
of the work done by the newcomers at the time of our investigation).
We also used data from experienced teams located in the USA and Italy as
a benchmark and to establish the performance goals for the newcomers. We
did not include tasks carried out by newcomers from other locations due to295
two reasons: i) The newcomers located in Poland never worked with product
customization tasks; ii) The teams located in Sweden, Italy, and the USA had
been onboarded too long ago. This made it difficult to collect reliable data
since part of our measurement approach depended on expert knowledge; people
involved with those teams either had left Ericsson or were not able to recall300
sufficient details regarding the product customization tasks.
The newcomers onboarded in India had worked in the case for approximately
two years by the time we finalized the data collection process. The newcomers
were onboarded in three main waves: 11 newcomers in August 2014, seven
newcomers in January 2015, and 10 newcomers in August 2015. Due to this305
multi-phased onboarding, the product customization tasks were never fulfilled
by the same team of developers; the tasks were always conducted by an ad-hoc
team formed by the available developers at a given point in time. Thus, we
analyzed the tasks in chronological order to identify how the performance of
the newcomers evolved. Note that while the three onboarding waves increased310
12
the total number of developers, it also replaced developers that were either
reallocated to other products or left the company during the investigated period.
Figure 1 presents the onboarding strategy employed to onboard the new-
comers in India. Given the distributed nature of the project, some parts of the
employed onboarding strategy were organized by the central project stakehold-315
ers in Sweden. In contrast, others occurred remotely and were handled by the
local management.
The recruitment of the new employees was organized by the Indian site
individually, while the demanded skill profiles were formulated in Sweden. The
company does not provide realistic job previews; however, senior developers (if320
any) participate in the recruitment process and the evaluation of new candidate
developers.
The orientation of new developers is carried out informally, i.e., there is no
formal orientation program. In general, the newcomers are given one week at
the new job to familiarize themselves with the new environment, get to know325
the key people and co-workers (socialization), and acquire the basics about the
existing ways of working. The way it is done depended on the number of people
being onboarded: individual orientation when a few developers (less than three)
are onboarded and group level orientation when many developers are onboarded
(the case in the three main onboarding waves).330
The employed learning process is mainly based on autonomous learning. The
new developers receive, on average, three months of formal training about the
product. Most of the learning is based on doing actual work. Senior developers,
mainly software architects located in Sweden, are assigned as mentors [53]. The
first wave of newcomers received training and mentoring on-site in Sweden for335
the initial five months. The second wave received training and mentoring in
India for four months from two visiting senior developers from Sweden. Finally,
the third wave just received remote mentoring, provided by software architects
located in Sweden.
The company also uses other resources to make the onboarding of new de-340
velopers successful. For each developer, an Excel spreadsheet was used to track
13
their progress regarding the competence they must acquire. This spreadsheet
also contains the primary source of knowledge they can use to obtain the re-
quired expertise. It is also used by immediate managers and mentors to fol-
low the progression of new developers. Another tool is the corporate intranet,345
wherein documents about the ways of working and the product are available,
and which is maintained centrally.
The newcomers receive continuous feedback on their work outcomes through
code reviews. Local senior developers (if any) and software architects located in
Sweden not only evaluate the performance but also transfer product knowledge350
to support the new developers. Based on the received feedback, newcomers may
require more formal training. At the same time, the status of performance is
used by the immediate managers locally to identify whether or not a newcomer
needs more support. Such checks are performed together with the mentors
weekly. Code reviews also serve as a track record used in permanent employment355
considerations.
3.2. Variables
In an ideal scenario, successfully onboarded software developers should be
able to develop software autonomously, delivering code efficiently and effectively.
All of this should be achieved in the shortest period possible. Thus, to inves-360
tigate the performance evolution of newcomers holistically, one should look at
how the productivity, autonomy, cost efficiency, and deliverables’ quality asso-
ciated with newcomers evolve. In our case, the available data only enabled us
to focus on the productivity and autonomy of the newcomers.
In this paper, we used the measurement approach detailed in Britto et al.365
[56], which evolved during this investigation. We accounted for the following
variables in our investigation (all variables use a ratio scale):
•Task size T is measured in complexity points and takes into account a
task’s extent and complexity to make tasks of different degrees of com-
plexity easier to compare (Unit: Complexity Points). Tiis the size of task370
15
iand Tki is the size of the proportion of task ithat was completed by
team k. Note that task size is measured using a group estimation process,
which involves senior software architects.
•Team productivity P represents the effort that a team spends to com-
plete a complexity point (Unit: Complexity Points/1000 Hours). Pki is375
the productivity of team kon task i:
Pki =Tki
Eki
(1)
where Eki is the total effort spent by team kon task i. The effort is
obtained from time reports.
•Team autonomy A represents how independently a development team
fulfills a task (Unit: Complexity Points/Hours). Aki is the autonomy with380
which team kcarried out task i:
Aki =Tki
Mh
ki + 1 (2)
where Mh
ki is the effort in work hours spent by software architects providing
mentoring and help to team kduring the fulfillment of task i. The effort
was obtained from mentoring time reports. Note that 1 is added to the
denominator of Equation to avoid division by zero (numerical stability).385
3.3. Data collection
In total, we collected data from 24 product customization tasks related to the
developers onboarded in India2. Furthermore, we collected data related to nine
product customization tasks carried out by mature developers located in the
USA (4) and Italy (5), for benchmark purposes. The data encompasses tasks390
carried out between August 2014 (inception of the Indian site) and October
2016. To collect the data, we conducted semi-structured interviews, archival
2Note that we cannot share the data collected and analyzed in this paper under the non-
disclosure agreement signed by the authors.
16
research, and workshops. All interviews and workshops were carried out in
person in Sweden, except for one interview conducted with a senior developer
located in the USA (via Skype).395
Five of the 24 tasks carried out by the newcomers involved the participation
of mature developers from other locations. The other 19 tasks were only fulfilled
by the newcomers in India with mentoring provided by senior developers or
software architects from Sweden. The mentoring was mainly provided by means
of design workshops and code reviews. Table 1 describes the collaborations400
involved in the five distributed product customization tasks.
Archival research
A large amount of the data used in our investigation was collected through
archival research. The mined data sources, with associated metrics and vari-
ables, are described in Tables 2 and 3. We aggregated all the data, which was405
verified through workshops and interviews.
Workshops
We conducted six workshops to assess the complexity of the investigated
tasks and verify (sanity check) the data collected through archival research.
The workshops took place in 2016, between January and October. Six to eight410
software architects attended them. Each workshop took approximately 1.5 h.
The participants’ experience in the investigated product ranged from five to 15
years. All workshops were conducted jointly by the first and third authors of
this paper.
In the first workshop with the architects, we defined and piloted the process415
to measure task complexity. It was consensus among the software architects
that existing complexity metrics (e.g., cyclomatic complexity and lines of code)
do not account for all the complexity related to product customization tasks in
this product. Together with the software architects, we defined the following
process to measure task complexity:420
1. At the beginning of each workshop, the software architects selected one
17
Distributed
Task
Main
Location
Maturity
Level
Collaboration
Setup
Locations
involved
Task 1 India Imma-
ture
Two independent
teams
India and
Sweden
Task 3 India Imma-
ture
Two independent
teams
India and
Italy
Task 9 India Imma-
ture
Virtual team with
developers located
in India and one
software architect
located in Sweden
India and
Sweden
Task 17 India Imma-
ture
Virtual team with
developers located
in India and one
software architect
located in Sweden
India and
Sweden
Task 18 India Imma-
ture
Virtual team with
developers located
in India and one
software architect
located in Sweden
India and
Sweden
Table 1: Distributed product customization tasks.
18
Data
source Description Variables
Task
time
report
spread-
sheets
Documents that contain the
developers and design leads
involved in finished tasks, in
addition to the actual effort
spent by them to carry out
the tasks.
We extracted team setup,
number of developers, and
task effort (Ei). We used
this data to calculate team
productivity (Pi) and to
support the identification of
a team’s contribution to
distributed tasks.
Mentor-
ing time
report
spread-
sheets
Documents that contain the
architects and the hours they
spent to support teams
during the fulfillment of
tasks.
From this type of document,
we extracted the architects
involved with each task and
the respective mentoring
hours (Mki ). We used this
data to calculate team
autonomy (Ai).
Slot-plan
spread-
sheets
Documents that contain the
planning information related
to developers assigned to
particular work items. These
spreadsheets helped to
identify the start and end
dates of the tasks.
We used slot-plans to
confirm the team setup
identified through the time
report spreadsheets.
Table 2: Archival research data sources - part I.
19
Data
source Description Variables
Human
resource
manage-
ment
reposi-
tory
Repository that contains
information about personnel
involved with the selected
case.
From this data source, we
extracted data regarding
the experience of developers
and software architects.
Code
reposi-
tory
Configuration management is
carried out using Git in the
selected case.
We extracted lines of code
associated with each task,
which were used to support
the sanity check carried out
regarding task complexity
(Ci).
Product
architec-
ture
specifica-
tion
Document that contains the
description of the product
architecture and its main
components.
It was used to support the
measurement of task
complexity (Ci).
Solution
specifica-
tions
Documents that contain
details about solution design.
It was used to support the
measurement of complexity
(Ci).
Table 3: Archival research data sources - part II.
20
task, and the other tasks were to be measured concerning it.
2. For each task, the software architects attributed a positive integer number
(complexity points) using a planning poker-based approach.
3. To check the assigned measures, the software architects consulted solution425
specification documents, the product architecture specification, and the
product source code whenever needed.
The task complexity measurement took place from the second to the sixth
workshop with the software architects. The results were recorded in a spread-
sheet.430
In the sixth workshop with the architects, we also conducted a data sanity
check to validate both the assessed task complexity and the plots about perfor-
mance evolution. It was based on summaries and plots of the collected data,
including lines of code and task complexities. We asked the architects to pro-
vide explanations for the outliers. They realized they had not accounted for435
non-functional testing in two product customization tasks. As a consequence,
they increased the amount of task complexity points associated with these two
tasks. We kept notes about the developers’ comments on the performance evo-
lution results.
An additional workshop took place with the participation of five developers440
onboarded in India. The workshop took one hour and 20 minutes and was held
in November 2016. We conducted this workshop with developers who spent
three months in Sweden as part of the fulfillment of one product customization
task. The experience of the participants in the investigated product ranged from
1.5 to 2.5 years.445
We asked the participants to provide information about the challenges they
faced to achieve high performance. The developers were asked to write down,
independently of each other, the problems that, in their opinion, impacted their
learning processes. After 10 minutes, individual ideas were discussed within the
group.450
21
Semi-structured interviews
We conducted individual semi-structured interviews with three software ar-
chitects in 2016 between April and October. Each interview took approximately
one hour. The interviewees had from 5 to 15 years of experience in the investi-
gated product. The first author of this paper conducted all interviews.455
The main objectives of the interviews were:
•To identify teams’ contribution to the distributed product customization
tasks’, and how much mentoring and help these teams received by software
architects. We used this information to adjust Tifor tasks that involved
several teams (Tki).460
•To collect additional information about the challenges the newcomers
faced to achieve high performance (high productivity and autonomy).
We also conducted one semi-structured interview via Skype with a senior
developer located in the USA. He had more than ten years of experience in the
investigated product by the time of our investigation. The interview took 30465
minutes and was conducted in September 2016. The main goal of this interview
was to get the view of an experienced developer about the challenges newcomers
face to achieve high performance in the product under investigation.
In all interviews, we took notes to facilitate post-interview analysis. The
notes included key points related to the questions that were posed during the470
interviews. The notes were discussed with the respective interviewees to ensure
that they reflected what was discussed during the interviews.
3.4. Data analysis
The data analysis involved quantitative and qualitative methods. To quan-
titatively evaluate the performance evolution of the newcomers, we employed475
Locally Weighted Scatterplot Smoothing (LOWESS) plots [57]. This approach
is adequate to identify trends in a dataset with a small number of observa-
tions than traditional linear regression analysis, which demands a considerable
22
amount of observations [58, 59]. Furthermore, we employed a Wilcoxon-Mann-
Whitney and the Vargha-Delaney A measure [60] to test for statical differences480
and calculate the effect sizes, respectively.
To analyze the qualitative data from the workshops and interviews, we fol-
lowed the coding process described by Robson and McCartan (open coding)
[61].
We conducted three iterations of coding. In the first iteration, we employed485
a deductive approach, i.e., we used the functions described in Bauer’s model
(see Section 2) to link the employed onboarding strategy and the observed per-
formance evolution of the newcomers. This was done by coding the interviews
and workshop notes, which resulted in identifying two onboarding functions
(mentoring and training).490
In the second iteration, we screened the notes again to identify issues as-
sociated with the functions identified in the first coding iteration. As a result,
we identified one item associated with mentoring (distance) and two problems
related to training (expectation misalignment, on-the-job training with complex
tasks, and on-the-job training with distributed tasks).495
In the third iteration, we combined the initial onboarding function codes
with the issue codes identified in the second iteration. The final result includes
the three issues reported in this paper (the distance to mentors; the formal
training approach used, which did not fit the socio-cultural background of the
newcomers; allocation of large and distributed tasks in the early stages of the500
onboarding process). Note that a fourth issue (team instability) was identified
during the quantitative analysis.
All the iterations were conducted by the first author and reviewed by the
second author.
3.5. Business process modeling and static validation505
To answer RQ2, we packed the findings from our exploratory study reported
herein together with the findings and solutions reported in our previous research
[62, 56, 53, 12]. To develop the process, we used BPM [63]. The resulting process
23
provides a systematic way to strategize onboarding undertakings and evaluate
onboarding results.510
BPM is the activity of representing the business processes of an organization
[64]. A business process is defined as the combination of related activities to
achieve a specific goal (e.g., product or service). A business process can be used
to improve or facilitate the learning of existing processes. According to von
Rosing et al., there are three main types of business processes [64]:515
•Management processes – Processes such as corporate governance, and
strategic management, which govern the operation of an organization.
•Operational processes – Processes like purchasing, manufacturing, mar-
keting, and sales, which are the core business of an organization and create
the primary value stream.520
•Supporting processes – Processes such as accounting, recruitment, and
onboarding, which support the core business of an organization. This is
the type of process proposed in this paper.
To carry out the process modeling, we followed these steps:
1. From our previous research [62, 56, 53, 12]3and the exploratory study re-525
ported herein, We identified relevant activities to support the development
of onboarding strategies and evaluation of onboarding results.
2. We identified additional activities or artifacts required to enable a coherent
process flow.
3. We combined all activities, defining the appropriate sequence for their530
execution and resulting artifacts.
4. We received informal feedback about the process from a domain expert
(an Ericsson RD manager with more than 15 years of experience).
5. We conducted a static validation [65] of the process by asking experienced
Ericsson R&D managers to answer a questionnaire.535
3Note that these studies were conducted in the order presented here.
24
In Ericsson, there are two main types of managers: R&D managers and
project managers. We selected R&D managers to participate in our static val-
idation because they are the ones responsible for planning and executing the
onboarding of newcomers.
To conduct the static validation, we first presented the process to 20 R&D540
managers (1-hour session). Then, we gave a questionnaire to the managers.
Each manager had two weeks to provide their own answers, although some of
the managers took more than two weeks to provide their input. In the end, nine
managers from three different Ericsson products answered the questionnaire.
All nine respondents had more than ten years of experience.545
The questionnaire had the following questions:
Q1 - Provide your opinion on each of the components of the process with respect
to their relevance when onboarding new developers. Mark your choice by writing
“Yes” in the cell of your choice.
Component Strongly
Agree Agree Unde-
cided Disagree Strongly
Disagree
Define
Onboarding
Context
Strategize
onboarding
using
adequate
practices
Evaluate
onboarding
results
Store and use
knowledge
from previous
onboarding
undertakings
Q2 - In your opinion, what are the benefits of using the proposed process?550
(Open-ended question)
25
Q3 - What are the drawbacks/limitations of the process? How can we im-
prove/revise the process? (Open-ended question)
Q4 - Are there steps that should be removed from the process? If yes, then
kindly list those items here and also state why do you recommend removing555
them? (Open-ended question)
We calculated the frequency of the answers associated with each process com-
ponent’s relevance (Q1). We evaluated the responses related to the open-ended
questions and selected relevant quotes. The results are presented in Section 5.
4. Results and interpretation of the exploratory case study - RQ1560
In this section, we present and interpret the results associated with RQ1.
We first show the findings related to the newcomers’ performance evolution.
Second, we show how the observed performance evolution results relate to the
employed onboarding strategy.
4.1. The newcomers’ performance evolution565
Productivity
The productivity goal for the newcomers was defined based on the produc-
tivity of senior software developers located in the USA and Italy. The results
show that the newcomers never reached the productivity goal. The maximum
productivity achieved by the newcomers was 46.44 complexity points per 1000570
hours (CP). On average, the senior developers were 3.57 times more productive
than the newcomers. i.e., the maximum observed productivity of the senior de-
velopers (120.07 complexity points per 1000 hours) was 2.59 times bigger than
the maximum observed newcomers’ productivity. Even the minimum observed
senior developers’ productivity (58.41 complexity points per 1000 hours) was575
bigger than the maximum newcomers’ productivity.
Figure 2 shows how the newcomers’ productivity evolved during the investi-
gated period. The x-axis shows the delivery date for each investigated product
26
customization task. In contrast, the y-axis shows the productivity for the re-
spective tasks4(in CP).580
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Task−16
Task−11
Task−8
Task−10
Task−24
Task−12
Task−15
Task−9
Task−4
Task−3
Task−5
Task−22
Task−2
Task−7
Task−13
Task−1
Task−23
Task−14
Task−18
Task−6 Task−17 Task−21
Task−20
Task−19
−10
0
10
20
30
40
50
15/02
15/03
15/04
15/05
15/06
15/07
15/08
15/09
15/10
15/11
15/12
16/01
16/02
16/03
16/04
16/05
16/06
16/07
16/08
16/09
End Date
Team Productivity
Figure 2: Productivity evolution for the newcomers (24 tasks). The tasks highlighted in blue
involved more than one development site (see Table 1 located in Section 3.3 for more details).
The gray area means the confidence interval associated with the line generated using LOWESS
(see Section 3.4 for more details).
Although the productivity varied a lot, it is possible to see that it increased
initially and peaked after about six months (August 2015 – 1508). The produc-
tivity then decreased gradually during about eight months to finally return to
the top-level of the first year at the end of the second year.
It is possible to see in Figure 2 that the newcomers had their best perfor-585
mance when they were not required to work on tasks in collaboration with teams
located on other sites. The results show that the average productivity of the
4In Figures 2, and 4.1, the tasks with a blue label (1, 3, 9, 17 and 18) were conducted in
a distributed fashion. They are described in more details in Table 1.
27
newcomers in those tasks is 3.11 (median 3.52) times higher than their pro-
ductivity in tasks wherein they collaborated with teams located on other sites
(tasks 1, 3, 9, 17 and 18, blue in Figure 2).590
We applied the Wilcoxon-Mann-Whitney test and identified that the differ-
ence mentioned above is statistically significant (p-value = 1.37E−03). We also
used the Vargha-Delaney A measure to calculate the effect size of distribution
on productivity. The resulting A measure is equal to 0.94, i.e., 94% of the time,
the newcomers had a better productivity in tasks where they did not collaborate595
with teams located on other sites.
Autonomy
The autonomy goal for the newcomers was defined based on the autonomy of
senior software developers located in the USA and Italy (autonomy in relation
to the main site of the case, which was located in Sweden). The results show600
that the newcomers never reached the autonomy goal. On average, the senior
developers are 1.67 times more autonomous than the newcomers.
Although the newcomers did not evolve much concerning their productivity,
they became more independent. This is showed by the maximum observed
autonomy achieved by them (1.32), which was very close to the maximum605
observed autonomy of the senior developers (1.46).
Figure 4.1 shows how the newcomers’ autonomy evolved during the inves-
tigated period. The x-axis shows the delivery date for each investigated prod-
uct customization task, while the y-axis shows autonomy for the corresponding
tasks. Compared to Figure 2, we can see that the variation of autonomy over610
time is smaller than the change in productivity. We can observe an initial in-
crease in autonomy. After that, we have a year-long period of stagnation. In
the last five months (from June 2016 onwards), we can see a further increase in
autonomy.
In relation to how the tasks were fulfilled (with or without global distribu-615
tion), there is no apparent difference regarding autonomy in Figure 4.1. The re-
sults show that the average autonomy of the newcomers in tasks without global
28
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
Task−16
Task−11
Task−8
Task−10
Task−24
Task−12 Task−15
Task−9
Task−4
Task−3
Task−5
Task−22
Task−2
Task−7
Task−13
Task−1
Task−23
Task−14
Task−18
Task−6
Task−17
Task−21
Task−20
Task−19
0.0
0.5
1.0
15/02
15/03
15/04
15/05
15/06
15/07
15/08
15/09
15/10
15/11
15/12
16/01
16/02
16/03
16/04
16/05
16/06
16/07
16/08
16/09
End Date
Team Autonomy
Figure 3: Autonomy evolution of the newcomers (24 tasks). The tasks highlighted in blue
involved more than one development site (see Table 1 located in Section 3.3 for more details).
The gray area means the confidence interval associated with the line generated using LOWESS
(see Section 3.4 for more details).
29
distribution is 1.69 (median 1.90) times higher than in globally distributed
tasks (tasks 1, 3, 9, 17 and 18, blue in Figure ). However, after applying the
Wilcoxon-Mann-Whitney test, we identified that this difference is not statisti-620
cally significant (p-value=0.1).
4.2. The relationship between the observed performance evolution and the em-
ployed onboarding strategy
As mentioned above in this section, the newcomers did not achieve the es-
tablished performance goals; the observed productivity was far from the target,625
while the perceived autonomy evolved more than the productivity and got closer
to the respective goal.
As shown in Section 3, the Indian site started with 11 developers in August
2014. In January 2015, seven developers were added (a total of 18 develop-
ers), followed by another ten developers in August 2015 (a total of 28 devel-630
opers). Furthermore, ten developers were added to replace developers that left
the project (three left in the first half of 2015 and seven in the second half of
2015). The onboarding of new developers meant that there were a large number
of newcomers who needed training and mentoring, which may explain why the
productivity of the newcomers did not evolve as expected.635
A factor that seems to have amplified the challenges imposed by staff turnover
is the employed mentoring approach. The most substantial productivity im-
provement occurred when the first wave of newcomers was trained and men-
tored on-site in Sweden (between August 2014 and January 2015) and when
two senior developers from Sweden traveled to India to provide on-site men-640
toring in India (between February and May 2015). From June 2015 onward,
the newcomers received only remote mentoring by software architects located
in Sweden. This matches the period wherein their productivity goes down in
Figure 2. While remote mentoring is better than no mentoring, the results show
that the newcomers performed best when they received on-site mentoring.645
Regarding autonomy, at first glance, the stagnation period seems counter-
intuitive. It is fair to assume that the addition of new developers, together with
30
remote mentoring, should have called for more mentoring hours because of the
inefficiency of remote communication. In contrast, we found that the newcomers
perceive the mentoring functions less accessible and often do not reach out for650
help that often. This might also explain why productivity went down since the
knowledge gap that was compensated by the short-term involvement of software
architects later consumed more effort from the newcomers.
So, how does the observed performance evolution relates to the employed on-
boarding strategy? We learned that the choice of having remote mentoring655
seems to have negatively impacted performance evolution (especially productiv-
ity). A software architect confirmed this: “I believe that the reason the newcom-
ers in India are struggling is that the product is complex to learn, and it is tough
for us to help them just using code reviews, emails, and Skype”. A newcomer
also mentioned this as a challenge: “Since we didn’t get that much training about660
the product before starting working, we have to keep learning stuff. The two pri-
mary sources we have are the software architects and documentation. However,
the architects are in Sweden, which complicates the communication with them,
and the documentation sometimes does not have everything, and it is hard to
find the required knowledge.”665
The software architects provided a large amount of feedback to the new-
comers through code reviews. They did this to mitigate the challenges of com-
municating over a distance. However, as a newcomer commented, geographical
distance and temporal distance affect how code review is operationalized: “We
learn a lot from the feedback we get from code reviews. However, sometimes670
it takes quite a while to get the feedback, because the experienced reviewers are
located either in Sweden or the USA. ”
The use of code reviews instead of rich communication media also affected
the intensity of connection between the newcomers and software architects. We
found that videoconferencing is used only for critical tasks and during critical675
phases. Status meetings were held twice per week for high priority tasks and
to deal with task software design matters. A newcomer highlighted that he
would like to have more videoconference meetings to support their onboarding:
31
“I believe that we should have more videoconferences. For example, during the
time we spent in Sweden, things worked much better because we could talk to680
the architects any time to clarify any doubt about the product. More frequent
videoconferences would allow us to have more frequent feedback.”
Another aspect of the employed onboarding strategy seems to have also neg-
atively impacted performance evolution: The poor fit of the formal training
and the newcomers’ expectations. The main site of the case (located in685
Sweden) employs a learning process mainly based on autonomous learning, i.e.,
newcomers do not have the entire required knowledge before starting real work.
While this approach worked well in Sweden, the USA, and Italy, it seems to chal-
lenged the newcomers onboarded in India. Although the teams located in India
received more formal training than the teams located in other locations (e.g.,690
USA, Sweden, and Italy), their general perception is that it was still insufficient.
One possible explanation for this could be rooted in the cultural differences
[66]. The learning-by-doing approach used in during the onboarding of newcom-
ers expects pro-active learners and might have clashed with the expectations of
the Indian newcomers. This misalignment or perceived “lack of training” seems695
to harm their performance evolution as mentioned by one of the newcomers:
“We just get a very short training about the product before starting doing the
work. It is more like a helicopter view, and we just learn something when we
start working. In addition, we don’t get enough training in the used technologies.
This for sure impacts how we learn and how we work.”700
An aspect that apparently amplified the problems mentioned above is the
amount and complexity of the legacy code associated with the product developed
in the investigated case. The product includes several subsystems and comprises
millions of lines of code, including a significant amount of legacy code that was
accumulated during more than 20 years of development. Most interviewees705
emphasized that the product size and complexity makes it challenging to learn
and to work with. For example, a senior developer located in the USA site
mentioned: “The product is very complex. Although I have been working in
this product for more than ten years, there are parts that I still don’t have
32
enough knowledge about to do things independently.” One of the newcomers also710
highlighted the product complexity: “We have been working with the product for
more than two years and we just managed to have a reasonable understanding
regarding just one of its main modules.”
In addition to legacy code complexity, the product also involves many dif-
ferent technologies, which in some cases are company-specific. This means that715
the newcomers also needed to deal with a complex set of technologies, making
the process of acquiring the required knowledge particularly tricky. One new-
comer pointed out that because some of these technologies are Ericsson-specific,
it reduces the sources from where newcomers can acquire the required knowl-
edge (e.g., it is not possible to use commonly used sites like Stack Overflow5to720
learn about these technologies): “The product involves a huge technology stack.
Besides, some of the used technologies do not have comprehensive support from
the community outside Ericsson. This means that we depend only on internal
people to learn about this type of technology.”
The innate complexity of the product and the strategy of involving early725
on the newcomers in some large complex globally distributed tasks
seems to have made the onboarding process more difficult, contributing to the
observed performance evolution.
Finally, another aspect that also seems to have negatively affected the new-
comers’ performance evolution was the decision of not keeping the newcom-730
ers in stable formal teams (team instability). As mentioned before, none of
the tasks was carried out by the same constellation of developers. Team insta-
bility is a known hindering factor for group learning and affects the performance
of software developers negatively [67, 48]. Although none of the interviewees
mentioned this, we identified the team instability during the quantitative data735
analysis.
5www.stackoverflow.com
33
5. A process to strategize and evaluate the onboarding of software
developers - RQ2
We packed as a process the findings from our exploratory study reported
herein together with the findings and solutions reported in our previous research740
[62, 56, 53, 12]. To do so, we used BPM [63]. The resulting process provides a
systematic way to strategize onboarding undertakings and evaluate onboarding
results. The resulting process is presented in Figure 4.
The process has five activities and a knowledge repository, whose role is
to allow for documentation and reuse of onboarding experiences and lessons745
learned. The knowledge repository can be implemented in different forms, like
a wiki. This process was designed to be used within the context of large-scale,
globally distributed projects. However, it can be adapted to be used in any
other context wherein software developers and teams are onboarded.
The activities, an example of how to use the process, and the results of the750
static validation are presented in the remainder of this section.
5.1. Define context
Classifying, describing, and documenting the context of an onboarding un-
dertaking is essential to allow for identifying the associated needs, particular-
ities, and challenges [68]. It also provides more systematic reuse of previous755
onboarding experiences and facilitates knowledge mining [69].
Define context is the first activity of the proposed process. In this activity,
an onboarding undertaking context is classified using the extended version [62] of
Smite et al.’s GSE taxonomy [70], whose dimensions are presented in Tables 4, 5
and 6. The taxonomy allows for classification on site (Table 4) and relationship-760
between-pair-of-sites levels (Tables 5 and 6).
In the context of the proposed process, the taxonomy is to be used following
these steps:
1. Identify the source site(s) (the main source(s) of knowledge and where
the key decision-makers are located) and the target sites (locations where765
34
Figure 4: The proposed process.
35
Dimension Categories Description
Language
distance
No distance,
Small,
Medium,
large
The language distance is measured in
terms of the distance between a site’s
mother tongue and English (language
distance index), which is a number
that varies from 0 to 1. There is no
distance when a site’s mother tongue
is English or there is no need for a
lingua franca. The distance is small
when the a site’s language distance
index is smaller or equal to 0.4. It is
considered medium when a site’s
language distance index is greater
than 0.4 and smaller than 0.57.
Finally, it is considered large when it
is greater than 0.57 and smaller or
equal to 1.
Software
process
type
Agile,
Plan-driven
A site is to be classified as agile if its
software process is mainly based on
agile practices. Otherwise, it is to be
classified as plan-driven.
Power
distance
Small,
Large
A site has large power distance when
its power distance index is greater
than 50; otherwise, it is considered
small.
Uncertainty
avoidance
Weak,
Strong
A site has strong uncertainty
avoidance when its uncertainty
avoidance index is greater than 63;
otherwise, it is considered weak.
Table 4: Dimensions of the GSE taxonomy on site level.
36
Dimension Cate-
gories Description
Location Onshore,
Offshore
A sourcing can be delegated to a site in the
same country, i.e., onshore, or to a site in
another country, i.e., offshore.
Legal
entity
Insourc-
ing,
Out-
sourcing
Independently from the location, a sourcing
can be transferred to a different branch (site)
of the company, i.e., insourcing, or
subcontracted to a different legal entity
(company), i.e., outsourcing.
Geographi-
cal
distance
Close,
Distant,
Near, Far
In onshore projects, the geographical distance
is considered: close when it is possible to have
relatively frequent face-to-face meetings, since
no flights are required to go from one site to
the other; distant when at least one flight is
required to have face-to-face meetings, which
yields time and cost increases. In offshore
projects, the geographical distance is
considered: near when the required flying time
is less than two hours; far when the flying
time is longer than two hours and staying
overnight is usually required.
Temporal
distance
Similar,
Differ-
ent,
Small,
Large
In onshore projects, the temporal distance is
considered: similar when there is a time
difference of one hour or less; different when
the time difference between two sites is longer
than one hour. In offshore projects, the
temporal distance is considered: small when
there is a time distance between sites of four
hours or less; large when there is a time
distance between two sites of more than four
hours.
Table 5: Dimensions of the GSE taxonomy on relationship-between-pair-of-sites level - Part
I.
37
Dimension Cate-
gories Description
Software
process
distance
Equal,
Similar,
Different
The software processes of two sites are
considered equal when they use the same
workflows, roles, and practices to develop
software. They have similar processes when
they have the same software process type, but
the workflows, roles, and practices are not the
same. The processes are considered different
when there are no commonalities.
Communi-
cation
model
Low syn-
chronic-
ity, high
syn-
chronic-
ity,
balanced
syn-
chronic-
ity
It is low when the communication is mainly
based on asynchronous media (e.g., email). It
is high when communication is mainly based
on synchronous media (e.g., instant messaging
tools). It is balanced when the
communication model has both synchronous
and asynchronous media, and each media type
is used for its most adequate purpose.
Table 6: Dimensions of the GSE taxonomy on relationship-between-pair-of-sites level - Part
II.
38
new software developers/teams will be onboarded). Note that it can be
the case that the target and source sites are the same, which happens
when new teams will be onboarded in the same location where the main
source of knowledge and the decision-makers are located.
2. Classify each involved site using the dimensions described in Table 4.770
3. Classify each relationship between a pair of sites using the dimensions
described in Tables 5 and 6. Note that if the source and target sites are
the same, this step is not necessary.
5.2. Strategize onboarding undertaking
Before starting any onboarding undertaking, it is essential to define the775
appropriate strategy for the associated context. The combination of tools,
practices, recommendations, performance goals, and measurement milestones
constitutes an onboarding strategy, which is formalized in an onboarding plan.
The decision makers must account for relevant tools, practices, methods, and
techniques to strategize an onboarding undertaking, such as the ones identified780
by Britto et al. [12, 13]:
•Integrate recruitment and onboarding.
•Provide realistic job previews.
•Create an onboarding plan.
•Involve key stakeholders in the recruitment and onboarding process.785
•Provide formal orientation for newcomers.
•Provide mentoring for newcomers.
•Evaluate the progress of newcomers.
•Provide feedback for newcomers.
•Take into account cultural differences when developing the learning pro-790
cess.
39
•Ensure collocated mentoring to support the learning process of offshore
teams when there is not enough competence locally.
•Facilitate group learning.
•Use code reviews to support learning.795
It is necessary to define performance indicators of interest and baselines
to define performance goals and milestones. Based on the exploratory study
reported in this paper and Britto et al. [53], we set productivity, autonomy, and
maturity as performance indicators. Productivity and autonomy are defined in
Section 3. Maturity [53] relates to the amount of knowledge associated with a800
product under development/maintenance, and knowledge about the associated
technology stack. The bigger the knowledge, the bigger the maturity.
The performance goals for a developer or team are defined based on the av-
erage performance of high-performance developers or teams (baseline), with the
addition of some acceptable margin of variation (up and down the average, to be805
defined by the decision-makers when strategizing an onboarding undertaking).
Performance is measured using the measurement approach described in Section
3.
5.3. Evaluate onboarding results
To identify if an onboarding undertaking is progressing as expected, it is810
necessary to measure the performance of the onboarded developers or teams
using the performance indicators described above and compare the results with
the defined performance goals. If the onboarding undertaking is not progressing
as expected, it may be the case that the company needs to act (e.g., providing
more formal training). The metrics associated with each performance indicator815
are presented in Section 3. Maturity is defined as follows:
•Maturity Mki is measured as the maturity of team kor developer kbefore
carrying out task i. It is measured using the authority matrix presented
Britto et al. [53]. The authority matrix is showed in Figure 5.
40
The matrix has a maturity curve that shows how the responsibilities of820
software architects and developers/teams change as they get more mature. In
its y-axis, there are the four main activities that developers/teams and architects
are involved, while the x-axis has the four defined maturity levels [53]:
•In Level A – A developer or team on this level has no or very basic knowl-
edge about the code and architecture of the product. They require a lot825
of mentoring and support from the architects, even when implementing
(i.e., coding, testing, and documenting) non-complex technical solutions.
Software architects guide the Level-A developers/teams during the imple-
mentation and are actively involved, both with reviewing and approving
code.830
•Level B – A developer or team on this level has sufficient knowledge
to implement non-complex technical solutions without much guidance.
More knowledgeable team members and design leads of Level-B teams
can review the code implemented by the team, but software architects are
still required to review the majority of the design and code.835
•Level C – It represents experienced and mature developers or teams with
good knowledge of the product architecture, which can implement complex
technical solutions that have a significant architectural impact. They are
capable of reviewing and approving their code, and software architects are
only involved in approval when critical components of the software archi-840
tecture are affected (a critical component contains the core functionality
of the product that executes key operations). More solution design work is
also delegated to Level-C teams. Software architects support these Level-
C teams/developers by mentoring the design of technical solutions and
providing on-demand guidance in the initial stages of implementation.845
•Level D – It represents very experienced and rather autonomous develop-
ers or teams that are capable of implementing complex technical solutions
independently, even the ones that affect critical components of the prod-
42
uct architecture. The code implemented by them does not need to be
approved by software architects. They can also drive the design and re-850
view of technical solutions. Software architects are involved only in the
technical solution design.
5.4. Identify and address issues
The results of the previous activity (evaluate onboarding results) must be
compared to the defined performance goals. Deviations can indicate that there855
are issues in the onboarding undertaking that need to be addressed. Prob-
lems may be related to insufficient amounts of formal training and inadequate
amounts of mentoring. It may be the case that it is not worthwhile for a
company to invest time and money to address an issue. For example, when a
newcomer or team composed of newcomers is presenting poor performance after860
many measurement milestones, decision makers may decide to close down the
associated site.
An onboarding undertaking is considered successful when the onboarded
developers or teams achieved the defined performance goals. The issues and
associated solutions (if any) should be documented in a knowledge repository865
(e.g., wiki).
5.5. Using the process
To illustrate the use of the process, we used the case investigated in this
paper (described in Section 3).
In the investigated case, there are two sites (Figure 6), one located in Sweden870
(A – source site), and the other located in India (B – target site). Since there
are just two sites in this example, there is just one relationship (AB). The result
of employing the taxonomy to describe the context of the example is presented
in Tables 7 (site level) and 8 (relationship-between-pair-of-sites level).
The onboarding was strategized in the following way:875
•The average productivity, autonomy, and maturity level of high-performance
teams located in Italy and the USA were used to define the performance
43
Figure 6: Sites involved in the case.
goals of the newcomers.
•Training and mentoring were provided on-site in Sweden for the first new-
comers so that they could help with the onboarding of other newcomers880
later on. This initial training in Sweden was followed by on-site mentoring
provided by senior software developers. They went from Sweden to India
and stayed for four months. The senior developers also provided training
for the newcomers onboarded during this period.
•The onboarding was mainly strategized by the decision makers located in885
Sweden, but the recruitment process was planned and conducted by local
personnel in India.
•The performance of the onboarded newcomers was to be continuously
evaluated and they were to take the main responsibility for the product
after two years.890
An evaluation of the newcomers’ performance (see Section 4) showed that
they were not improving as expected by the decision makers; after two years,
they were still on average 3.57 times less productive and 1.67 times less au-
tonomous than the target performance goals (the productivity and autonomy
levels of the benchmark teams). Furthermore, no team composed of newcomers895
in India managed to progress to a mature level (C or D). Thus, it was neces-
sary to extend the time for the Indian site to take over the main responsibility
regarding the product. Furthermore, the decision makers decided to prepare
some developers from the Indian site to become software architects. The idea
44
Dimension A B
Language distance
No distance (all
employees had to
be fully fluent in
English)
No distance (all
employees had to
be fully fluent in
English)
Software process
type Agile Agile
Power distance Small Large
Uncertainty
avoidance Strong Week
Table 7: Classification on the site level for the case.
was to have people capable of providing on-site mentoring in India. To do so,900
the selected developers stayed in Sweden for six months and received specific
training and mentoring.
6. Static validation of the process
The ideal way to evaluate a process like the one proposed in this paper is
by using it in a live project. However, we were not able to do so by the time of905
our investigation. To mitigate this limitation, we conducted a static validation
[65] of the process by asking experienced Ericsson R&D managers to answer a
questionnaire.
The feedback provided by the nine respondents indicates that the process is
useful and can help managers to onboard newcomers in an effective way. At the910
same time, they have shared a few concerns that may make it difficult to use
the whole process. The results of the static validation are presented next.
Table 9 contains the results associated with Q1 (relevance of the different
process’s components) and shows that all nine respondents of the questionnaire
see the significance of all activities of the process. Moreover, Evaluate on-915
boarding results and Store and use knowledge from previous onboard-
ing undertakings received more Strongly Agree answers, which is aligned with
45
Dimension AB Detail
Location Offshore
The target site is
located in a
different country.
Legal entity Insourcing
Both sites are part
of the same
company
(Ericsson)
Geographical
distance Far
The fastest flight
between the two
sites is longer than
two hours.
Temporal distance Small
There is a time
zone difference of
3 hours and a half.
Software process
distance Equal
Both sites employ
the same software
workflows, role
and practices.
Communication
model
Balanced
synchronicity
The
communication
between the sites
is done via
different types of
media, such as
Skype, email and
videoconferencing.
Table 8: Classification at the relationship level for the example.
46
the answers provided to the open-ended questions (Q2-Q5).
Compo-
nent Strongly
Agree Agree
Unde-
cided
Dis-
agree
Strongly
Dis-
agree
Define
Onboard-
ing
Context
45000
Strate-
gize
onboard-
ing using
adequate
practices
63 0 0 0
Evaluate
onboard-
ing
results
81 0 0 0
Store
and use
knowl-
edge
from
previous
onboard-
ing
under-
takings
81 0 0 0
Table 9: Results of Q1.
Regarding Q2 (the benefits of the process), most respondents believe the
main benefit of the process is that it helps to systematize the onboarding of920
newcomers, making it more repeatable, less dependent on individuals, and en-
suring that all required steps are carried out. One of the respondents said: “It
requires you to think first and not only teach what you know, which I see is
often the case when we ask teammates to onboard new colleagues without any
clear instructions.” Another respondent had a similar opinion: “It provides925
47
structure into the onboarding process. A checklist is often a good way to secure
that all required actions are performed. It also makes it easy to handover be-
tween different RD managers, securing that the process is relatively uniform.”
The same respondent mentioned that the process may help to identify early on
the strengths and weaknesses of newcomers: “One can get early on a feeling of930
where the individual has strengths and weaknesses.”
The fact that the process enables the description of an onboarding under-
taking’s context was highlighted by one of the respondents as an advantage:
“Context is easy to forget since we directly jump into the technical aspect. With
this process, we do not miss to explain what purpose we serve with our technical935
solutions and how we do it using organization, tools, processes, etc.”
One of the respondents highlighted that the process helps to document ex-
periences gained with onboarding undertakings, which can help with the on-
boarding of other newcomers and avoid “reinventing the wheel”: “The benefit
is to log and store success stories and what experiences are key to achieve what940
we aim for.”
Concerning Q3 (the drawbacks and limitations of the process), most re-
spondents shared their concern about the administration time required to use
the process, especially about the evaluation of onboarding results: “The main
drawback is the risk that it will take too much time in administration, which945
may mean that the process will not be used in the long run.” The time and cost
associated with maintaining the tools and artifacts related to the process were
also mentioned by another manager: “I think managing the process will take
time and money. The tools related to the process will need to be maintained.”
Another aspect that concerns some of the respondents is that the process950
can be seemed like a hurdle by some managers, which may lead them to return
to ad-hoc ways of onboarding newcomers: “At the start, the process may be
perceived as a hurdle for managers. If this happens, it is easy to slip into old
habits, which are ad-hoc.”
In the opinion of all respondents, there are no steps that should be removed955
from the process (Q4). Moreover, they believe the process is flexible enough
48
and does not require any additional step (Q5). However, one of the respondents
suggested the creation of a template to facilitate the usage of the process: “I
believe you need to create a template to fill in the onboarding context, like a
spreadsheet. You should also provide a spreadsheet to facilitate tracking the960
status of each developer, like their competence in different areas.”
7. Discussion
Our results support and extend many prior findings related to the per-
formance of newcomers onboarded in large-scale or just distributed software
projects. Our quantitative analysis of performance data confirms the possible965
dramatic decreases in productivity, as in the case of 80% decrease described by
Carmel and Tjia [71], and the importance of mentoring as a compensating and
supporting practice[14, 15].
The performance analysis also supports the view that it takes a considerable
time for offshore developers to acquire the required knowledge on a distance,970
similar to Espinosa et al. [44] and Smite and van Solingen [48]. Although we
refer to the small performance improvements as unexpected, performance gaps
are not surprising.
Although we did not find the true time it takes to acquire the required knowl-
edge, our results indicate that time to minimize performance gaps is certainly975
longer than three years. Our results are more pessimistic than those of Ebert
[38], who suggests that the learning process may take 12 months. Our results
are more aligned with the findings by Mockus and Weiss [37]; they found that
remote developers may have up to 3-year learning curves [37].
Given the relatively small performance improvements, it is unreasonable to980
believe that the remote site will achieve comparable performance in five years,
as found by Smite and Wohlin [40], and Kommeren and Parviainen [41]. It
is likely to take longer than five years, as in the case of Boden et al. [42] or
never achieve full recovery as in the case described by Carmel and Tjia [71].
Therefore, we believe that companies shall plan for large performance gaps and985
49
a long time to learning when onboarding developers in large-scale projects with
a large amount of legacy code, as described in prior research [10, 11], legacy
code increases the difficulty to learn.
Jones [27], based on Van Maanen and Shein work [18], proposed a model
that categorizes onboarding programs into institutionalized (fully formal) and990
individualized (partially formal). Existing research shows that successful on-
boarding of newcomers relates to formal onboarding programs (institutional-
ized onboarding) [25, 28, 29]. Thus, it is important to strategize onboarding
undertakings by systematically developing onboarding programs. The process
proposed in this paper supports careful planning, which is needed to: i) design995
the stages through which the newcomers are expected to progress [20, 21]; ii)
to select actors involved with the onboarding [22, 23]; iii) to employ tactics and
practices for onboarding [24, 18, 25]; and iv) to plan the content to be learned
[21, 26].
Concerning designing the stages through which the newcomers are expected1000
to progress, we found that for highly complex products with large amounts of
legacy code, the 4-6 months long co-located mentoring (coaching and support)
might be insufficient. We suspect that longer on-site mentoring could help
newcomers to progress faster. Increased synchronous interaction between the
mentors and the newcomers could be another solution to facilitate the learning.1005
This would also require selecting mentors with excellent communication skills.
We also learned that the company failed to align the training and support
activities with the needs and expectations of the remote developers. The learn-
ing process employed in the project was mainly based on autonomous learning
and expected pro-active learners. This might have clashed with the expectations1010
of the Indian newcomers. According to Nicholson and Sahay [66], the education
system in India is more traditional and emphasizes more discipline than the ones
in European countries. Indian developers are more used to a receiving learning
approach. Clashing learning approaches could have, therefore, inhibited their
progress.1015
Concerning the content of what shall be learned, the choice of complex tasks
50
might have also negatively impacted the learning experiences. Research related
to job satisfaction [72] indicates that a perceived lack in programming experience
and fear of failure cause frustration and may lead developers to leave their jobs.
They are also related to a long period to learn what is necessary to do the1020
required work [72]. The presence of a considerable amount of legacy code was
perceived as an additional complexity driver.
Globally distributed projects often involve multiple sites, which may have
different national cultures. Considering that national cultures [73] influence or-
ganizational cultures, it is hard to create the same corporate culture in locations1025
with different national cultures [74]. This may result in fragmented onboarding
strategies within the same company and different formality levels regarding on-
boarding [12]. Since formal onboarding processes are perceived as more effective
[24], the existence of different formality levels may lead to situations where a
company is successful in onboarding developers in a particular location and fails1030
in others.
While it is essential to account for the particularities of involved locations,
it is equally important to consider onboarding functions (tools, practices, meth-
ods, and techniques [24]) that are proved to be effective [24]. Thus, the process
put forward in this paper can help companies to systematically account for1035
the particularities of involved locations and effective onboarding practices when
strategizing onboarding of developers. This can help to avoid onboarding strat-
egy fragmentation and different effectiveness levels among various sites.
Our study has some implications for research and practice. We have em-
ployed a novel approach to the performance evolution of newcomers in large-1040
scale distributed projects. However, we have investigated just one case. Further
research is necessary to strengthen the empirical evidence.
Another important aspect is the duration of the investigation. We believe
that investigating newcomers for an extended period may enrich our under-
standing of their performance evolution. For example, it may allow identifying1045
when offshore newcomers will reach and sustain the same level of performance
of senior onshore developers.
51
In our investigation, we analyzed historical data and talked to the newcomers
many months after the starting of their onboarding. We believe it may be
beneficial to start this type of investigation together with the onboarding of the1050
newcomers. In doing so, it may be possible to reveal things that are not possible
to identify with the same research design employed in our investigation.
Finally, we have shown with our investigation that companies in similar con-
texts should strive for onboarding newcomers more systematically and formally.
The process proposed in this paper may support companies in doing so.1055
8. Threats to validity
The validity threats associated with our investigation are discussed using
the categories reliability, internal, construct and external validity described by
Runeson and H¨ost [55]. Furthermore, we also discuss conclusion validity [75],
since we applied statistical inferences in this investigation.1060
We minimized reliability threat by involving several researchers in the de-
sign and execution of our investigation. Furthermore, our observations and
findings were verified with the company representatives to avoid false interpre-
tations. We also designed and followed an explicit case study protocol, following
the guidelines by Runeson and H¨ost [55].1065
However, the approach we used to assess task complexity was highly depen-
dent on the involved software architects. It might therefore be very hard to
obtain the same values with other informants. Since we used an iterative pro-
cess for task complexity assessment (see Section 3.3), we would expect similar
results, though.1070
The same applies to the approach used to adjust productivity and autonomy
of distributed product customization tasks. Finally, the data on task effort and
mentoring effort was based on time reports provided by the developers and
software architects respectively. As investigated by Perry et al. [76], self time
reporting is fairly unreliable. To mitigate this threat, we carried out a sanity1075
check of the collected data, by comparing the reported hours with slot plan
52
documents associated with the investigated newcomers.
Regarding internal validity, the facets of performance we investigated are
influenced by several confounding factors. We made an attempt to mitigate this
threat by interviewing people with different roles and by using existing literature1080
(data triangulation). Regarding the qualitative part of our research, the main
internal validity threats are investigator bias and interviewee bias. To mitigate
these threats, three researchers were involved with the design of the interview,
workshop guides, and static validation questionnaire (investigator triangula-
tion). We mitigated the second threat in the case study by interviewing people1085
with different roles (data triangulation). However, it was not possible to do the
same when conducting the process static validation; we only involved managers.
the ideal approach would be to involve managers and developers recently on-
boarded, but there were no suitable developers by the time we evaluated the
process.1090
The main threat to construct validity is that we used only one method to
measure a construct. To mitigate this threat in the case study, we collected
data from different sources (data triangulation). Furthermore, we conducted a
sanity check together with the software architects to validate our measures (task
complexity and autonomy). To support these sanity checks, we used plots and1095
descriptive statistics to identify inconsistencies (no inconsistencies were found).
Since task complexity was obtained using expert judgment, this is also a po-
tential threat to construct validity (expert bias). This threat was mitigated by
involving several experts with many years of experience in the product under in-
vestigation and employing an iterative assessment approach (based on planning1100
poker). Existing literature shows that group discussions lead to better effort
estimates than expert judgment [77].
Regarding the static validation of the proposed process, we piloted the ques-
tionnaire with the help of a senior RD manager. To mitigate expert bias, we
asked different managers to answer the questionnaire (nine). However, the fact1105
that no developer answered the questionnaire is a limitation in itself and a threat
to the construct validity of the static validation.
53
Since we employed the case study method, our findings are strongly bound
by the context of our study (external validity). In addition, the investigated
case involved only one product in one company. To mitigate this threat, we1110
made an attempt to describe the context of our study in as much detail as
possible. This makes it easier to relate the present case to similar cases.
It is hard to claim that the proposed process is meaningful or useful without
evaluating it in a living project, which we could not do during the course of our
investigation. Instead, we conducted a static validation to get the opinion of1115
practitioners about the proposed process. However, it is hard to generalize the
results of the conducted static validation due to the small number of respondents
(nine) and the fact that all respondents were affiliated to the same company.
However, the results are important as a sanity check of the relevance of the
proposed process.1120
The main threats to conclusion validity are the low reliability of measures
(the amount of noise related to a measure) and low statistical power. To mitigate
the first threat, we conducted a sanity check of the collected data, as mentioned
above. Regarding statistical power, we were limited to data covering product
customization tasks carried out by the newcomers during two years.1125
9. Conclusions and future work
This paper presents the results of a case study conducted in Ericsson, which
aimed at investigating the performance evolution of offshore newcomers on-
boarded in a large-scale globally distributed project and how it relates to the
employed onboarding strategy. The overall conclusion is that some aspects of1130
the used onboarding strategy seem to be associated with the observed perfor-
mance evolution, which was lower than expected by the company.
We identified the following aspects in the onboarding strategy employed in
the investigated case that relate to the observed performance evolution: i) the
distance to mentors; ii) the formal training approach used, which did not fit1135
the socio-cultural background of the newcomers; iii) the allocation of large and
54
distributed tasks in the early stages of the onboarding process; and iv) team
instability.
The results of this paper indicate that onboarding in globally distributed
projects that involve a considerable amount of complex legacy code must be1140
planned well ahead. It might take a long time until newcomers acquire all the
knowledge required to perform as well as experienced teams. Organizations
must be prepared to provide extended periods of mentoring by expensive and
potentially scarce resources (e.g., software architects).
In our investigation, we covered approximately two years of data. Including1145
an extended period might provide further insights into the performance evolu-
tion of newcomers. Therefore, we plan to continue collecting data about this
case.
In this paper, we also put forward a process to strategize and evaluate the
onboarding of newcomers in globally distributed large-scale projects. The results1150
of the conducted static validation indicate that the process can help companies
to strategize and evaluate the results of onboarding undertakings in a more
formal, systematic, and repeatable way. However, the proposed process has
not been used to plan any onboarding undertaking from scratch. Rather, some
of its activities were used in an on-going undertaking (the case investigated1155
in this paper) and not in a systematic way. We believe it is worthwhile to
investigate how effective the process is to strategize and evaluate the onboarding
of newcomers in real, globally distributed large-scale projects.
Acknowledgments
This research was funded by the Swedish Knowledge Foundation under the1160
KK-H¨og grant 2009/0249 and is a part of the TEDD research project. The
authors are very thankful to Ericsson and all the company employees involved
in and being sincerely interested in our research.
55
References
[1] N. Ramasubbu, M. Cataldo, R. K. Balan, J. D. Herbsleb, Configuring1165
global software teams: A multi-company analysis of project productivity,
quality, and profits, in: Proceedings of the 33rd International Conference
on Software Engineering - ICSE’11, 2011, pp. 261–270.
[2] E. Conch´uir, P. J. ˚
Agerfalk, H. Holmstr¨om, B. Fitzgerald, Global software
development: Where are the benefits?, Communications of the ACM 52 (8)1170
(2009) 127–131.
[3] A. B. Bondi, J. P. Ros, Experience with training a remotely located perfor-
mance test team in a quasi-agile global environment, in: Proceedings of the
2009 Fourth IEEE International Conference on Global Software Engineer-
ing - ICGSE’09, IEEE Computer Society, Washington, DC, USA, 2009, pp.1175
254–261.
[4] J. Herbsleb, D. Moitra, Global software development, IEEE Software 18 (2)
(2001) 16–20.
[5] K. Dikert, M. Paasivaara, C. Lassenius, Challenges and success factors for
large-scale agile transformations: A systematic literature review, Journal1180
of Systems and Software 119 (2016) 87–108.
[6] J. A. Espinosa, N. Nan, E. Carmel, Do gradations of time zone sepa-
ration make a difference in performance? a first laboratory study, in:
Second IEEE International Conference on Global Software Engineering -
ICGSE’07., 2007, pp. 12–22.1185
[7] J. D. Herbsleb, A. Mockus, An empirical study of speed and communica-
tion in globally distributed software development, IEEE Transactions on
Software Engineering 29 (6) (2003) 481–494.
[8] M. Vierhauser, R. Rabiser, P. Gr¨unbacher, A case study on testing, commis-
sioning, and operation of very-large-scale software systems, in: Companion1190
56
to the proceedings of the 36th International Conference on Software Engi-
neering, ICSE Companion, New York, NY, USA, 2014, pp. 125–134.
[9] S. Eldh, J. Brandt, M. Street, H. Hansson, S. Punnekkat, Towards fully
automated test management for large complex systems, in: 2010 Third
International Conference on Software Testing, Verification and Validation,1195
2010, pp. 412–420.
[10] S. A. Bohner, Software change impacts-an evolving perspective, in: Soft-
ware Maintenance, 2002. Proceedings. International Conference on, 2002,
pp. 263–272.
[11] K. Chen, V. Rajich, Ripples: tool for change in legacy software, in: Soft-1200
ware Maintenance, 2001. Proceedings. IEEE International Conference on,
2001, pp. 230–239.
[12] R. Britto, D. S. Cruzes, D. Smite, A. Sablis, Onboarding software devel-
opers and teams in three globally distributed legacy projects: A multi-case
study, Journal of Software: Evolution and Process 30 (4) (2018) e1921.1205
[13] R. Britto, D. Smite, L. Damm, J. B¨orstler, Performance evolution of new-
comers in large-scale distributed software projects: An industrial case
study, in: 2019 ACM/IEEE 14th International Conference on Global Soft-
ware Engineering (ICGSE), 2019, pp. 1–11.
[14] F. Fagerholm, A. S. Guinea, J. M¨unch, J. Borenstein, The role of men-1210
toring and project characteristics for onboarding in open source software
projects, in: Proceedings of the ACM-IEEE 8th International Symposium
on Software Engineeering and Measurement - ESEM’14, 2014, pp. 1–10.
[15] F. Fagerholm, A. Sanchez-Guinea, J. Borenstein, J. M¨unch, Onboarding in
Open Source Projects, IEEE Software 31 (6) (2014) 54–61.1215
[16] D. ˇ
Smite, C. Wohlin, Strategies facilitating software product transfers,
IEEE Software 28 (5) (2011) 60–66.
57
[17] T. N. Bauer, B. Erdogan, Organizational socialization: The effective on-
boarding of new employees, in: APA handbook of industrial and organi-
zational psychology, Vol 3: Maintaining, expanding, and contracting the1220
organization, 2011, pp. 51–64.
[18] J. Van Maanen, E. H. Schein, Toward a theory of organizational socializa-
tion, Research in Organizational Behavior 1 (1979) 209–269.
[19] H. J. Klein, B. Polin, K. Leigh-Sutton, Specific Onboarding Practices for
the Socialization of New Employees, International Journal of Selection &1225
Assessment 23 (3) (2015) 263–283.
[20] B. Buchanan, Building organizational commitment: The socialization of
managers in work organizations, Administrative Science Quarterly 19 (4)
(1974) 533–546.
[21] D. C. Feldman, A contingency theory of socialization, Administrative Sci-1230
ence Quarterly 21 (3) (1976) 433–452.
[22] E. M. Morrison, Newcomers’ relationships: The role of social network ties
during socialization, Academy of Management Journal 45 (2002) 1149–
1160.
[23] B. E. Ashforth, Role transitions in organizational life: An identity-based1235
perspective, Mahwah, NJ:Lawrence Erlbaum Associates, 2001.
[24] T. N. Bauer, Onboarding new employees: Maximizing success, Tech. rep.
(2011).
[25] H. J. Klein, A. Heuser, The learning of socialization content: A framework
for researching orientating practices, Research in Personnel and Human1240
Resources Management 27 (2008) 278–336.
[26] G. T. Chao, A. M. O’Leary-Kelly, H. J. Wolf, S., Klein, P. D. Gardner,
Organizational Socialization: Its contents and consequences, Journal of
Applied Psychology 79 (5) (1994) 730–743.
58
[27] G. R. Jones, Socialization Tactics, Self-Efficacy, and Newcomers’ Adjust-1245
ments To Organizations., Academy of Management Journal 29 (2) (1986)
262–279.
[28] T. N. Bauer, T. Bodner, B. Erdogan, D. M. Truxillo, J. S. Tucker, New-
comer adjustment during organizational socialization: A meta-analytic re-
view of antecedents, outcomes and methods, Journal of Applied Psychology1250
92 (2007) 707–721.
[29] D. M. Cable, C. K. Parsons, Socialization tactics and person-organization
fit, Personnel Psychology 54 (1) (2001) 1–23.
[30] T. N. Bauer, S. G. Green, Effect of newcomer involvement in work-related
activities: a longitudinal study of socialization, Journal of Applied Psy-1255
chology 79 (2) (1994) 211–223.
[31] T. N. Bauer, E. W. Morrison, R. R. Callister, Organizational socialization:
A review and directions for future research., Research in Personnel and
Human Resources Management Vol 16. 16 (January) (1998) 149–214.
[32] G. Maier, J. C. Brunstein, The role of personal work goals in newcomers’1260
job satisfaction and organizational commitment: A longitudinal analysis,
Journal of Applied Psychology 86 (5) (2001) 1034–1042.
[33] J. P. Meyer, N. . Allen, Links between work experiences and organizational
commitment during the first year of employment: A longitudinal analysis,
Journal of Occupational Psychology 61 (3) (1988) 195–209.1265
[34] H. J. Klein, J. Fan, K. J. Preacher, The effects of early socialization experi-
ences on content mastery and outcomes: A mediational approach, Journal
of Vocational Behavior 68 (2006) 96–115.
[35] H. J. Klein, N. A. Weaver, The effectiveness of an organizational-level ori-
entation training program in the socialization of new hires, Personnel Psy-1270
chology 53 (2000) 47–66.
59
[36] C. Ostroff, S. W. J. Kozlowski, The role of mentoring in the information
gathering processes of newcomers during early organizational socialization,
Journal of Vocational Behavior 42 (1993) 170–183.
[37] A. Mockus, D. M. Weiss, Globalization by chunking: a quantitative ap-1275
proach, IEEE Software 18 (2) (2001) 30–37.
[38] C. Ebert, Optimizing supplier management in global software engineer-
ing, in: International Conference on Global Software Engineering (ICGSE
2007), 2007, pp. 177–185.
[39] D. ˇ
Smite, F. Calefato, C. Wohlin, Cost savings in global software engineer-1280
ing: Where’s the evidence?, IEEE Software 32 (4) (2015) 26–32.
[40] D. ˇ
Smite, C. Wohlin, Lessons learned from transferring software products
to India, J. Softw. Evol. and Proc. 24 (2012) 605–623.
[41] R. Kommeren, P. Parviainen, Philips experiences in global distributed soft-
ware development, Empirical Softw. Eng. 12 (6) (2007) 647–660.1285
[42] A. Boden, B. Nett, V. Wulf, Coordination practices in distributed software
development of small enterprises, in: International Conference on Global
Software Engineering (ICGSE 2007), 2007, pp. 235–246.
[43] A. Nguyen-Duc, D. S. Cruzes, R. Conradi, The impact of global dispersion
on coordination, team performance and software quality - A systematic1290
literature review, Information and Software Technology 57 (2014) 277–294.
[44] J. A. Espinosa, S. A. Slaughter, R. E. Kraut, J. D. Herbsleb, Familiarity,
complexity, and team performance in geographically distributed software
development, Organization Science 18 (4) (2007) 613–630.
[45] M. Cataldo, S. Nambiar, On the relationship between process maturity and1295
geographic distribution: An empirical analysis of their impact on software
quality, in: Proceedings of the the 7th Joint Meeting of the European Soft-
ware Engineering Conference and the ACM SIGSOFT Symposium on The
60
Foundations of Software Engineering, ESEC/FSE ’09, ACM, New York,
NY, USA, 2009, pp. 101–110.1300
[46] R. Jabangwe, D. ˇ
Smite, An exploratory study of software evolution and
quality: Before, during and after a transfer, in: 2012 IEEE Seventh Inter-
national Conference on Global Software Engineering, 2012, pp. 41–50.
[47] R. Jabangwe, K. Petersen, D. ˇ
Smite, Visualization of defect inflow and
resolution cycles: Before, during and after transfer, in: 2013 20th Asia-1305
Pacific Software Engineering Conference (APSEC), 2013, pp. 289–298.
[48] D. ˇ
Smite, R. van Solingen, What’s the true hourly cost of offshoring?, IEEE
Software 33 (5) (2016) 60–70.
[49] A. Labuschagne, R. Holmes, Do onboarding programs work?, in: Pro-
ceedings of the IEEE/ACM 12th Working Conference on Mining Software1310
Repositories, 2015, pp. 381–385.
[50] I. Steinmacher, M. A. G. Silva, M. A. Gerosa, D. F. Redmiles, A systematic
literature review on the barriers faced by newcomers to open source software
projects, Information and Software Technology 59 (March) (2015) 67–85.
[51] I. Steinmacher, M. A. Gerosa, Choosing an appropriate task to start with1315
in open source software communities: A hard task, Lecture Notes in Com-
puter Science (including subseries Lecture Notes in Artificial Intelligence
and Lecture Notes in Bioinformatics) 8658 LNCS (2014) 349–356.
[52] G. G. Sharma, K.-J. Stol, Exploring onboarding success, organizational fit,
and turnover intention of software professionals, Journal of Systems and1320
Software 159 (2020) 110442.
[53] R. Britto, D. ˇ
Smite, L. Damm, Software architects in large-scale distributed
projects: An ericsson case, IEEE Software 33 (6) (2016) 48–55.
[54] M. Johnson, M. Senges, Learning to be a programmer in a complex orga-
nization: A case study on practice-based learning during the onboarding1325
process at google, Journal of Workplace Learning 22 (3) (2010) 180–194.
61
[55] P. Runeson, M. H¨ost, A. Rainer, B. Regnell, Case Study Research in Soft-
ware Engineering: Guidelines and Examples, John Wiley & Sons, 2012.
[56] R. Britto, D. ˇ
Smite, L. Damm, Experiences from measuring learning and
performance in large-scale distributed software development, in: Proceed-1330
ings of the 10th ACM/IEEE International Symposium on Empirical Soft-
ware Engineering and Measurement, ESEM ’16, ACM, New York, NY,
USA, 2016, pp. 17:1–17:6.
[57] J. Burchell, M. Vargas, The Hitchhiker’s Guide to ggplot2 in R, Leanpub,
2016.1335
[58] S. B. Green, How many subjects does it take to do a regression analysis,
Multivariate Behav. Res. 6 (3) (1991) 499–510.
[59] S. E. Maxwell, Sample size and multiple regression analysis, Psychol. Meth-
ods 5 (4) (2000) 434–458.
[60] G. Neumann, M. Harman, S. Poulding, Transformed vargha-delaney effect1340
size, in: M. Barros, Y. Labiche (Eds.), 7th International Symposium on
Search-Based Software Engineering, SSBSE’15, 2015, pp. 318–324.
[61] C. Robson, K. McCartan, Real World Research, 4th Edition, Wiley, 2016.
[62] R. Britto, C. Wohlin, E. Mendes, An extended global software engineer-
ing taxonomy, Journal of Software Engineering Research and Development1345
4 (1) (2016) 1–24.
[63] J. Holt, A Pragmatic Guide to Business Process Modelling, British Comp
Society Series, British Computer Society, 2009.
[64] M. von Rosing, H. von Scheel, A. Scheer, The Complete Business Process
Handbook: Body of Knowledge from Process Modeling to BPM, Elsevier1350
Science, 2014.
[65] T. Gorschek, P. Garre, S. Larsson, C. Wohlin, A model for technology
transfer in practice, IEEE Software 23 (6) (2006) 88–95.
62
[66] B. Nicholson, S. Sahay, Some political and cultural issues in the globali-
sation of software development: Case experience from Britain and India,1355
Information and Organization 11 (1) (2001) 25–43.
[67] S. Narayanan, S. Balasubramanian, J. M. Swaminathan, A Matter of Bal-
ance: Specialization, Task Variety, and Individual Learning in a Software
Maintenance Environment, Management Science 55 (11) (2009) 1861–1876.
[68] K. Petersen, C. Wohlin, Context in industrial software engineering research,1360
in: Proceedings of the 2009 3rd International Symposium on Empirical
Software Engineering and Measurement, ESEM’09, IEEE Computer Soci-
ety, Washington, DC, USA, 2009, pp. 401–404.
[69] S. Vegas, N. Juristo, V. R. Basili, Maturing software engineering knowledge
through classifications: A case study on unit testing techniques, Software1365
Engineering, IEEE Transactions on 35 (4) (2009) 551–565.
[70] D. ˇ
Smite, C. Wohlin, Z. Galvi¸na, R. Prikladnicki, An empirically based ter-
minology and taxonomy for global software engineering, Empirical Software
Engineering 19 (1) (2014) 105–153.
[71] E. Carmel, P. Tjia, Offshoring Information Technology: Sourcing and Out-1370
sourcing to a Global Workforce, Cambridge University Press, 2005.
[72] D. Ford, C. Parnin, Exploring causes of frustration for software develop-
ers, in: 2015 IEEE/ACM 8th International Workshop on Cooperative and
Human Aspects of Software Engineering, 2015, pp. 115–116.
[73] G. Hofstede, G. J. Hofstede, M. Minkov, Cultures and Organizations: Soft-1375
ware of the Mind, 3rd Edition, McGraw-Hill, 2010.
[74] S. Nidhra, M. Yanamadala, W. Afzal, R. Torkar, Knowledge transfer chal-
lenges and mitigation strategies in global software development-A system-
atic literature review and industrial validation, International Journal of
Information Management 33 (2) (2013) 333–355.1380
63
[75] W. Trochim, J. P. Donnelly, K. Arora, Research Methods: The Essential
Knowledge Base, Cengage, 2015.
[76] D. E. Perry, N. Staudenmayer, L. G. Votta, People, organizations, and
process improvement, IEEE Softw. 11 (4) (1994) 36–45.
[77] K. Moløkken-Østvold, M. Jørgensen, Group processes in software effort1385
estimation, Empirical Software Engineering 9 (4) (2004) 315–334.
64
