PreprintPDF Available

Employee Retention and Turnover in Global Software Development: Comparing In-house Offshoring and Offshore Outsourcing

Authors:
Preprints and early-stage research may not have been peer reviewed yet.
Preprint

Employee Retention and Turnover in Global Software Development: Comparing In-house Offshoring and Offshore Outsourcing

Abstract and Figures

High staff turnover has a negative impact on software development productivity and product quality. Further, offshore outsourcing has a widely held reputation for particularly poor employee retention. Interestingly, in-house sites (regardless of location) do not suffer such high levels of staff turnover. We want to understand the factors affecting employee retention in-house and offshore outsourced settings, to better understand the potential impact of staff turnover on global software development. We employed a mixed-method approach comprising two empirical case studies in industry involving 62 practitioners at three global companies conducting in-house and offshore outsourced software development. We collected practitioner perceptions of causal factors for employee retention and performed a cross-case analysis to triangulate our findings. Practitioners cited employment policies, work-life balance, workplace innovation, product quality, alignment of offshore work hours with onshore, long working hours and adverse impact on health as factors affecting staff retention. In-house offshore have more family friendly employment policies. In the outsourcing sector, the focus on customer satisfaction sometimes leads to less attractive work patterns. Offshore outsourcing service providers could improve development team member retention by improving work-life balance and adopting family friendly employment policies.
Content may be subject to copyright.
Employee Retention and Turnover in Global Software
Development: Comparing In-house Offshoring and Offshore
Outsourcing
Julian M. Bass
University of Salford
j.bass@salford.ac.uk
Sarah Beecham, Mohammed
Abdur Razzak
Lero, the Irish Software Research
Centre,
University of Limerick, Ireland
sarah.beecham,abdur.razzak@lero.
ie
John Noll
University of East London
j.noll@uel.ac.uk
ABSTRACT
Poor employee retention (high staff turnover) has a negative
impact on software development productivity and product
quality. Further, offshore outsourcing has a widely held repu-
tation for particularly poor employee retention. Interestingly,
in-house sites (regardless of location) do not suffer such high
levels of staff turnover.
We want to understand the factors affecting employee
retention in-house and offshore outsourced settings, to better
understand the potential impact of staff turnover on global
software development.
The research employed a mixed-method approach compris-
ing two empirical case studies in industry involving 62 practi-
tioners at three international companies conducting in-house
and offshore outsourced software development. We collected
practitioner perceptions of causal factors for employee reten-
tion and performed a cross-case analysis to triangulate our
findings.
Practitioners cited employment policies, work-life balance,
workplace innovation, product quality, alignment of offshore
work hours with onshore, long working hours and adverse
impact on health as factors affecting staff retention. In-house
offshore have more family friendly employment policies. In
the outsourcing sector, the focus on customer satisfaction
sometimes leads to less attractive work patterns.
Offshore outsourcing service providers could improve de-
velopment team member retention by improving work-life
balance and adopting more family friendly employment poli-
cies.
Permission to make digital or hard copies of part or all of this work
for personal or classroom use is granted without fee provided that
copies are not made or distributed for profit or commercial advantage
and that copies bear this notice and the full citation on the first page.
Copyrights for third-party components of this work must be honored.
For all other uses, contact the owner/author(s).
ICSE’18, May 2018, Sweden
©2018 Copyright held by the owner/author(s).
ACM ISBN 123-4567-24-567/08/06. . . $15.00
https://doi.org/10.475/123_4
CCS CONCEPTS
Software and its engineering Software creation and man-
agement
;Software development process management; Col-
laboration in software development;
KEYWORDS
In-house Offshore, Offshore Outsourced, SME, Large Enter-
prise, Global Software Development, GSD, Employee Re-
tention, Employee Turnover, Motivation, Self-Determination
Theory
ACM Reference Format:
Julian M. Bass, Sarah Beecham, Mohammed Abdur Razzak, and John
Noll. 2018. Employee Retention and Turnover in Global Software
Development: Comparing In-house Offshoring and Offshore Out-
sourcing. In Proceedings of International Conference on Global
Software Engineering (ICGSE) (ICSE’18). ACM, New York, NY,
USA, 10 pages. https://doi.org/10.475/123_4
1 INTRODUCTION
Staff turnover has a negative effect on software development
projects [
1
,
26
]; GSD projects are not immune to this effect:
turnover can exacerbate the effects of global distance [
18
], to
the extent that Ebert and Jha cite staff turnover as one of
the top five risks to GSD projects [12].
Offshore outsourcing (to a third party service vendor) ap-
pears to experience higher turnover than offshore insourcing
(to an offshore team of company employees) [
25
]. Yet, while
there is empirical evidence indicating that offshore outsourc-
ing is prone to high staff turnover, there seems to be little
research into why this is the case.
As such, in this study, we attempt to discover the reasons
behind higher turnover in offshore outsourcing teams, as
compared to offshore insourcing. We interviewed members of
three organizations: a large outsourcing vendor in India, an
offshore software development laboratory (also in India) of a
multi-national industrial products company, and a medium-
sized software product company with globally distributed
teams. We observed that the outsourcing firm experienced
relatively high staff turnover, while the other two companies
had much lower turnover. We also found important differ-
ences in the experiences reported by participants from the
three companies, including employment policies, work-life
balance, innovation, product quality, work hours, and the way
each handles temporal distance. These differences appear to
have an effect on motivation, which in turn affects turnover:
the participants from the outsourcing firm reported issues
such as anti-social working hours and persistent overtime that
could negatively affect motivation, while the other partici-
pants reported positive experiences in areas such as work-life
balance, technical challenges, and team “connectednes,” all of
which have been identified as positive motivators for software
engineers.
We hypothesize that the fundamental differences in the
relationship between the offshore site and the onshore “home”
site shape the working environment, and hence the motivation
of the developers at the offshore site(s): the relationship
between the client (home) site and the outsourcing team is
defined by the contract, while developers at offshore sites of
a company are employees of that company, and so have a
more collaborative relationship with their peers at the home
site.
This paper is structured as follows: The next section
presents previous research on global software development
in agile projects, followed by a description of our research
methods in Section 3. In Section 4, we describe our empirical
findings, which is followed by a discussion in Section 5. Fi-
nally, we provide conclusions and possible future directions
in Section 6.
2 BACKGROUND
2.1 Global Sourcing Strategies
While there are many variants of sourcing strategies in GSD,
in this paper we focus on two types, namely, Outsourcing,
and Offshoring, as shown in Fig. 1. Where our case study out-
sourcing organizations leverage external third party resources
in their software development, and our offshore organization
leverages resources from a different country (within the same
organization). These definitions reflect the empirically agreed
terminology for reporting GSD research in [
35
]. Of note in
[
35
] is the distance expected, where in an offshore situation
time difference limits can be “perceived as small and large
have to be defined differently than in the onshore situation.
For offshoring, non-overlapping work hours are expected and
hence it is more a matter of how many overlapping hours
there are between two sites”. The authors define small as
being 4 hours or less different (meaning most of the working
day will overlap), whereas large is defined as more than 4
hours, implying a small overlap in working hours. This dif-
ference in time overlap was further measured in [
27
], along
with geographic, and cultural distance; the values for these
dimensions are summarized in Table 1.
2.2 Software Engineer Turnover in GSD
GSD projects are shown to suffer from high staff turnover
[
12
,
18
]. Demotivated software development team members
have been shown to reduce productivity [
8
] and software
quality [
23
]; conversely, high levels of motivation can have
a positive effect on staff retention [
17
]. Software developers
Table 1: Degree to which different dimensions of “global dis-
tance” increase overall separation between teams. Values are
median survey responses, where participants rated each item
on a 5-point scale (0 - Not at all, 1 - A little, 2 - Moderately,
3 - A lot, 4 - Very much).
Dimension/Size of distance Effect
Geographic Distance
Different building on same campus A little
Different towns in same region (two
hour drive)
Moderately
Less than three hour flight (Frank-
furt to Helsinki)
A lot
Transcontinental flight (New York to
San Francisco)
Very much
Intercontinental flight (London to
Shanghai)
Very much
Temporal Distance
Transcontinental (five hour overlap)
A little
Intercontinental (three or four hour
overlap)
Moderately
Global (one or two hour overlap) A lot
No overlap Very much
Cultural Distance
Uneven language skills Moderately/A lot
East/West divide in culture A lot
Different national culture Moderately
Differenalt organizational culture A lot
Figure 1: Detail from GSD Project Sub-Ontology according
to Vizcaino et al, 2016 [39])
are likely to stay longer in the job if they are satisfied [
3
]
whereas “even organizations that offer competitive salaries
and work with leading-edge technologies experience high
levels of dissatisfaction and higher than desired turnover
among their IT staff.” Given that job satisfaction [
3
,
36
],
motivators and de-motivation [
13
,
22
,
31
] are considered
predictors of staff turnover, we look at how working in a
distributed environment might influence motivation.
Traditionally software engineers were thought of as intro-
verted, and this view was supported by many studies coming
from Couger and colleagues’ who measured Social Needs
2
Figure 2: Model of Software Engineer Motivation (adapted
from Beecham et al. 2008 [5])
Strength of engineers [
9
] in their Job Diagnostics Survey.
This view is not universal, as seen in the body of more recent
research that identified software engineers as sociable people
[
5
]. Certainly, the need for software engineers to communicate
and relate to others is crucial in a GSD context [
28
]; this
relatedness is one of the three dimensions of Ryan and Deci’s
“self determination theory” [
34
] (Fig. 3). The new software
engineer profile may therefore reflect the changing demands
of the role [6].
Fig. 2 shows the relationship between characteristics, con-
trols and moderators, motivators, and outcomes. The level
to which the needs (defined by a software engineer’s charac-
teristics) are met by the motivators will impact on tangible
outcomes (note that “Job retention” is an outcome). For
example, Hall et al. [
17
] found a positive correlation between
software engineer motivation and employee turnover. An-
other outcome is project success, where Verner et al. [
37
]
found a positive correlation between motivation and software
engineering/management agreements on project success.
Table 2 gives a breakdown of software engineer character-
istics as listed in Beecham et al [
5
], and how these needs are
met by working in a distributed environment (as extracted
from [4]:
As shown in Table 2, need for stability (within the orga-
nization and geographically), and being introverted are not
compatible with operating in a changing world (with low
compatibility).
Looking at the motivators, also in [
5
], there are several
factors that are likely to threaten motivation, for example
the study on motivation in GSD [
4
] hypothesized that, based
on case study observations, both extrinsic and intrinsic moti-
vators are challenged.
Table 3 lists external extriinsic influences (not directly
related to the job itself), that are challenged by working in
distributed teams or remotely. Work/life balance and Sense
of belonging/supportive relationships are a lot more difficult
to achieve when considering global distance. Especially where
there is little time overlap in core working hours, as described
in Section 2.1.
We often turn to the open source community to understand
what motivates developers to develop software (independent
of extrinsic rewards such as salary). In the empirical study of
Lin et al, they note that motivation of open source developers
to participate, and by implication remain, in open source
Table 2: Software Engineer Characteristics and GSD Role
Characteristic Compatibility
1
Need for stability (organisational sta-
bility)
Low
2 Technically competent High
3
Achievement orientated (e.g. seeks
promotion)
Medium
4
Growth orientated (e.g. challenge,
learn new skills)
High
5 Need for competent supervising Medium
6
Introverted (low need for social in-
teraction)
Low
7
Need for involvement in personal
goal setting
Medium
8
Need for feedback (needs recognition)
Medium
9 Need for Geographic stability Very Low
10
Need to make a contribution (worth-
while/meaningful job)
High
11
Autonomous (need for independence)
High
12 Need for variety High
13 Marketable High
14 Need for challenge High
15 Creative High
16
Need to be sociable/identify with
group
High
Figure 3: Self-determination Theory Psychological Con-
structs.
projects is influenced by the identification of participants, the
transformational leadership of leaders and an active manage-
ment style, and the emotions of developers [
20
]; their study
of five open source projects suggests that, to retain develop-
ers, they need to contribute early to a project, and focus on
coding rather than documentation. Developers working on
open source projects are working in virtual teams, and could
be considered to have similar experiences as those developers
working in multi-site commercial projects.
3 METHODS
A mixed method approach has been adopted comprising two
case studies and a cross-case analysis. The first phase (Case
Study A) comprised a multiple case study of 53 practitioners
from two multinational companies; employing a Glaserian
grounded theory analysis of documentary sources, practice
observations and interview transcripts [2, 16].
3
Table 3: Extrinsic motivation challenged by virtual team practices
Extrinsic Factor Virtual Team Practice (drawn from case study)
Rewards and incentives (e.g. scope for
increased pay and benefits linked to
performance)
Requires objective measurement, and as such is independent of location – however making
sure that rewards are given to each employee fairly across different locations may not be
achievable, e.g. some remote workers were not able to take time off in lieu for working
long hours and overtime.
Good management (senior manage-
ment support, team-building, good
communication).
Becomes even more important when working remotely – extra pressures, extra layer of
complexity requires experienced and confident managers to deal with unforeseen problems.
A recurring theme was that remote projects required experienced managers that can
communicate well with both customers and all team.
Sense of belonging/ supportive rela-
tionships
Difficult to feel supported when your counterpart might be sleeping during your core work-
ing hours. However the organisation had a strong corporate culture, clearly communicated
in all interviews.
Work/life balance (flexibility in work
times, caring manager/ employer, work
location)
Extremely difficult to achieve, when there is a lot of travel, working away from home
(and family), and keeping work hours down to core times seems impossible. It was rare to
hear any reports of people working sustainable hours when working remotely.
Employee participation/ involvement/
working with others
Some experienced managers working remotely, did not want to participate with the wider
organisation; finding interference from higher management to be a negative influence.
They tended to want to be left alone to sort out their customer facing issues. A fine
balance needs to be struck between participation, and a top-down style of management
that imposes the processes.
Appropriate working conditions/ envi-
ronment /equipment/ tools / physical
space /quiet
Working conditions specially affected remote workers. For example, when working onsite
with customers they often did not have any influence on where they work, or how and
sometimes, when. They were not able to separate themselves from being on call to the
customer: there was a tension between dealing with customer demands and their tangible
deliverables.
Sufficient resources Resources were scarce in terms of people – (individuals were stretched to fill the gaps).
Table 4: Case study company characteristics
Company Company
Sector
Employees Revenue, 2016
(Gross Income)
IndProdCo Industrial
Products
362,000 79.6 billion
OutsourceCo IT Service
Provider
8,000 US $420 million
Pracmed Software
Vendor
300 20 million
In addition to Case Study A, during our second phase,
we conducted a 14 month longitudinal embedded case study
(Case Study B) in a medium sized software development
company.
Finally, we employed a cross-case analysis to triangulate
our findings.
3.1 Case Study A
3.1.1 Research Sites. The companies selected for inclusion
in this study are from a population of large enterprises en-
gaged in outsourced or off-shore software development, as
shown in Table 4.
Intensity sampling, which targets a larger number of in-
terview participants with different responsibilities within the
same unit of analysis, was employed to obtain richness and
depth in the study [
30
, p. 234]. Perspectives from partici-
pants with different responsibilities were obtained in order
to triangulate the data. Responsibilities included: developers,
testers, project management, programme management and
corporate-level executives.
The Indian IT Services company (known here as Out-
sourceCo) selected for the study, is a well-known mid-sized
vendor in the worldwide software service outsourcing sector.
OutsourceCo has Fortune500 company clients in Europe and
North America and specialises in the travel sector.
The industrial products company (known here as Ind-
ProdCo) has headquarters in Europe and has divisions in
industrial automation and health. The software development
centre in India is one of several worldwide technology centres.
3.1.2 Data Collection. The study was supported with doc-
umentary sources, such as publicly available white papers,
technical reports, case studies, descriptions of vendor capa-
bilities and web hosted marketing materials.
On-site visits to secure work environments enabled first-
hand observation of working practices and workplace en-
vironments. Scrum teams coordination meetings (stand-up
meetings) were observed. Distributed scrum teams use video-
4
Table 5: Case study participants
Company Participant roles
IndProdCo
(26 participants in
Bengaluru (Banga-
lore), India)
Scrum Master (4)
Chief Manager & Agile Coach (1)
(Sub-)Segment Head (2)
Quality Assurance Manager (2)
(Senior) Developer (4)
Tester/Test Lead (3)
(Part) Product Owner (2)
Programme Manager (1)
Project Manager (2)
Technical Lead/Architect (5)
OutsourceCo
(27 participants in
Delhi, India)
Chief Technology Officer (1)
Corporate Lead Architect (1)
General Manager, Human Re-
sources (1)
Delivery/Programme Manager
(3)
(Senior) Project Manager (3)
Scrum Master (2)
Technical Analyst/Consult-
ant/Specialist (6)
Team Member (9)
Business Analyst
Pracmed
(9 partici-
pants in Ireland and
North America)
Product Owner (2)
Software Developer (5)
Tester (1)
Scrum Master (1)
and audio-conferencing technology to enable virtual team
coordination meetings.
However, the primary data collection technique employed
in the study was face-to-face interviews conducted with 53
practitioners performed between May 2012 and March 2016,
as shown in Table 5. The interviews were typically 50 minutes
long and structured using an open-ended interview guide.
Probing questions were used to encourage interviewees to
raise any topics, issues and concerns outside the scope of
scripted interview questions.
3.1.3 Data Analysis. Audio interview recordings were tran-
scribed and then imported into a qualitative data analysis
software tool, Nvivo V9 [
29
]. Audio interviews and each cor-
responding transcript were then reviewed for consistency.
A Glaserian approach to grounded theory was used for
data analysis [
14
]. Topics were identified within the interview
data and then coded into concepts by comparing within
and between interview participants. Next, these concepts
were iteratively grouped and refined into selected interview
categories using constant comparison.
Descriptions of each selected category, with illustrative
example quotations as evidence, were used to create examples
of memo writing [
15
, Chapter 12]. These memos evolved and
changed during the analysis where categories are refined and
sharpened.
3.2 Case Study B
Case Study B was a participant-observer study, focusing on a
development team from a medium-sized Irish-based software
company that develops practice and lab management software
for the optical industry.
Pracmed employs approximately seventy staff members
in its software development organization, including support
and management staff. Pracmed’s annual sales approach
e
20
million, from customers across the British Isles, continental
Europe, Scandinavia, North America, and China.
Case Study B focused on TeamA, whose responsibility
is to tailor the company’s product for a large customer in
North America. The members of TeamA are distributed over
four countries on two continents (see Table 5), with up to
eight hours difference in timezones between locations. They
are using Scrum to develop their software, with two weekly
sprints.
3.2.1 Data Collection. We observed TeamA from Janu-
ary, 2016 to March, 2017. Specifically, one of the authors
observed approximately 200 of TeamA’s Scrum ceremonies,
including daily standups, sprint planning, backlog grooming,
and sprint retrospectives. Due to team members being dis-
tributed across Europe and North America, the observations
were made via video conference for each ceremony. The same
author also conducted semi-structured interviews of each
member of TeamA, which were recorded and transcribed.
The interviews took approximately one hour and followed an
interview protocol available from [7].
The observer also made contemporaneous hand-written
notes during both the ceremony observations and interviews.
Finally, the interviewer summarized the interviews using a
mind-map, and presented the result to five interviewees in
an online workshop to validate the insights gained from the
interviews.
3.2.2 Data Analysis. Given that Case Study A was com-
pleted by the start of the data analysis phase of Case Study
B, we took a deductive approach that attempted to find
evidence in support of, or contradictory to, the themes gen-
erated by Case Study A. We examined interview transcripts
for comments illustrating or elaborating these themes, and
our observational notes for events related to themes.
3.3 Cross Case Analysis
While the case study approach is well established in software
engineering [
33
], this research has employed a cross case (or
cross site) analysis to explore similarities and differences
among cases [
24
]. We use multiple cases in order to establish
the range of generality and conditions of applicability of each
approach [16].
5
Our approach does not synthesise data from multiple case
studies [
10
,
11
], but rather use a cross case analysis to facili-
tate the comparison events, activities, and processes consid-
ered important for each case [
19
,
24
]. We have purposively
selected the Case Study A and Case Study B in order to
contrast features of the in-house offshore and outsourced
offshore context.
4 RESULTS
4.1 Length of Service
The results here confirm anecdotal evidence of high staff
turnover in the offshore outsourcing sector. Length of service:
“2
1
2
years” (Senior Software Engineer, OutsourceCo). “I have
been working [here] for 1 year” (Scrum Master, OutsourceCo).
Length of service: “1
1
2
years” (Senior Software Engineer,
OutsourceCo). Length of service: “I have been working here
for the last 2 years” (Software Engineer, OutsourceCo).
There is an expectation of high staff turnover in the out-
sourcing sector “if you work for a company like [a major
Indian outsourcing company] or something. . . within 2 years
you generally shift companies” (Developer, IndProdCo).
In contrast, working in-house for an international company
even in an offshore location, there is improved retention, “I
have been working here for 8
1
2
years. I joined as a fresher right
out of college” (Developer, IndProdCo), “10
1
2
years I have
worked here” (Architect, IndProdCo), “11 years” (Quality
Manager, IndProdCo), “Fourteen years about to complete”
(Quality Assurance Manager, IndProdCo) and “9
1
2
years”
(Technical Lead, IndProdCo).
Participants witness long service and high staff retention in
the in-house offshore sector “[in] my team of 9 only 3 people
are freshers. Otherwise, everyone has 8, 9, 10 years experience”
(Developer, IndProdCo). Indeed, the average length of service
on TeamA was over 7 years, with one senior member having
over 20 years tenure. Three of TeamA’s members started with
Pracmed as interns, and four have spent almost their entire
careers with the company. Interestingly, one of TeamA’s
members used to work for an outsourcing vendor in India
before joining Pracmed in Ireland.
4.2 Employment Policies
The positive employment ethos of working in-house for an
international company is reflected in the offshore location,
“they have good policies, employee related policy” (Developer,
IndProdCo). Such policies include inculcating a collegial and
supportive work environment,
“we have open communication with colleagues.
We share a lot of things. We help others. This
helps to reduce a lot of tension and pressure in
the workplace” (Test Lead, IndProdCo).
and “everyone is so supportive for getting the job done”
(Senior Developer, IndProdCo). Practitioners describe a high
level of autonomy in their work “nobody ringing me saying,
‘Okay, you have to do this, this, this.’ Because we are self-
organised basically” (Technical Lead, IndProdCo).
Pracmed also tries to treat its offshore staff as equal to
those at the home office: every year, all development staff are
flown to Dublin for a week-long developer conference. Also,
Pracmed has an ambitious growth-by-acquisition strategy;
they make substantial efforts to integrate development teams
from acquired companies into their organization.
4.3 Work-life Balance
Practitioners describe respect from the employer towards
home life “we come here for professional work, but we have
another place to go after work that is to our family” (Senior
Developer, IndProdCo), “[IndProdCo ] respects our family
as well” (Architect, IndProdCo) and “if there is any prob-
lem, I can go home whenever required” (Technical Lead,
IndProdCo).
Employee-friendly policies are seen as supporting staff
retention, “If I have an emergency [at home], I don’t need to
worry if I have leave or not – my manager approves [time off].
There is work-life balance. . .that is one reason why many
people stick with the company” (Scrum Master, IndProdCo).
Another example, from Pracmed, involved a project man-
ager who considered resigning to spend more time with her
young children; Pracmed made adjustments to her work
schedule to accommodate this need.
4.4 Workplace Innovation
Practitioners at IndProdCo describe workplace innovation
as a driver for staff retention,
“[we have an] innovative culture, where we are
allowed to think freely and come up with our own
ideas. Then, we can file our own invention dis-
closures. Those are discussed and taken forward
for patent filing” (Architect, IndProdCo)
We did not find any evidence of innovation patenting in
OutsourceCo.
4.5 Product Quality
Many practitioners at IndProdCo emphasised the importance
of product quality “Quality is always a challenge for us,
but [IndProdCo ] always has a focus on quality” (Quality
Assurance Manager, IndProdCo) and “there are a lot of
[quality assurance] processes. . . we are minimising the defects”
(Chief Manager, IndProdCo).
Lean practices are used to ensure the focus on quality
“there is ‘stop the line,’ where the team is empowered to raise
an issue related to quality” (Product Owner, IndProdCo).
Senior management monitors product quality during the
development process “each version of the product. . . has five
quality gates, wherein quality at every stage is being checked.
And then it is reported to higher management” (Project
Manager, IndProdCo).
Practitioners at IndProdCo describe this commitment to
product quality as a driver for staff retention, “It’s also
a reputed company, which produces a good quality prod-
uct. . . This helps us to stay longer in [IndProdCo ]” (Test
Lead, IndProdCo)
6
Pracmed also places emphasis on quality: junior developers
are required to have their code reviewed by a senior developer.
But this is seen as positive: “you do have a better product at
the end of the sprint. There are a lot of checks and balances
within the sprint at the same time there [is] more and more
communication.” (Junior Developer, Pracmed)
4.6 Alignment with Onshore Work Hours:
Antipattern
Some outsourcing teams are required to shift their usual work
hours to maximise time shared with onshore clients, for exam-
ple “we are four and a half hours ahead right now, so we have
half day when we really can talk to [the clients] and organise
any meetings” (Senior Project Manager, OutsourceCo).
normally our working hours in India are 9 to 6
but we are working from 11 to 8. And as a team
lead, I stay in the daylight saving times I stay
one hour more, so that we get a full two hours of
overlapping with the team at onshore (Technical
Analyst, OutsourceCo).
Again, “[normally] we leave at 8pm, so by 9pm I’m at
home. . .[the onshore client] is providing us with [taxi] cabs
[to get home]” (Software Engineer, OutsourceCo).
It is not clear if shifting work hours is a requirement
from clients, or if outsourcing vendors offer to shift work
hours as an inducement to attract customers. None of the
teams at IndProdCo reported aligning work hours to the
onshore corporate headquarters time zone. This is also true of
Pracmed; despite being highly distributed across Europe and
North America, there is no attempt to synchronize working
hours.
Rather, TeamA sometimes tries to take advantage of the
time difference: “It would helpful if everybody was in the
same room but in our case. .. we have the advantage of people
in different time-zones. They [DBA in Dublin] are given some
work that I am doing at the moment then will be working
on it during the day. Then the DBA can handover to me in
the next morning.” (Senior. Developer, TeamA)
by having Senior Developers in Dublin do code reviews of
North American developers’ output.
4.7 Work Hours: Antipattern
Outsourcing vendors require staff members to work additional
hours, for example “towards the end of a sprint we may be
putting extra hours, sometimes” (Senior Project Manager,
OutsourceCo). For some team members the need to work late
happens if there is a technical problem “sometimes if there is
a challenge on the team. It does put pressure on us. So that
we give some extra hours” (Scrum Master, OutsourceCo).
Practitioners do not view the need to work long hours
positively, “sometimes we have to stay [at work] late, so it
feels bad” (Software Engineer, OutsourceCo).
In contrast, working in-house for an international company
“the work is really good, in the sense that you
have regular timeslots of nine hours, they don’t
ask you to work on Saturdays, Sundays. The
work-life balance is really good here” (Developer,
IndProdCo).
This quote is illustrative of several similar comments made
about working hours at IndProdCo.
In contrast, Pracmed has an unwritten “9 to 5” policy:
while we observed occasional examples of senior team mem-
bers working late to solve an urgent customer problem, in
general Pracmed seems to adopt a sustainable pace philos-
ophy with flexible working hours to accommodate school
schedules and other family requirements.
4.8 Adverse Impact on Health
In the outsourcing environment, long work hours are consid-
ered unhealthy by practitioners. For example, “that pressure
[to deliver] comes after every sprint, at the end of every
sprint. It is not healthy I fear” (Senior Project Manager,
OutsourceCo).
Similarly,
“If one day we stretch to 12 working hours, it’s
more than enough. So, if you’re continuously
working 12 hour days, your health goes down.
You can’t think anymore” (Senior Software En-
gineer, OutsourceCo).
We found no evidence of practitioners identifying negative
health impacts of work at IndProdCo or Pracmed.
5 DISCUSSION
The findings from our cross case analysis identify issues
around employment policies, work-life balance, workplace
innovation, onshore work hours alignment, working hours,
and impact on health.
We found evidence of family friendly policies at IndProdCo
and Pracmed. For example, time-off from work to deal with
a family emergency, sustainable work hours, a culture of
communication and respect were all cited as important by
practitioners.
In contrast, at OutsourceCo there seemed to be a much
more immediate focus on client satisfaction leading to issues
around long working hours as well as evening and weekend
working.
We observed another important distinction in the area of
product innovation and product quality. For IndProdCo and
Pracmed there was a sense of pride and ownership of the
product being produced. The commitment to quality was
striking in practitioner responses. While at OutsourceCo the
product belongs to the client and the commitment quality
was sometimes subsumed by the need for productivity to
meet client demands.
These findings can be summarised, as shown in Table 6, by
saying that in OutsourceCo client satisfaction was achieved
through productivity and responsiveness to customer de-
mands; while in IndProdCo and Pracmed, there was a greater
emphasis on product quality and product innovation.
Previous studies have shown that developer motivation and
attrition are linked: highly motivated developers are more
7
Table 6: Outsourced and In-house Comparison factors
OutsourceCo IndProdCo Pracmed
Customer Satis-
faction
Reputation for In-
novation
“Best of breed”
product
Productivity Product Quality Product quality
Client Need
Work Life Balance Work Life Balance
likely to remain in their current jobs, while lack of motivation
may result in attrition [5, 38].
This may be part of the reason that some GSD projects
experience high staff turnover, and others do not: the nature
of the work, and the working environment, in different kinds
of GSD may reduce or exacerbate staff turnover.
Ultimately, software developer motivitation can be distilled
into three factors, as proposed by Ryan and Deci [
34
] in their
self determination theory. These three factors – relatedness,
competence, and autonomy – capture the software developer’s
need to be part of a team, to learn new skills and develop
existing skills, and to exercise those skills to the best of
his or her ability; Ryan and Deci also note, however, that
these dimensions need to be balanced: autonomy without
competence can lead to stress, while lack of connectedness
can lead to a feeling of isolation [28, 34].
Are our results consistent with self determination theory?
We consider the three dimensions in turn:
Relatedness. The employment policies of both IndProdCo
and Pracmed help to promote a sense of belonging, to one’s
team and to the larger organization. It could also be argued
that a degree of relatedness is necessary for innovation: ex-
change of both ideas and experience among developers would
help innovative ideas progress to implementation.
Competence. Competence is crucial for quality: quality soft-
ware cannot be produced by unqualified developers. Compe-
tence is also a necessary pre-requisite to innovation: in a tech-
nical context, innovation derives from engineering skill that
enables a developer to carry an idea through to a patentable
innovation.
Autonomy. We noted an emphasis on individual autonomy
at IndProdCo. This is somewhat less true of Pracmed at the
individual level, but at the team level, Pracmed’s develop-
ment teams follow the Scrum philosophy of self-organization.
In previous research, we have hypothesized that competent
developers will not be motivated unless they have sufficient
autonomy to exercise their competence [
28
]. It appears that,
in the case of our offshoring companies, both conditions are
met.
5.1 Implications for Practice
Our findings show that IndProdCo and Pracmed have done
an excellent job in creating an attractive workplace culture,
evidenced by the length of service and low staff turnover we
observed.
There are attractions to working in the outsourcing sector.
Such companies provide opportunities to work with many
clients, technologies and cultures in a relatively short period
of time, when compared with a traditional career path of
moving job from one company to another.
However, in the outsourcing context, line and personnel
managers need to make more strenuous efforts to create an
attractive working environment. Greater effort to collate and
reward innovations could be a useful tool. But our evidence
suggests that paying attention to work life balance and em-
ployment policies would seem to be key.
5.2 Limitations
We have adopted four criteria for exploring the trustworthi-
ness of naturalistic research findings, following the approach
of [21, Chapter 11]:
Credibility,
Transferability,
Dependability, and
Confirmability.
In ‘real-world’ research it is not easy to manipulate exper-
imental variables to establish causal relationships [32]. As a
consequence, the quality criteria we have adopted attempt to
address broad questions of research validity and reliability.
Credibility, in a sense, relates to the ‘truthfulness’ of the
research. We seek to conduct research in such a way that
the findings are found ‘credible’ by researchers and study
participants.
Transferability addresses the applicability of research from
one group of study participants to another given a similar
context. From this perspective, we need to understand the
circumstances affecting each group to judge their similarity
in order to understand the likely application of the research
findings.
Dependability relates to the consistency or repeatability
of the research.
Confirmability in research concerns researcher neutrality or
objectivity in their interactions with the study context. A new
and independent observer should be expected to draw similar
conclusions from their findings in confirmable research.
The mixed-method research approach we adopted enabled
us to triangulate findings from OutsourceCo and IndProdCo
in Case Study A and TeamA from Pracmed in Case Study
B.
We also performed a methodological triangulation by using
an embedded participant observation study in Case Study B
as opposed to the multi-case study approach in Case Study
A. These strategies together minimise researcher bias (con-
firmability) and enhance transferability of the findings.
We have attempted to demonstrate a rigorous approach to
data collection and data analysis in order to enhance research
credibility and dependability.
6 CONCLUSIONS
This research takes as its starting point the observation that
poorly motivated software team members have a negative
8
impact on productivity and product quality. We have in-
vestigated the question: What do practitioners perceive to
be the causes of high staff turnover? And then focusing on
the question: How do practitioners explain staff turnover
for in-house offshore and offshore outsourced projects? We
observed significant differences in length of service between
the in-house and outsourced work context.
In order to explain the differences in length of service, this
research adopted a mixed methods approach comprising a
multi-case study involving two large multinational companies
and a longitudinal embedded case study in a medium sized
software development company.
In Case Study A, 53 practitioners were interviewed to
compare and contrast the in-house offshore setting (an off-
shore development centre that is part of a larger international
company) and an offshore outsourcing service provider.
In Case Study B, a participant observation study was con-
ducted over a 14 month period. A geographically distributed
team was investigated in-depth, including interviews with 9
of its members.
Our cross case analysis findings highlight issues around
employment policies, work-life balance, workplace innovation,
onshore work hours alignment, working hours and impact on
health.
In the outsourcing context, development team members
are client-facing and expected to contribute to achieving good
customer satisfaction. Emphasis on good customer satisfac-
tion focuses on development team productivity; with poor
productivity being masked for the client by long working
hours within the development team. While innovation and
elegant solutions are desirable there is a pervasive awareness
that the development artefacts produced by the team belong
to the onshore client.
In the in-house offshore context, in contrast, the team are
very much nurturing their own product. The development
artefacts produced by the team belong to the team. Of course
the team are incentivised by client satisfaction, but through a
focus on product innovation and quality. Employment policies
and employer commitment to work-life balance are designed
to nurture and retain good quality staff.
We speculate that offshore outsourcing service providers
could reduce staff member turnover by improving work-life
balance and adopting more family friendly employment poli-
cies. Further, outsourcing service providers could reward
innovation more effectively and structure contracts to enable
software product ownership to improve staff retention.
7 ACKNOWLEDGMENTS
The authors are grateful to the companies and interviewees
who participated in Case Study A. Thanks also go to Inter-
national Institute for IT, Bangalore who provided hospitality
during several research visits. The research benefited in part
from travel funding from the UK Deputy High Commission,
Bangalore; Science and Innovation Network. Accommodation
and sustenance was provided by OutsourceCo during the
data collection visit to Delhi, India.
REFERENCES
[1]
Tarek K. Abdel-Hamid. 1989. A Study of Staff Turnover, Acquisi-
tion, and Assimilation and Their Impact on Software Development
Cost and Schedule. Journal of Management Information Systems
6, 1 (summer 1989), 21–40.
[2]
Steve Adolph, Wendy Hall, and Philippe Kruchten. 2011. Us-
ing grounded theory to study the experience of software devel-
opment. Empirical Software Engineering 16, 4 (Aug. 2011),
487–513. https://doi.org/10.1007/s10664-010-9152-6
[3]
Ritu Agarwal and Thomas W. Ferratt. 2001. Crafting an HR
strategy to meet the need for IT workers. Commun. ACM 44, 7
(2001), 58–64. https://doi.org/partially
[4]
Sarah Beecham. 2014. Motivating Software Engineers working in
Virtual Teams across the Globe. In Software Project Management
in a Changing World, Claes Wohlin and Guenther Ruhe (Eds.).
Springer, Germany, 255–282.
[5]
Sarah Beecham, Nathan Baddoo, Tracy Hall, Hugh Robinson,
and Helen Sharp. 2008. Motivation in Software Engineering: A
systematic literature review. Information and Software Technol-
ogy 50, 9 (Aug. 2008), 860–878. https://doi.org/10.1016/j.infsof.
2007.09.004
[6]
Sarah Beecham and John Noll. 2015. What motivates software en-
gineers working in global software development?. In International
Conference on Product-Focused Software Process Improvement.
Springer, Cham, 193–209.
[7]
Sarah Beecham, John Noll, and Mohammad Abdur Razzak.
2017. Lean Global Project Interview Protocol. Available
at http://www.lero.ie/sites/default/files/Lero_TR_2017_
02_Beecham_Noll_Razzak-Lean%20Global%20Project%
20Interview%20Protocol.pdf. (2017).
[8]
Barry W. Boehm. 1981. Software Engineering Economics (1st
ed.). Prentice Hall, Englewood Cliffs, N.J.
[9] J. Daniel Couger and Robert A. Zawacki. 1980. Motivating and
managing computer personnel. Wiley, New York. 213 pages.
[10]
D. S. Cruzes and T. Dybå. 2010. Synthesizing Evidence in Software
Engineering Research. In Proceedings of the 2010 ACM-IEEE
International Symposium on Empirical Software Engineering
and Measurement (ESEM ’10). ACM, New York, NY, USA,
1:1–1:10. https://doi.org/10.1145/1852786.1852788
[11]
D. S. Cruzes and T. Dybå. 2011. Research synthesis in software
engineering: A tertiary study. Information and Software Tech-
nology 53, 5 (May 2011), 440–455. https://doi.org/10.1016/j.
infsof.2011.01.004
[12]
C. Ebert, B. K. Murthy, and N. N. Jha. 2008. Managing Risks
in Global Software Engineering: Principles and Practices. In
IEEE International Conference on Global Software Engineering
(ICGSE 2008). 131–140. https://doi.org/10.1109/icgse.2008.12
[13]
S. A. Frangos. 1998. Motivated humans for reliable software
products. Microprocessors and Microsystems 21, 10 (1998), 605–
610. http://dx.doi.org/10.1016/S0141-9331(98)00062-3
[14]
B. G. Glaser. 1992. Basics of Grounded Theory Analysis: Emer-
gence vs. Forcing. Sociology Press, Mill Valley.
[15]
B. G. Glaser. 1998. Doing Grounded Theory: Issues and Discus-
sions. Sociology Press, Mill Valley.
[16]
B. G. Glaser and A. L. Strauss. 1967. Discovery of Grounded
Theory: Strategies for Qualitative Research. Aldine, Chicago,
IL.
[17]
T Hall, S Beecham, J Verner, and D Wilson. 2008. The impact of
staff turnover on software projects: the importance of understand-
ing what makes software practitioners tick (Refilling the Pipeline:
Meeting the Renewed Demand for Information Technology Work-
ers). In ACM-SIGMIS CPR ’08 Conference.
[18]
H. Holmstrom, E. O. Conchuir, P. J. Agerfalk, and B. Fitzger-
ald. 2006. Global Software Development Challenges: A Case
Study on Temporal, Geographical and Socio-Cultural Distance. In
Global Software Engineering, 2006. ICGSE ’06. International
Conference on. 3–11. https://doi.org/10.1109/icgse.2006.261210
[19]
S. Khan and R. VanWynsberghe. 2008. Cultivating the Under-
Mined: Cross-Case Analysis as Knowledge Mobilization. Forum
Qualitative Sozialforschung / Forum: Qualitative Social Re-
search 9, 1 (Jan. 2008). https://doi.org/10.17169/fqs- 9.1.334
[20]
B. Lin, G. Robles, and A. Serebrenik. 2017. Developer turnover
in global, industrial open source projects: Insights from applying
survival analysis. In Proceedings - 2017 IEEE 12th International
Conference on Global Software Engineering, ICGSE 2017. 66–75.
https://doi.org/10.1109/ICGSE.2017.11
9
[21]
Y. S. Lincoln and E. G. Guba. 1985. Naturalistic Inquiry (1st
ed.). SAGE Publications, Inc, Beverly Hills, Calif.
[22]
B. L. Mak and H. Sockel. 2001. A confirmatory factor analysis of IS
employee motivation and retention. Information & Management
38, 5 (2001), 265–276. https://doi.org/no
[23]
S. McConnell. 1998. Problem programmers. IEEE Software 15, 2
(March 1998), 128, 127, 126–. https://doi.org/10.1109/52.663801
[24]
M. B. Miles and A. M. Huberman. 1994. Qualitative Data Anal-
ysis: An Expanded Sourcebook (2nd ed.). Sage Publications,
Inc.
[25]
Nils Brede Moe, Geir Kjetil Hanssen, et al
.
2012. From offshore
outsourcing to offshore insourcing: Three stories. In Global Soft-
ware Engineering (ICGSE), 2012 IEEE Seventh International
Conference on. IEEE, 1–10.
[26]
Robbie T. Nakatsu and Charalambos L. Iacovou. 2009. A com-
parative study of important risk factors involved in offshore and
domestic outsourcing of software development projects: A two-
panel Delphi study. Information and Management 46 (2009),
57–68.
[27]
John Noll and Sarah Beecham. 2016. Measuring Global Distance:
A Survey of Distance Factors and Interventions. In International
SPICE Conference on Process Improvement and Capability
Determination in Software, Systems Engineering and Service
Management. Dublin, Ireland. http://lero.ie/sites/default/files/
2015_TR_02_Sarah%20Beecham_John%20Noll_Measuring%
20Global%20Distance%20A%20Survey%20of%20Distance%
20Factors%20and%20Interventions.pdf
[28]
John Noll, Mohammad Abdur Razzak, and Sarah Beecham. 2017.
Motivation and Autonomy in Global Software Development: An
Empirical Study. In Proceedings of the 21st International Con-
ference on Evaluation and Assessment in Software Engineering.
ACM, 394–399.
[29]
NVivo. 2013. NVivo 9 Help. http://help- nv9-en.qsrinternational.
com/nv9_help.htm. (2013). [accessed 10-09-2017].
[30]
M. Q. Patton. 2002. Qualitative Research & Evaluation Methods
(3rd ed.). Sage Publications, Inc, Thousand Oaks, California.
[31]
C. M. Ridings and L. B. Eder. 1999. An Analysis of IS technical
career paths and job satisfaction. SIGCPR Comput. Pers. 20, 2
(1999), 7–26. https://doi.org/no
[32]
Colin Robson. 2011. Real World Research (3rd ed.). John Wiley
and Sons Ltd., Chichester, UK.
[33]
P. Runeson, M. Höst, A. Rainer, and B. Regnell. 2012. Case Study
Research in Software Engineering: Guidelines and Examples.
Wiley-Blackwell, Hoboken, NJ.
[34]
Richard M. Ryan and Edward L. Deci. 2000. Self-determination
theory and the facilitation of intrinsic motivation, social devel-
opment, and well-being. American psychologist 55, 1 (2000),
68.
[35]
Darja Šmite, Claes Wohlin, Zane Galvi
n
,
a, and Rafael Priklad-
nicki. 2014. An empirically based terminology and taxonomy for
global software engineering. Empirical Software Engineering 19,
1 (2014), 105–153.
[36]
D. C. Smith and H. L. Speight. 2006. Antecedents of turnover
intention and actual turnover among information systems per-
sonnel in South Africa. Proceedings of the 2006 ACM SIG-
MIS CPR conference on computer personnel research: Forty
four years of computer personnel research: achievements, chal-
lenges & the future. Claremont, California, USA (2006), 123–129.
https://doi.org/no
[37]
June Verner, S Beecham, and N Cerpa. 2010. Stakeholder Disso-
nance: Disagreements on project outcome and its impact on team
motivation across three countries. In ACM SIGMIS CPR ’10.
[38]
J. M. Verner, M. A. Babar, N. Cerpa, T. Hall, and S. Beecham.
2014. Factors that motivate software engineering teams: A four
country empirical study. Journal of Systems and Software 92
(June 2014), 115–127. https://doi.org/10.1016/j.jss.2014.01.008
[39]
Aurora Vizcaíno, Felix García, Mario Piattini, and Sarah Beecham.
2016. A validated ontology for global software development. Com-
puter Standards & Interfaces 46 (2016), 66–78.
10
... Historical data draw a big impact on project estimation because if our previous estimates are not accurate and consistent, then estimation for new project does not produce better results, so because of these, chances of under and overestimation becomes high, which is not appropriate for any project [3]. ...
... Quality Assessment criteria for study selection n identifying different factors involved in GSD, we parallel achieved the Quality Assessment mechanism for the nominated papers with the information extraction phase. For QA, guidelines represented in [3] [17] [30] are followed, and a checklist is also produced. ...
... For the validation of these finding and to check the impact of these factor on task allocation empirical studies were conducted. Factors identified form Paper [10] Factors identified from Paper [26] Factors identified from Paper [3] Factors identified from Paper [21] Communication Cultural Travel Process Time Zone ...
Conference Paper
Full-text available
Nowadays, software projects are a vital element in any organization's success. It plays the highest role in the organization's success in most cases. Hence, its main focus is to earn more money on a project and minimize the developing time cost. Sometimes due to unavailability of experts may decrease the profit of the organization. Thus, the organization comes with these types of issues. They want to increase the profit and decrease the development time and on fewer budgets, hire the more expert people to achieve the organization's goal. For this purpose, they are applying the new development approach called GSD (global software development). Through global software development, they develop their project on a reasonable budget and maximize profit. However, in GSD, other challenges of team communication, coordination, geographical location, and cultural and time zone differences increase the project's effort. This paper shows the more critical factors in GSD and the more challenging and shows their impact. They are more challenging on which project manager or team leader more focus on these factors, which can be more helpful for the project's success. This paper is more helpful for both industries and researchers in that they can easily estimate the effort in the context of GSD.
... Previous literature reported on the negative impact of turnover on team cognition and performance (Levine and Choi 2004;Levine et al. 2005), and its costs for the company and society (Graef and Hill 2000;Garman et al. 2005). Software engineering-specific literature has also shown that developers' turnover harms software development projects (Bass et al. 2018;Nakatsu and Iacovou 2009;Hall et al. 2008). Hall et al. (2008) showed that projects with high turnover are less successful. ...
Article
Full-text available
Several Open-Source Software (OSS) projects depend on the continuity of their development communities to remain sustainable. Understanding how developers become inactive or why they take breaks can help communities prevent abandonment and incentivize developers to come back. In this paper, we propose a novel method to identify developers’ inactive periods by analyzing the individual rhythm of contributions to the projects. Using this method, we quantitatively analyze the inactivity of core developers in 18 OSS organizations hosted on GitHub. We also survey core developers to receive their feedback about the identified breaks and transitions. Our results show that our method was effective for identifying developers’ breaks. About 94% of the surveyed core developers agreed with our state model of inactivity; 71% and 79% of them acknowledged their breaks and state transition, respectively. We also show that all core developers take breaks (at least once) and about a half of them (~45%) have completely disengaged from a project for at least one year. We also analyzed the probability of transitions to/from inactivity and found that developers who pause their activity have a ~35 to ~55% chance to return to an active state; yet, if the break lasts for a year or longer, then the probability of resuming activities drops to ~21–26%, with a ~54% chance of complete disengagement. These results may support the creation of policies and mechanisms to make OSS community managers aware of breaks and potential project abandonment.
... However, the issue of the global engineer shortage has been one of the most concerning issues today. The phenomenon of talent competition, or "war for talent" due to talent shortages, has become a priority issue, specifically among engineers (Bass et al., 2018). The Asian engineers' shortage is also not a new issue and has become a significant concern among employers, especially in manufacturing engineering. ...
... As previously discussed, communication, coordination, and control are essential components in RCM and implementation process, especially when outsourcing a software product [36]- [38]. Thus, it is of vital importance to select the most viable methods, tools, and technology to effectively implement the RCM process in GSD [30]- [32], [39], [40]. ...
Article
Full-text available
Global Software Development (GSD) is expanding quickly all around the world because of the various advantages offered to the customers, vendors, and other stakeholders involved in software project development. However, GSD is not a simple process as it faces multiple challenges that arise due to the mismanagement of the communication and coordination process. Meanwhile, Requirements Change Management (RCM) is a tedious and high resource-consuming process in GSD, which is further negatively affected by the poorly managed communication and coordination mechanisms. Multiple research studies have presented various theoretical and conceptual models to overcome the challenges during RCM in the GSD context. However, the existing methodologies lack in handling the communication and coordination challenges during the RCM process in the GSD context. In the literature, the researchers have concluded that a conceptual model can effectively reduce the communication and coordination challenges during RCM in GSD. Inspired by this, the current work aims at proposing a conceptual model to overcome and mitigate the communication and coordination challenges, while ensuring the effective requirement changes at offshore software development sites. Moreover, it would help the multiple stakeholders in understanding and managing the necessary resources before initiating the RCM process. To validate the proposed conceptual model, we have conducted a questionnaire-based survey to procure the results from the industrial experts working in the GSD domain. After analyzing the obtained results, we found that the proposed conceptual model is effective to handle the communication and coordination challenges up to 87%. In addition, almost 87% of the experts have agreed upon the correctness, identified challenges, and the mitigation practices in the proposed conceptual model necessary to improve the RCM process in the GSD context. Furthermore, it was observed that 75% of the experts also agreed upon the practical implementation of the proposed conceptual model in the software development industry to observe the heuristic performance of the proposed conceptual model.
... As previously discussed, communication, coordination, and control are essential components in RCM and implementation process, especially when outsourcing a software product [32]- [34]. Thus, it is of vital importance to select the most viable methods, tools, and technology to effectively implement the RCM process in GSD [26]- [28], [35], [36]. ...
Article
Full-text available
Global Software Development (GSD) is widely used by software development organizations to ensure the development of a cost-effective software product. GSD has now become a common engineering practice adopted by a significant number of multinational software development organizations, and even individuals (freelancers) are seeking numerous benefits including low development cost, highly skilled workers, and access to better development ideas. However, communication and coordination challenges remain a prominent research issue in the GSD context, while performing different project-related activities especially for Requirements Change Management (RCM). As a result, improper communication and coordination during RCM require additional time, cost, and development resources. Thus, it is of vital importance to ensure proper communication and coordination before initiating a software project. Inspired by this, current work aims at exploring and mitigating the communication and coordination challenges during RCM in the GSD context. To accomplish the targeted research objective, we performed a tertiary study to provide a landscape of the challenges that occurred during RCM in the context of GSD. Based on the performed study, we found 62 communication and 14 coordination challenges. In total, 107 mitigation strategies are explored and reported that effectively address the categorized sub-challenges of communication and coordination. Moreover, we proposed a conceptual model useful to address the communication and coordination challenges for the RCM process in GSD. Furthermore, we consulted the domain experts for the validation of the proposed conceptual model. Based on the promising results, we believe that this work supports the project managers in managing the cost and time-related issues in the GSD context. Consequently, the proposed conceptual model would help in optimally utilizing the scared software development resources.
... They are based mainly on the promotion of a healthy and harmonious lifestyle, the impression of programs promoting respect for differences between employees, eliminating any forms of discrimination, as well as integrating employees also outside the workplace, providing medical and insurance packages or care for the elderly or sick. Creating a worker-friendly environment by ensuring work-life balance is increasingly an argument that ensures employee loyalty (Bass and Beecham, 2018). ...
... Almost 90% of the employees leave the company within the first year, while in the second year is 50%, revealing that two years is the retention threshold for the investigated company. Similarly, Bass et al. [18] conducted a study to find out why turnover in offshore outsourcing teams is higher than offshore insourcing. They interviewed members of three organizations: a large outsourcing, an offshore software development laboratory, and a company with globally distributed teams. ...
Conference Paper
Full-text available
In order to know whether FLOSS projects are performing well, researchers have studied the ability of these projects to both attract and retain contributors, and consequently, their turnover, that is, the exit of some contributors and the entry of others. However, most contributors accounted for turnover in FLOSS projects are not active and make one or two contributions per year, which can lead to inaccurate results. In this paper, we compute the turnover of 174 FLOSS projects for each year between 2015 and 2018, considering only core developers. We analyze how the Core Developers' Newcomers and Leavers rates can influence the actionability of these projects, considering the time to fix issues and bugs, and the time to implement enhancements. We found out that 104 (59.7%) out of 174 projects have at least 30% turnover per year, 46 (26.4%) projects exceed 50%, and only 10 (5.7%) projects have less than 10% of annual turnover on average. We also found that projects owned by organizations have a higher Core Developer Turnover (CDT) rate than projects owned by individual users. The results show that the turnover of core developers increases with the size of teams, and it is notably higher in Ruby projects. Finally, we use the Core Developer Newcomers (CDN Rat e) and Leavers (CDL Rat e) rates to classify FLOSS projects as Attractive, Unattractive, Stable, Unstable. The results show that projects classified as Unstable (High Number of Core Developers Leavers and Newcomers) take a longer time to fix issues and bugs and to implement enhancements than other groups.
... The importance of the turnover to the field of software engineering is ever greater particularly as tech companies witness record high fluctuation of men power [32], [33]. In software development business job satisfaction, motivators and demotivation are considered predictors of staff turnover [34], [35]. As studies report, turnover has become a culture in the Information Technology (IT) industry [36], [37]. ...
Article
Full-text available
Turnover of the personnel represents a serious issue for management of software projects. The buildup of competences and phasing in of the people into the project requires both time and effort. This paper presents a case study of a large in-house agile software development project. The research goal was to determine the effects that turnover has on the expert effort estimation. In order to do this, paper examines relations across empirical data on a studied project. Study findings are the following: a) it is necessary to distinguish types of turnover, b) the general and planned turnover do not necessarily have a negative effect on estimation accuracy, and c) the unplanned turnover can have a significant negative impact on the reliability of the estimates and therefore should be treated with special attention. Results suggest that these facts should be taken into account both by the management and human resources.
Article
This study empirically examines the impact of technical and situational factors on the quality of software development. Defect density was used to measure the post-implementation quality of software projects. The non-parametric Kruskal-Wallis test and the parametric Welch T-test were used to test the differences in defect density for technological and situational factors related to these projects. Results suggest technological and situational factors significantly impact the quality of software. Empirical findings revealed the following factors result in lower defect density: (1) project enhancements versus new project development; (2) smaller projects versus larger projects; (3) using a development methodology; (4) using later generation programming languages; (5) developing projects with in-house teams; (6) using an iterative development methodology versus a waterfall development methodology; (7) using larger development teams versus smaller teams; (8) using CASE tools; and (9) developing projects on a standalone platform versus developing on a client\server multiplatform.
Article
Full-text available
Information Technology (IT) is one of the fast-growing industries. On the one hand, IT organizations get benefits from their skilled and talented employees to increase their annual growth and productivity. On the other hand, IT and software organizations are facing a lot of challenges because of high employee turnover intention. The main causes of high employee turnover intention are lack of management support, low level of compensation plans, poor relationship with supervisors, limited development and training programs, and work stress. Therefore, the current study aims to identify and empirically evaluate the factors of turnover intention in Pakistan's software and IT industries. For this purpose, a systematic literature review is conducted to identify turnover intention factors from the literature. For the empirical evaluation, a survey is conducted to evaluate these identified factors. In the survey, a total of two hundred and fifty professionals from Pakistan's IT and software industry participated either through online Google Form or printed survey questionnaires. The collected data were analyzed using regression analysis performed in SPSS and Warp-PLS. The findings of this study illustrate that the recruitment & section, team & management support, performance & career management, salary & compensation, employee commitment, job security, recognition, organizational demographics, and personal demographics with mediating the role of job satisfaction have a significant impact on IT professionals' turnover intention except for age and gender. The current study also depicts that there was a significant correlation between SLR and empirical results (r = 0.627, P = 0.039). It has been concluded that IT professionals prefer to work long tenure in the organization if they are offered better facilities in terms of compensation plans, career growth, and management support. The practical implication of this study is helpful for IT and software organizations' top management to retain skilled employees and reduce their loss in annual revenue. INDEX TERMS Employee commitment, empirical study, employee turnover intention, IT professional turnover, job satisfaction, job security, recruitment, systematic literature review, team management.
Article
Full-text available
The motivation of software engineers affects the quality of the software they produce. Motivation can be viewed in terms of needs. The key need for a software engineer is to ‘identify with their task’ which requires being given a task that is challenging and understanding the purpose and significance of the task in relation to the complete system being developed. Software engineers’ needs are complex – they also require regular feedback, trust, appreciation, rewards, a career path, and sustainable working hours. Furthermore, amongst other fixed environmental factors, these motivators require sensitive tuning in line with a software engineer’s personality and career stage. Creating this personality-job fit is not easy in a co-located environment, so how can project managers motivate teams of individuals distributed across the globe? This chapter reflects on some of the motivational issues that managers of virtual teams may encounter. Some background theory is presented for a deeper understanding of how to manage team motivation. Recommendations are drawn from a case study where issues raised by practitioners working in virtual teams serve to highlight and magnify known motivational issues. Project managers play an important part in software engineer motivation. If they can create a working environment that motivates individuals in the team, they will find that team members are more likely to turn up to work, are less likely to look elsewhere for employment, will work harder to meet deadlines, will take more pride in their work, and will share their knowledge, concerns, and ideas for innovation.
Conference Paper
Distributed development involving globally distributed teams in different countries and timezones adds additional complexity into an already complex undertaking. This paper focuses on the effect of global software development on motivation. Specifically, we ask, what impact does misalignment between needed and actual autonomy have on global team motivation? We studied members of two distributed software development teams with different degrees of distribution, both following the Scrum approach to software development. One team's members are distributed across Ireland, England and Wales; the other has members in locations across Europe and North America. We observed the teams during their Scrum "ceremonies," and interviewed each team member, during which asked we asked team members to rate their motivation on a 5 point ordinal scale. Considering both the reported motivation levels, and qualitative analysis of our observations and interviews, our results suggest that autonomy appears to be just one of three job aspects that affect motivation, the others being competence and relatedness. We hypothesize that (1) autonomy is a necessary but not sufficient condition for motivation among experienced team members, and (2) autonomy is not a motivator unless accompanied by sufficient competence.
Conference Paper
Context: Working in a distributed environment poses new challenges to software engineer motivation. Problem: Where should global project managers focus their efforts so that they have the best chance of motivating their teams, for higher staff retention, increased productivity and improved software quality? Method: We asked a group of software engineers attending a workshop on global collaboration to complete a survey on software engineer motivation. We then identified motivation themes in the responses. Finally, we mapped these themes to software engineer motivators identified in previous research. Results: Thirteen participants completed the survey. Analysis of the results yielded 27 motivation categories. The vast majority (23 of 27) were partially or wholly mapped to Intrinsic motivators. Implications: We conclude that Global Software Development projects that relegate some teams to performing routine tasks (such as maintenance or testing) will experience lower productivity and quality due to demotivation. Finally, we hypothesize that GSD introduces new motivators, such as opportunities to travel and interact with different cultures.
Conference Paper
Geographic separation, lack of timezone overlap, and cultural differences are widely recognized as factors that impede communication and collaboration of globally distributed software development teams. While much research has been done into how these factors affect communication and collaboration, there needs to be a way of measuring how much effect they have. This research develops a Global Distance Metric that attempts to quantify global distance as the combination of three factors: geographic, temporal, and cultural distance. Thirty researchers and practitioners were asked to rate the degree to which distance factors affect collaboration. The responses were aggregated and used to calibrate a global distance metric. The metric revealed some surprising insights into the perception of global distance among the teams. In particular, pairs of teams had different perceptions of the cultural distance with their peers, with native English speakers perceiving a lower value than non-native speakers.
Article
The Global Software Development (GSD) paradigm has, over the last fifteen years, shifted from being novel and ground breaking to being widely adopted and mainstream. This wide adoption is partly owing to the many benefits provided by GSD, such as reduced labour costs, proximity to new markets and access to a diverse and experienced skills pool. Yet taking advantage of these benefits is far from straightforward, and research literature now includes a proliferation of guidelines, reviews and models to support the GSD industry. Although this active area of study is firmly established as a research area in its own right, the boundaries between general software engineering and GSD are somewhat confused and poorly-defined. In an effort to consolidate our understanding of GSD, we have developed an ontology in order to capture the most relevant terms, concepts and relationships related to the goals, barriers and features of GSD projects. The study we present here builds on research conducted in a collaboration project between industry and academia, in which we developed an ontology in order to provide practitioners with a “common language and conceptualisation”. Its successful outcome encouraged us to create a broader ontology that captures the current trends in GSD literature. The key ontology, along with its three sub-ontologies, are the result of a review of the relevant literature, together with several expert evaluations. This ontology can serve as a useful introduction to GSD for researchers who are new to the paradigm. Moreover, practitioners can take advantage of it in order to contextualise their projects and predict and detect possible barriers. What is more, using a common language will help both researchers and practitioners to avoid ambiguities and misunderstanding.
Article
In this article we investigate how staff turnover, acquisition, and assimilation rates affect software development cost and schedule. A system dynamics model of the software development process is employed as our experimentation vehicle. In addition to permitting less costly and less time-consuming experimentation, simulation-type models can provide useful insights into the causes behind the different behavior patterns observed. Our results indicate that staff turnover, acquisition, and assimilation rates can increase a project's cost and duration by as much as 40 to 60 percent. This suggests that the three staffing variables are indeed critical for the successful development of software systems, as well as for the accurate estimation of software development cost and schedule.
Book
Introduction Design of the Case Study Data Collection Data Analysis Reporting and Dissemination Lessons Learned
Article
Motivation, although difficult to quantify, is considered to be the single largest factor in developer productivity; there are also suggestions that low motivation is an important factor in software development project failure. We investigate factors that motivate software engineering teams using survey data collected from software engineering practitioners based in Australia, Chile, USA and Vietnam. We also investigate the relationship between team motivation and project outcome, identifying whether the country in which software engineering practitioners are based affects this relationship. Analysis of 333 questionnaires indicates that failed projects are associated with low team motivation. We found a set of six common team motivational factors that appear to be culturally independent (project manager has good communication with project staff, project risks reassessed, controlled and managed during the project, customer has confidence in the project manager and the development team, the working environment is good, the team works well together, and the software engineer had a pleasant experience). We also found unique groupings of team motivational factors for each of the countries investigated. This indicates that there are cultural differences that project managers need to consider when working in a global environment.