MASTER’S DEGREE THESIS INDUSTRIAL MANAGEMENT AND ENGINEERING

A study of how DevOps can

be adopted in offshore
projects

Anna Grönvall
Blekinge Institute of Technology, Karlskrona, Sweden 2018

Supervisor: Darja Šmite, Department of Software Engineering, BTH

[This page is intentionally left blank]
This thesis is submitted to the Faculty of Engineering at Blekinge Institute of Technology in
partial fulfilment of the requirements for the degree of Master of Science in in Industrial
Management and Engineering. The thesis is equivalent to 20 weeks of full time studies.

The author declare that she is the sole author of this thesis and that she have not used any
sources other than those listed in the bibliography and identified as references. She further
declare that she have not submitted this thesis at any other institution to obtain a degree.

Contact Information:
Author:
Anna Grönvall
E-mail: [email protected]

University advisor:
Darja Šmite
Department of Software Engineering

Faculty of Engineering Internet : www.bth.se

Blekinge Institute of Technology Phone : +46 455 38 50 00
SE-371 79 Karlskrona, Sweden Fax : +46 455 38 50 57
ABSTRACT
Background: Organizations want to reach shorter development cycles to stay competitive,
meanwhile, many organization wants to globalize their business to obtain benefits like reduced
cost, get hold of specific talent or gain global presence. Typically in software development
projects, there is a gap between development and operation resulting in a longer development
cycle due to inferior communication and collaboration. DevOps is a framework that intends to
reduce this gap with the purpose to reach shorter development cycles. However, currently, there
is lack of literature covering whether it is possible to adopt DevOps and keeping an offshore
strategy.
Purpose: The purpose of this thesis is to increase understanding about the use of DevOps in
offshore projects. This increased understanding will be the start of filling the current gap in the
literature about DevOps in distributed setups and form a basis for future research. The study
aims to suggest how DevOps framework can bridge the gap between development and
operation in offshore projects.
Method: An exploratory case study was conducted and three different offshore projects, who
had adopted DevOps, were investigated. In this study, 15 members from different projects were
interviewed to find out how DevOps had been adopted in their projects. Based on a survey sent
out to all project members, a Social Network Analysis was conducted for each project with the
purpose to identify communication patterns between members.
Results: The result of this study provided information, specific to each project, about the setup,
DevOps definition and goal, DevOps practices as well as benefits and challenges with DevOps.
Furthermore, the result presented information related to the performance of the project and,
information about the collaboration, communication, and trust within the project.
Conclusion: This study presented four possible distribution possibilities of DevOps in an
offshore project and suggested different ways to manage the work roles when adopting DevOps.
The study indicates that DevOps can be adopted in an offshore project in order to decrease the
gap between development and operation by considering three perspectives; roles and
responsibility, automated workflow and DevOps practices, and knowledge sharing
Delimitations: This study is limited to only investigate projects from one company.
Furthermore, the scope of this study does not include any economic aspects.

Keywords: DevOps, Agile, Global Software Development, Offshore

i
[This page is intentionally left blank]

ii
SAMMANFATTNING
Bakgrund: Organisationer önskar att nå kortare utvecklingscykler för att vara
konkurrenskraftiga, under tiden strävar många organisationer efter att globalisera sin
verksamhet för att nå fördelar som till exempel lägre kostnader, tillgång till specifika talanger
eller ökad global närvaro. I mjukvaruutvecklingsprojekt finns det vanligtvis ett gap mellan
utveckling och operation som resulterar i en längre utvecklingscykel. DevOps är en metod som
syftar till att minska detta gap för att nå kortare utveckling tider. För närvarande är det brist på
litteratur som behandlar huruvida DevOps kan tillämpas i globala utvecklingsprojekt.

Syfte: Syftet med denna studie är att öka förståelsen för hur DevOps kan tillämpas i globala
utvecklingsprojekt. Denna ökade förståelse kommer att vara början på att fylla den nuvarande
klyftan i litteraturen om DevOps i distribuerade projekt och utforma en grund för framtida
forskning Studien syftar till att föreslå hur DevOps kan tillämpas i globala utvecklingsprojekt
för att överbrygga klyftan mellan utveckling och operation.

Metod: En fallstudie utfördes där tre olika globala utvecklingsprojekt, som använder DevOps,
var studerade. I den här studien blev 15 medlemmar från de olika projekten intervjuade för att
få förståelse för hur DevOps blivit tillämpat i dessa projekt. Med hjälp av en enkät, som
skickades ut till alla projektmedlemmar, genomfördes en social nätverksanalys för respektive
projekt för att identifiera kommunikationsmönster mellan de olika medlemmarna.

Resultat: Resultat av denna undersökning gav information om hur respektive projekt

definierade DevOps, vilka mål de hade med DevOps, vilka DevOps-verktyg som användes samt
fördelar och utmaningar med DevOps. Dessutom presenterades resultat kopplat till prestation
samt projektmedlemmarnas kommunikation, samarbete och tillit.

Slutsats: Denna undersökning presenterar fyra olika distribuerings möjligheter av DevOps i

globala utvecklingsprojekt samt olika sätt att organisera arbetsrollerna när DevOps tillämpas.
Studien indikerar att DevOps kan tillämpas i offshore projekt för att minska klyftan mellan
utveckling och operation. Detta utifrån tre perspektiv: Roller och ansvar, automatiserat
arbetsflöde och DevOps-verktyg samt kunskaps utbyte.

Avgränsningar: Denna studie är begränsad till att enbart undersöka projekt från ett företag.
Dessutom har omfattningen av denna undersökning inte tagit hänsyn till några ekonomiska
aspekter.

Nyckelord: DevOps, Agile, Global mjukvaruutveckling, Offshore

iii
[This page is intentionally left blank]

iv
PREFACE

I would foremost like to thank my supervisor Darja Šmite. Thank you for your valuable insights,
expertise, and commitment during this period. Without you as a source of inspiration and
without your support, this work would have been much harder. Thanks to Aivars Sablis for all
hours spent helping me conducting the social network analysis and sharing you expertise. Also,
I would like to thank Ashish, my contact person from the company, for taking the time to help
me get in contact with the right persons.

I would also like to thank my family for the encouragement and support during this semester.
Thanks to Tobias Karlsson for making sure I could focus on my education by helping with
duties outside of school. Finally, I would like to thank Jennie Karlsson for supporting me during
this period. I appreciate all the times you have encourage me and got me back on track.

Anna Grönvall
2018-06-10

v
[This page is intentionally left blank]

vi
NOMENCLATURE

Acronyms

Dev Development

DevOps A combined word from development and operation

QA Quality Assurance

Ops Operation

PM Project Manager

SA Software Architect

Vocabulary Description

Continuous Delivery A method to ensure that code quickly and safely can be deployed
to production by deliver every change in the code to a test
environment similar to the production environment

Continuous Deployment A method similar to continuous delivery, but if the code pass the
automated tests, it is deployed to production automatically

Continuous Integration A practice for continuously merging work to a shared repository

IT Operation Include, for example, software configuration management, bug

tracking management, making software build and deployment.

Offshore Leveraging resources from another country

Onshore Leveraging resources from the same country

Site One location in distributed projects

vii
[This page is intentionally left blank]

viii
TABLE OF CONTENTS

ABSTRACT ...............................................................................................................................I
SAMMANFATTNING ......................................................................................................... III
PREFACE ................................................................................................................................ V
NOMENCLATURE ............................................................................................................. VII
TABLE OF CONTENTS ....................................................................................................... IX
LIST OF FIGURES ............................................................................................................... XI
LIST OF TABLES ................................................................................................................. XI
1 INTRODUCTION ............................................................................................................ 1
1.1 INTRODUCTION ................................................................................................................ 1
1.2 PROBLEM DISCUSSION .................................................................................................... 2
1.3 OBJECTIVES ..................................................................................................................... 3
1.4 THESIS QUESTIONS .......................................................................................................... 3
1.5 THE COMPANY ................................................................................................................ 4
1.6 EXPECTED OUTCOME ...................................................................................................... 4
1.7 DELIMITATIONS ............................................................................................................... 4
2 THEORETICAL FRAMEWORK ................................................................................. 6
2.1 AGILE DEVELOPMENT PROCESS IN OFFSHORE PROJECT .................................................. 6
2.2 DEVOPS .......................................................................................................................... 6
2.2.1 DevOps Definition .................................................................................................... 6
2.2.2 DevOps Practices ...................................................................................................... 7
2.2.3 Benefits and Challenges with DevOps ...................................................................... 8
2.3 GLOBAL SOFTWARE DEVELOPMENT ............................................................................... 9
2.3.1 Global Distributed Project Setup............................................................................... 9
2.3.2 Distributed Project Challenges ................................................................................ 10
2.3.3 Knowledge in Offshore Project ............................................................................... 10
2.4 DEVOPS IN OFFSHORE PROJECT .................................................................................... 11
2.4.1 Setup of DevOps in Offshore Project ...................................................................... 12
2.4.2 Benefit and Challenges ............................................................................................ 12
2.5 SUMMARY ..................................................................................................................... 13
3 METHOD ........................................................................................................................ 14
3.1 PRE-STUDY .................................................................................................................... 14
3.2 RESEARCH DESIGN ........................................................................................................ 15
3.3 DATA COLLECTION METHODS ...................................................................................... 15
3.3.1 Qualitative Methods ................................................................................................ 16
3.3.2 Quantitative Methods .............................................................................................. 16
3.3.3 Primary Data ........................................................................................................... 16
3.3.4 Secondary Data ....................................................................................................... 16
3.3.5 Interviews ................................................................................................................ 16
3.3.6 Social Network Analysis ......................................................................................... 18
3.4 DATA ANALYZE METHODS ........................................................................................... 19

ix
 3.4.1 Analysis of Interviews ............................................................................................. 19
3.4.2 Social Network Analysis ......................................................................................... 20
3.5 VALIDITY ...................................................................................................................... 20
4 RESULTS ........................................................................................................................ 22
4.1 PROJECT 1 ..................................................................................................................... 22
4.1.1 Offshore Setup ......................................................................................................... 22
4.1.2 DevOps Definition and Goal ................................................................................... 22
4.1.3 Bridging the gap ...................................................................................................... 23
4.1.3.1 Roles and Responsibilities ............................................................................... 23
4.1.3.2 Automated workflow and DevOps practices ................................................... 24
4.1.3.3 Knowledge sharing ........................................................................................... 24
4.2 PROJECT 2 ..................................................................................................................... 25
4.2.1 Offshore Setup ......................................................................................................... 26
4.2.2 DevOps Definition and Goal ................................................................................... 26
4.2.3 Bridging the Gap ..................................................................................................... 27
4.2.3.1 Roles and Responsibility .................................................................................. 27
4.2.3.2 Automated Workflow and DevOps practices ................................................... 28
4.2.3.3 Knowledge Sharing .......................................................................................... 28
4.3 PROJECT 3 ..................................................................................................................... 30
4.3.1 Offshore Setup ......................................................................................................... 31
4.3.2 DevOps Definition and Goal ................................................................................... 31
4.3.3 Bridging the Gap ..................................................................................................... 32
4.3.3.1 Roles and Responsibility .................................................................................. 32
4.3.3.2 Automated Workflow and DevOps Practices .................................................. 33
4.3.3.3 Knowledge sharing ........................................................................................... 33
4.4 SIMILARITIES AND DIFFERENCES BETWEEN THE PROJECTS ........................................... 35
5 DISCUSSION ................................................................................................................. 37
5.1 ANALYSIS OF THE INVESTIGATED PROJECTS ................................................................. 37
5.1.1 DevOps Definition and Goals .............................................................................. 37
5.1.2 DevOps Practices ................................................................................................. 37
5.1.3 Bridging the Gap in the Investigated Projects ...................................................... 38
5.1.3.1 Roles and Responsibilities ............................................................................... 38
5.1.3.2 Automated Workflow and DevOps Practices .................................................. 39
5.1.3.3 Knowledge Sharing .......................................................................................... 40
5.1.4 Performance ......................................................................................................... 41
5.1.5 Most Successful Setup ............................................................................................ 41
5.2 DEVOPS CHARACTERISTICS .......................................................................................... 42
5.3 DISTRIBUTION OF DEVOPS IN OFFSHORE ENVIRONMENT .............................................. 43
5.4 ADOPTION OF DEVOPS IN OFFSHORE PROJECTS ............................................................ 45
6 CONCLUSIONS............................................................................................................. 47
6.1 CONCLUSION ................................................................................................................. 47
6.2 CONTRIBUTION OF THIS STUDY ..................................................................................... 48
7 RECOMMENDATIONS AND FUTURE WORK ...................................................... 49
7.1 SUGGESTIONS OF FUTURE WORK .................................................................................. 49
AFTERWORDS ..................................................................................................................... 50
REFERENCES ....................................................................................................................... 50

x
APPENDIX A: INTERVIEW– PROJECT MANAGER ................................................... 54
APPENDIX B: INTERVIEW– PROJECT MEMBER ...................................................... 56
APPENDIX C: SURVEY FOR SNA .................................................................................... 58

LIST OF FIGURES
FIGURE 3. 1. AN EXAMPLE OF HOW A SNA-GRAPH CAN LOOK LIKE .......................................... 20

FIGURE 4. 1. DEVELOPMENT AND OPERATION DISTRIBUTION ACROSS LOCATIONS FOR PROJECT 1

.......................................................................................................................................... 22
FIGURE 4. 2. ROLES AND RESPONSIBILITIES IN PROJECT 1 ......................................................... 23
FIGURE 4. 3. SNA GRAPH PROJECT 1 ......................................................................................... 25
FIGURE 4. 4. DEVELOPMENT AND OPERATION DISTRIBUTION ACROSS LOCATIONS IN PROJECT 226
FIGURE 4. 5. ROLES AND RESPONSIBILITIES IN PROJECT 2 ......................................................... 28
FIGURE 4. 6. SNA GRAPH FOR PROJECT 2 ................................................................................. 30
FIGURE 4. 7. DEVELOPMENT AND OPERATION DISTRIBUTION ACROSS LOCATIONS IN PROJECT 3
.......................................................................................................................................... 31
FIGURE 4. 8 ROLES AND RESPONSIBILITIES IN PROJECT 3 ......................................................... 33
FIGURE 4. 9 SNA GRAPH FOR PROJECT 3 .................................................................................. 34

FIGURE 5. 1 DEVOPS INCLUSION IN DEVELOPMENT CYCLE ....................................................... 42

FIGURE 5. 2 SCALE TO DECIDE HOW DEVOPS A PROJECT IS ....................................................... 43
FIGURE 5. 3. DIFFERENT DISTRIBUTION POSSIBILITIES OF DEVELOPMENT DUTIES AND
OPERATIONAL DUTIES IN OFFSHORE SETUP ....................................................................... 44

LIST OF TABLES
TABLE 3. 1. A TABLE OVER THE PROJECT MEMBERS THAT WERE INTERVIEWED, PROVIDING
INFORMATION ABOUT THE RESPONDENT’S ROLE, LOCATION, AND BELONGING PROJECT.... 17

TABLE 4. 1. ROLE ACCESSIBILITY PROJECT 1 ............................................................................ 25

TABLE 4. 2. ROLE ACCESSIBILITY PROJECT 2 ............................................................................ 30
TABLE 4. 3. ROLE ACCESSIBILITY PROJECT 3 ............................................................................ 34
TABLE 4. 4. A TABLE OF SIMILARITIES AND DIFFERENCES BETWEEN THE PROJECTS .................. 36

xi
[This page is intentionally left blank]

xii
1 INTRODUCTION
This chapter will introduce the subject of this study. First an introduction to the studied area
will be presented followed by a discussion of the problem in order to give the reader a brief
insight to the area of this study. Furthermore, objectives, research question and delimitations
of this study will be presented and the problem will be motivated.

1.1 Introduction
Releases of recurring software can, in the modern era of interconnected and highly available
systems, occur at the same time as the software is being used. These frequent software releases
result in new requirements for software organization who, among other things, need to closely
monitor possible issues in the production system with the purpose to provide optimum user
experience [1]. The life cycle of products has become shorter and tend to continue shrinking.
In the electronic and material area, technologies are changing rapidly which, as a result, force
to shorten the development cycle even more [2]. If the software is managed to be developed in
short cycles several benefits can be obtained. For example, the organization can stay a step
ahead of the competitors since releases reach the customer more quickly and user feedback can
be obtained more frequent helping to build the right products [3].

Meanwhile aiming for shorter development cycles to stay competitive, many software
organizations want to globalize their business in order to obtain other benefits like for example,
get hold of specialized talent, reduce development cost, gain globalize presence and close
customer proximity [4, pp. 4-10]. Some other reasons for an organization to choose an offshore
strategy can be to obtain a more business-friendly climate where business can be easier due to
tax incentives and easing governmental regulation. Another factor can be a wider scope of
knowledge since a large number of trained manpower, at different geographical places, are
available [5].

The fast speed up of communication and computing has been beneficial for distributed
development since it makes it possible to effectively adapt to rapid changes in the marketplace,
as well as in the competition, IT infrastructure, and technology [5]. However, in distributed
projects, a geographical, temporal, and cultural distance can be difficult to handle [6], resulting
in a hard time achieving good collaboration within the project.

Often in software development it has been found a gap between development and operation
resulting in them being in conflict with each other. Development department wants to see
changes, like for example new features, be delivered to the customer more quickly and
operation department emphasis stability and do not feel confident in changing the system that
often since then quality and security can’t be guaranteed [7] As a result, longer development
cycle will occur, making it difficult for companies to reduce it due to lack of collaboration
between development and operation. DevOps is a framework that intends to decrease the gap
between development and operation, but there is not much research on whether DevOps
successfully can be adopted in an offshore project where other factors tend to inhibit
cooperation between project members.

1
1.2 Problem Discussion
No matter which type of software development model used, often operation personnel and
development personnel are working in two different silos [7]. The operation personnel
considers the ones who are responsible for putting software into production and manage the
production infrastructure [7], more specifically, they are responsible for IT Operations like
software configuration management, bug tracking management, making software build and
deployment [8]. Development personnel are the ones who are responsible for developing and
test the software [7].

In the waterfall model, which is a plan-driven model, operation and maintenance are involved
in the last phase of the development cycle [9, pp. 30-32]. The same goes for development
models with an agile approach like for example scrum, were general objectives are formulated
in the first phase, in the second phase a sprint cycle is iterated with four steps; assess work to
be done, select what to do, develop it and review. In the last phase, the project is enclosed [9,
p. 73]. The engineering education model CDIO can be used to describe a typical software
development process. CDIO stands for Conceive, Design, Implement and Operate [10]. The
CDI part can be described as the development part of the software, where the software is
conceptualized and requirements for the product are established, then the product is going to be
developed by design and implement it. These three phases are working close to each other and
the operation part is strictly separated from CDI.

As mentioned, it has been found that often in software development project there is a gap
between development and operation resulting in them being in conflict with each other.
Development wants to see changes, like for example new features, be delivered to the customer
quickly, meanwhile operations emphasis stability and do not feel confident with the system
changing that often [7]. Operation department does not feel confident putting the software into
production because they can’t guarantee the quality of the product. As well, since operational
tasks are not considered at an early stage, some modification may be necessary in a later stage
in order for the software to function in the production environment. Another problem is that the
time from observation of an error until repairing it may take some time since development are
shielded from customer feedback [11]. As a result, longer development cycle will occur, making
it difficult for companies to achieve shorter development cycles due to lack of collaboration
between development and operation. Furthermore, projects where developers and IT operations
personnel do not collaborate, are found more likely to fail, have poor outcomes, falls short of
the goal and deliver products that do not reach their true potential. The reason for this is that
testing and activities for information security are involved at a late stage when it often is too
late to handle the problems found in a proper manner. Furthermore, a lot of manual effort and
too many handoffs of critical factors leads to inferior quality, and longer lead time with a final
outcome that affects the customers and company negatively [12].

To overcome this barrier between developers and operations personnel a conceptual framework
called DevOps can be introduced which aims to reintegrate development and IT Operations
[13]. DevOps is a relatively new term that has different types of content associated with it [7].
Lately, many organization has shown great interest in this new organizing approach to
development and operation, and DevOps is also a popular topic in scientific research [14]. Even
though there are multiple definitions of DevOps with a different perspective, the core purpose
with DevOps is the same; to bridge the gap between development and operation as well as
leverage important skills and knowledge in order to be able to provide a product or service to
the customer more continuously [13].

2
As mentioned in the introduction section, there are several reasons for a company to globalize
their organization, however, geographical, temporal, and cultural distance tends to pull project
members apart and inhibit the collaboration between project members. As a result, it is difficult
for the project to perform optimally.

The gap between development and operation inhibits organizations' work against achieving
shorter development cycles. DevOps is a framework that more often is adopted in software
projects in order to bridge this gap, however, there is not much research on whether DevOps
successfully can be adopted in an offshore project where it traditionally already is a large gap
among team members due to geographical, cultural and temporal distances. Therefore, this
study aims to investigate how DevOps may bridge the gap between development and operation
in an offshore project.

1.3 Objectives
The problem described above regarding how to achieve shorter development cycle in an
offshore project by bridging the gap between development and operation resulted in the subject
of this thesis. The purpose of this study is to increase understanding about the use of DevOps
in offshore projects. This increased understanding will be the start of filling the current gap in
the literature about DevOps in distributed setups and form the basis for future research. The
study aims to suggest how DevOps framework can bridge the gap between development and
operation in offshore projects. The goal is not to be able to draw any definitive or general
conclusions, instead the goal is to increase the understanding within the subject and present
findings for further investigation based in findings found when investigating three different
offshore projects were DevOps has been adopted.

The company’s projects were investigated aiming to see how far they have come with the
adoption of DevOps in each project, how they worked with DevOps within the projects and
how well they performed considering collaboration, communication, quality of the product and
length of development cycle. The goal of collecting this data from the company was to see if
there is a connection between how far the project has come with the adoption of DevOps and
how they perform. Furthermore, in order to reach the aim of this study, benefits and challenges
that the projects faced when adopting DevOps were identified. The focus was on the challenges
that were caused due to the distribution and dispersion of an offshore project and how this
factors may impede the structure of the process.

1.4 Thesis Questions

To be able to make sure that the purpose of this thesis had been reached, following research
question was established;

RQ 1: How does DevOps bridge the gap between development and operation in an
offshore project?

Following sub questions were established in order to help answer the research question:

RQ 1.1: What characterizes a DevOps project?

RQ 1.2: Which are the possible distribution possibilities of DevOps in an offshore project
from a location perspective?
3
 RQ 1.3: Which project setup was found most successful for the collaboration between
development and operation within the company?

The main research questions aim to suggest how DevOps can bridge the gap between
development and operation, based on the finding in the company’s projects and the literature
review. To be able to answer the main research question it is important to know what a DevOps
project actually is. Therefore, the first sub-question was established with the aim to identify
what characterizes a DevOps project. Another important factor to consider is which setup of
DevOps are affected by the offshore strategy. Therefore, the second sub-question was
established with the aim to identify which are the possible ways to distribute DevOps across
the sites. The third sub-question was established in order to see if there is any setup in the three
projects that were more successful and if it is possible to identify any factors that tend to foster
better collaboration between development and operation. Once the sub-questions were
answered, the result was used to answer the main research question.

1.5 The Company

The company that has been studied will be anonymous in this report and only referred to as “the
company”. The main task for the company was reselling of technology products and the
company provided end-to-end mobility solutions for their clients. The organization was located
in Americas, Europe, and Asia and worked mainly with offshore projects which means that
teams worked on the same project but from different countries. The company had several
ongoing offshore projects and were on their way of going from continuous integration to
DevOps continuous release. The company was positive to participate in this study with hope to
see if it was possible to map any factors that were more crucial to consider to bridge the gap
between development and operation.

For this study, three ongoing projects, where DevOps practices already have been adopted, were
investigated.

1.6 Expected Outcome

The expected outcome was to suggest how the gap between development and operation can be
reduced in an offshore project. To reach this, it needed to be identified what actually
characterizes a DevOps project and how DevOps can be set up in an offshore environment.
When investigating the company, the expected outcome was to identify which factors fostered
better collaboration between developers and operation personnel, and if there was any setup
found more successful for the collaboration.

1.7 Delimitations
This study was limited to offshore software development projects only and just one company
was investigated. However, within this company, three projects with different customers, and
countries involved were investigated. The scope of this study does not include any economic
aspect.

Within the timeframe and budget for this study, it was not possible to visit the sites where the
projects were located. Therefore, it was not possible to have any real person meetings or do any

4
observations. All communication was performed using a computer or phone. As well, within
the timeframe for this study, it was not possible to follow projects from the point they started
adopting DevOps and see how the performance changed or if shorter development cycle were
reached. Only projects who had already adopted DevOps were chosen to investigate. As a
result, in this study, there are not any metrics or actual evidence on how the projects had
changed regarding performance and collaboration. Mainly project members own opinion were
used to investigate these aspects.

This study will not in depth investigate how DevOps can be adopted in an offshore project or
how the practices worked and were implemented. The study aimed at creating an overall
understanding of DevOps in an offshore project to see how, if at all, DevOps reduced the gap
between development and operation in distributed projects.

5
2 THEORETICAL FRAMEWORK
In this chapter, literature that has been earlier published and is connected to the area of this
study will be presented in order to provide a theoretical background. This chapter begins with
theory relevant for this study and will end with a section presenting related work within the
area of DevOps in offshore projects.

2.1 Agile Development Process in Offshore Project

Agile methods aim to avoid time-consuming practices that do not add any significant value to
the project and instead focus on interaction, customer collaboration and fast response to changes
[15]. In a fast-changing market, agile methodology helps reduce the time-to-market, however,
a temporal, geographical and sociocultural distance that occur in global projects can make it
difficult to implement agile methods. Agile practices are inhibited by, among other factors, less
face-to-face interactions and less on-site customer collaboration in global projects, therefore, a
common view is that agile methods are not suitable to apply in global software development
projects [15]. On the other hand, Helena Holmström et.al found that agile practice, like for
example Scrum and XP, were useful in global software development since it improved
communication, coordination, and control within the teams. Furthermore, they found that agile
methods reduced some of the challenges that occurred due to temporal, geographical and
sociocultural distance [15]. In a case study, Ajay Danait also found that agile practices can work
well within offshore project [16], which goes in line with previous authors founding.

2.2 DevOps
In this sub-section, DevOps will be introduced further. This section mainly contains findings
from peer-reviewed literature, however, these sources have been complemented with some grey
literature. It has been found that inclusion of grey literature is important in that sense that it
provides variety, currency and increase the utility of academic inquiry [17]. For example, Tom,
Aurum, and Vidgen conducted a study on technical debt and found in their preliminary study
that the academic literature available for their study where not enough and decided to use grey
literature in their research [18]. Especially in software engineering, it has been proved that grey
literature generates great value for the literature review since a broad search is considered [19].
Example of grey literature are books, government reports, company publications, news articles,
annual reports, blogs, email and tweets [17].

2.2.1 DevOps Definition

Although agile practices aim to improve collaboration among all stakeholders a current problem
in agile teams is the gap between development and operational personnel. Elisa Diel at al. claims
that in order to overcome this barrier between development and operations a conceptual
framework called DevOps can be introduced which aims to reintegrate development and IT
Operations [13]. However, it is important to notice that DevOps practices do not only include
the work of developers or operation engineers. In order to achieve DevOps, fundamental
changes of the system may be necessary which affect the workflow for the persons working
with getting the system into production and support it, like for example software architects [11].
Also, testing teams, business analysts, automation teams, and other stakeholders can be
involved in DevOps adoption [20].

6
DevOps is a relatively new term that has different definitions connected to it which may differ
slightly from each other. Some define DevOps as an acronym for Development and Operations
of information technology systems and applications and claims that the gap between
development and IT operations depends on four factors; communication, cooperation, culture,
and collaboration. Other define it as a stub of global company collaboration were developers
and operation engineers work together in order to obtain better knowledge diffusion, and in an
early stage be able to identify critical issues instead of afterward by having stability, monitoring,
and backup [13]. Riungu-Kalliosaari et al. define DevOps as several practices that can be used
with the purpose to reduce the time from when a change is committed in a system to when the
change is placed into normal production, meanwhile guaranteeing high quality. Furthermore,
they claim that it extends collaboration between the developers and operation personnel, and
erasing the management of changes. Also, the last mentioned authors claim that there are two
so-called core principles were the first phenomenon highlights the collaboration between
development and operation meanwhile the second phenomenon focus on agile principle and
automation used to organize and handle deployment environment [1].

DevOps can be considered as an extension of agile methodology [21] but, according to Gene
Kim et al. it is important to notice that DevOps does not replace Agile, instead it should be seen
as DevOps principles are compatible with agile practices [12]. Although DevOps might be seen
as an extension of agile practices, Banica et al. found that DevOps has potential to become a
project management methodology aiming for increased efficiency of design activity and can be
used in order to make a transition of components from design to operation faster. However, as
mentioned before there are different definition and interpretation of DevOps where some see it
as a description of skill-sets meanwhile others claim that it is an IT mindset [21]. Ramtin
Jabbari, Nauman bin Ali, Kai Petersen conducted a systematic mapping study in order to find
out how DevOps has been characterized in the research literature by investigating DevOps
definition and practices. The authors proposed following definition of DevOps [22]:

DevOps is a development methodology aimed at bridging the gap between Development

and Operations, emphasizing communication and collaboration, continuous
integration, quality assurance and delivery with automated deployment utilizing a set
of development practices.

However, in this study, the definition, earlier mentioned, proposed by Riungu-Kalliosaari et al.
will be used.

Furthermore, a new role emerging is called “DevOps Engineer” which provide technical
support to evolve standard DevOps scripts, a foundation for execution and work with guiding
the rest of the teams in wanted direction. The purpose of this role is to facilitate the processes
of DevOps [23].

2.2.2 DevOps Practices

There are different tools that can be used, and they may even be mandatory, in order to achieve
automated DevOps and thereby deliver quality with short cycle time. Ebert presented several
automation tools for DevOps and categorize the tools into five different types which are build,
continuous integration, configuration management, logging and monitoring [24]. On the other
hand, Balalaie et al. claim that any tools or technique that decrease the time between changing
a system and transfer the change to the production environment, increase quality in terms of
code and delivery mechanism, can be considered a DevOps practice [25]. This goes in lines
with Bass, Weber and Zhu's opinion which is that all practices that intend to decrease the time

7
from when a developer commit until it is deployed can be considered a DevOps practices. This
regardless of the practices involve agile methods, tools or forms of coordination [11]. Some
claims since every company is unique, where the environment and project characteristic differ
from each other, companies need to find their own approach to achieve DevOps and select
suitable tool, architecture and culture that fit their needs [24].

Jabbari, Ali, and Petersen found in their systematic mapping that many DevOps practices were
shared with agile practices, but also found that some practices were specific for DevOps like
for example continuous monitoring of the system’s performance which is a practice for
automating the analysis of the application. Example of other DevOps practices found in this
systematic mapping was continuous planning, continuous integration, continuous delivery,
continuous deployment, automated testing, process standardizations and use of data to support
quality assurance [22].

Gill et.al conducted a systematic literature review in the context of DevOps adoption and found
that the two most highlighted DevOps process where Continuous delivery pipeline and
continuous improvements. The process named continuous delivery pipeline includes build,
acceptance test, performance test, and manual test production. The second process, continuous
improvements, includes continuous integration, continuous deployment, continuous testing,
continuous evolution and continuous monitoring. The previously mentioned authors also found
that other DevOps processes included practices that covered areas like service quality,
monitoring and optimization, automatic security testing, and deploy to test environment.
However, the latest mentioned practices where not mentioned in as large extension as the
practices in the two first DevOps process [23]. Many of this practices goes in line with Jabbari,
Ali and Petersen findings mentioned earlier.

2.2.3 Benefits and Challenges with DevOps

DevOps is beneficial since it makes it possible to monitor the production system at the real time
and therefore gives the opportunity to react to anomalies immediately. Furthermore, release
cycles can be shorter and the performance, as well as the stability, can be increased since
developers and operation teams together can streamline the development process [13]. An e-
commerce platform called Wotif used DevOps by defining deployment standards for
development and operations teams. This helped them recover from a negative trend of manual
release activity and the company found a drastically improvement regarding the average release
cycle time [26]. Moreover, Balalaie et al. found that some DevOps practices, as for example
continuous delivery, allows on-demand deployment of software and another practice called
continuous monitoring provides important feedback regarding performance, which results in a
greater probability of detecting any operational anomalies, as mentioned before [25]. Another
benefit with DevOps is that developers and their operation colleagues can, by adopting DevOps
practices, learn from each other. This sharing of knowledge results in the different parties being
able to avoid unnecessary problem and complexity that otherwise may occur in the future [27].

However, adopt DevOps into an organization is not always easy and findings of studies have
shown that issues can occur due to technical and cultural transformations [28]. Developers need
to rethink their role and how they work, besides, changing the behavior of people and merge
two roles can be difficult since it requires a great working load getting everyone on the same
ground. Furthermore, before making a decision regarding adopting DevOps it is important to
consider all crucial circumstances since DevOps practices not always is suitable for the
organization and, sometimes DevOps can be hard to implement as it is a complex task to

8
determine which practices one should use. This because there is not a standard set of practices
connected to DevOps [1].

In the systematic literature review conducted by Gill et.al, mentioned in the previous section, it
was found that the most common challenges that occurred in combination with DevOps
adoption where around people, culture, and misunderstandings. More specific, the most
common challenges were related to people and culture, for example, business units do not
collaborate until it is necessary, resistance to change, and sense of responsibility. The most
common challenges connected to the misunderstanding where that a faster movement means
inferior quality. Another challenge mentioned was how to “re-engineer the split between
development and operation” which shows how important it is to clearly understand DevOps
concept as a whole [23].

2.3 Global Software Development

As mentioned in Chapter 1, many software developing organization wants to globalize their
business to obtain benefits like for example, get hold of specialized talent, reduce development
cost, gain globalized presence and close customer proximity [4, pp. 4-10]. This section aims to
give an introduction to global software development, common terminologies, challenges and
benefits.

2.3.1 Global Distributed Project Setup

Šmite et.al conducted an empirically based terminology and taxonomy for global software
engineering. They described onshoring as leveraging resources from the same country. On the
contrary, when a project is leveraging resources from a different country, it is called offshoring.
However, these countries can be located close or further away, therefore they suggested that if
leveraging resources from a country which could be reached within a two hours flight, it is
called nearshoring. If it takes more than two hours to reach the country, it is called farshoring
[29].

Teams in globally distributed projects can either be collocated or dispersed even called virtual
team. A virtual team can be described as a group of workers that are dispersed geographically,
organizationally or due to time, but brought together with help of information or
telecommunication technologies in order to complete one or more organizational task [30]. A
collocated team means that all team members are located at the same sites. A dispersed team
can either be fully dispersed were all team members are located at different sites or partially
dispersed, where two or more members are geographically collocated [31]. In a dispersed team
it can be challenging to create a good team spirit [30], furthermore, it has been found that in a
partially dispersed team the collocated group members can meet in person, however they can
only meet the other members using computer-mediated communication. As a result from the
differences of communication methods, the partially dispersed team are more likely to be
affected of problem connected to “us vs. them” compared to disperse teams [31]. Another
finding in a partially dispersed team is that the like hood of conflict and lack of trust among
sub-teams increases compared to within sub-teams [31]. However, having loosely coupled
teams may instead make it more difficult to create a common goal across the locations and the
risk of competition and blocked situation increases [30].

9
2.3.2 Distributed Project Challenges
Using an offshore strategy comes with a lot of challenges. The distance that comes along with
offshoring has shown to have a negative impact on communication, collaboration, and control
within the project [32]. Communication has been proven to be an important factor in order to
reach successful teams. However, the geographical distance can make it hard for all team
members to meet together, furthermore, a temporal distance can result in few working hours
that are overlapping for the team members. In worst case scenario, there is no overlapping time
at all [33]. Carmel and Agarwal suggested some approaches to alleviating the distance in global
software development. The temporal distance can be reduced by, for example, using
technologies as email, online discussion groups, voice mail etc. [32]. Cultural differences have
shown to have an impact on the performance of the project group. Especially cultural factors
associated with organizational hierarchy, organizational harmony, the trade-off between current
and future need and, the individuals’ opportunity to influence their work [34]. Cultural
differences can be reduced by having a common language or having the IT workers within the
corporate network with access to all knowledge bases, calendars, web pages etc. The cultural
distance can as well be reduced by the use of cultural liaison which is a person with the purpose
to facilitate the organizational flow of communication and bridge the cultures [32]. In other
words, the liaison works as a link between different teams [33].

Bird et al. conducted a study with the aim to confirm that global software development leads to
more failures in code production. Before this study, the authors had found several difficulties,
inherent by distributed development, in the literature. Some of the difficulties were
communication breakdowns, diversity in operation environment, distance, and cultural
differences. However, an unexpected result from this study was that it is possible to conduct in-
house globalized distributed development without getting any significant impact on the quality
of the code. One factor found was that cultural barriers can lead to lack of trust between sites
and misinterpretation, which was reduced with the use of liaison. Another factor found in the
successful project was the consistent use of tools resulting in every engineer being familiar with
the same tools, environments, and methods. One more important factor to consider in this
projects was that an end to end ownership, with as few owner changes as possible, was pursued
[35].

Lack of trust is a common problem in distributed projects and is an important factor to consider
since it has shown to impact the collaboration between team members. More specifically, lack
of trust results in decreased productivity and quality, non-cooperation and reduced information
exchange. Lack of trust occurs due to poor socialization, not enough face-to-face meetings,
inferior communication and poor socio-cultural fit [36].

2.3.3 Knowledge in Offshore Project

In software engineering, knowledge management has been an engagement, for example, when
using activities like process improvement, best practices, and experience factory. Knowledge
management can be used in software project in order to improve processes and make it easier
to adopt new technology [37, pp. 73-94]. Earlier studies have shown that it is important to share
knowledge in order to build trust and improve the group’s effectiveness. An inferior sharing of
information may result in problems with coordination and collaboration [38]. Furthermore, it
has been found that the better availability team members have to personal knowledge, the better
productivity and efficiency of the development team [37, pp. 73-94].

10
Even though many global software projects have access to a wide range of communication tools
to share information, it is still a common problem that information is not enough spread across
the sites in globally distributed teams [38].

2.4 DevOps in Offshore project

There are not many studies on how DevOps has been adopted in offshore project. However,
after going through some grey literature it could be identified that there are different opinions
whether DevOps successfully can be adopted in offshore projects. Some authors found that
DevOps does not mark the end of offshore development and that there still is a place for an
offshore model, however, it is important to consider the impact of geographical distance [39].
Other found that DevOps can be run in a distributed model, but it is not optimally and will result
in lower productivity level [40]. Implementing DevOps in an offshore environment may be
challenging and not quite as productive as if it had been to have it at one location. However, in
some projects, where the deployment can be delayed, offshore DevOps can be suitable since it
may be more cost efficient [41]. Even though a distributed DevOps team may not be as fast as
a collocated team, it can still provide the same quality and to a lower price tag [42].

Another finding was that the success of DevOps in a distributed team depends on the maturity
of the team, which kind of management that is used, which tools are available (for example
GitHub or Trello), the communications skills within the team, and the culture. Furthermore, the
more overlapping work hours the better, especially for development teams and infrastructure
teams which, preferably, should be located at the same site since they are the ones who are
going to collaborate most closely [43]. Except for a good team maturity, it is also important to
have high level of trust where team members are allowed to work autonomously [44].

Stillwell and Coutinho presented how DevOps was used in a project consisting of services and
technologies that interact with an OpenStack cloud computing platform. Different components
where being developed by teams from different sites in Europe. There were four development
teams responsible for the maintenance of a specific part of the architecture. Furthermore, there
was one integration team responsible for testing of all services. The team shared a Git repository
manager and each project had owners who were the only one having access to the master
branch. The other members could make changes, like adding features or fix bugs, but the owner
had to accept the changes. In this project DevOps some practices like automated testing and
feedback loop where used. In the project, it was found that the development team was more
willing to accept change, provide feedback and operate autonomously. Also, they found a
reduction of communication overhead, moreover, automated testing and deployment had sped
up the work and made it more efficient. However, these findings were not quantified [45].

From another offshore DevOps project, it was claimed that DevOps was used to overcome the
“us-and-them” mentality where software teams had the end-to-end responsibility for a software
artifact. In this project, they found that practices as for example standardize Git, automated test,
container technologies, and logging tools had helped to improve the work. The project was
found successfully adopted DevOps principals in an offshore setup, however, there were still
more principals to adapt [46].

Diel, Marczak, and Cruzes identified some challenges in offshore DevOps projects. The first
challenge was the geographical distance resulting in teams being unaware of each other’s work
which results in the team members not taking any initiatives to communicate since they did not
know what to communicate about. Furthermore, the frequency of the communication was a

11
challenge since often, the communication was not frequent enough resulting in important
information being delayed. Some other challenges were due to the socio-cultural distance,
temporal distance, and communication channels. [13].

2.4.1 Setup of DevOps in Offshore Project

One suggestion for setup of DevOps personnel was to use cross-functional DevOps teams that
are responsible for both development and operation [47], where a DevOps team consist of
developers and operation engineers [42]. In an optimal DevOps team, everyone should be
located in the same room. This because a DevOps team needs to interact with operations as well
as development, and they need to have a good communication within the team. Moreover, a
large team tends to have a slower pace since they cannot communicate in that intense manner
[40]. Some claims that it is more beneficial to have a whole cross-functional DevOps team
offshore than having it distributed since a follow-the-sun approach will not work using DevOps.
The reason for this is that close communication is the key to productivity in DevOps team [47].
In addition, instead of having DevOps offshore, it has been claimed that DevOps team can be
found nearshore meanwhile keeping a lower cost compared to having it onshore. By having the
DevOps team nearshore, it will overcome the problem with huge time differences and make it
easier to communicate [48]. This goes in line with other findings where it is claimed that in
order to increase the DevOps capabilities it is better to look more locally [49].

Another suggestion of DevOps personnel setup was to not have any dedicated DevOps team,
instead, all project members were collaborating through the entire development cycle and
thereby decreeing the jumps back and forth [39]. This is possible since DevOps blurs the line
between developers and operation engineers where work as, for example, new features,
changes, support, and deployment are done more or less by the same people [50]. This goes in
line with other findings where a sense of ownership should be introduced among the roles in
order to prevent silos being emerged [44]. If people are taking away from consequences of their
action, bad behavior might arise and they do not take any responsibility. To make people take
responsibility for their action in software development projects, cross-functional teams can be
constructed, however, this does not have to be a so-called DevOps team. Some even claim that
a DevOps team, working as a link between development and operation and responsible for the
deployment of the system is not the proper way to solve the problem. This because, for example,
development will not feel any responsibility for the release of the software and will not be aware
of what is required. Instead, a DevOps team should be responsible for building platforms for
developers allowing a self-service environment for testing and production. Furthermore, the
DevOps team should be responsible for providing a toolchain and coach as well as support
teams’ way of working. However, this can be considered the work of operation [51].

2.4.2 Benefit and Challenges

Often in offshore organizations, it is easy to forget that DevOps is not just tools, there are some
cultural aspects with DevOps as well. For example, it is difficult to get teams work together and
collaborate when adopting DevOps in onshore project and it may be even more difficult in
offshore projects since there already are other factors that may harm the collaboration. It is
therefore important to have a team leader that interfaces well with business groups,
development teams, infrastructure teams and operation teams [41]. Another cultural challenge
by adopting DevOps in offshore projects is that DevOps engineers tend to always say yes to
challenges, meanwhile, it has been found that many offshore teams have difficult to say no.
Therefore, it is important to know if the DevOps team member that are saying yes actually have
the capability to do the right work or if it needs to be pushed back to the developers [41].

12
Some benefits with distributed projects are that the time zones differences can be used to
increase productivity, lower salaries, broader access to talents and a flexible source pool. To
obtain this benefits, it is important to have a good infrastructure for communications [42]. It is
also important to get hold of the right talent for success and sometimes the right people are not
available at the own location. Adopting DevOps in distributed projects can help reach
advantages and it is possible to make it successful as long as there is a communication strategy.
Especially in-person meeting through a technology tool has been found helpful [52].

2.5 Summary
Even though there are different definitions of DevOps, it can be described as a framework which
aims to decrease the gap between development and operation to reach shorter development
cycles. How to adopt DevOps in an organization may differ in different organization depending
on specific assets, requirements, and goals. Furthermore, there a multiple practices to use that
can be counted as DevOps practices and not every practice is necessary to adopt, however, the
practices most common were continuous integration, continuous delivery, automated testing,
and monitoring.

In distributed projects, temporal, geographical, and cultural differences were shown to affect
the communication and performance of the teams. These were also challenges mentioned in the
grey literature regarding adopting DevOps in offshore project. Moreover, in the literature
connected to DevOps in an offshore project, it was found that there were successful cases as
well as cases that had not succeeded well.

13
3 METHOD
This chapter describes the methods used to conduct this study. It included methods for data
collection as well as analysis of the data. The first section of this chapter will present the pre-
study that was performed. Following sections will describe which research design that was
chosen for this study, present the data collection methods and how the data collected where
analyzed. This chapter will end with a section about the validity of this study.

3.1 Pre-study
Before investigating this three projects at the company a pre-study was conducted within the
subject DevOps in offshore projects. Following search strings were used:

(DevOps) AND (Offshore)

(DevOps) AND (Distributed)

Summon@BTH was used when searching for peer-reviewed material which means that the
search is done in several databases simultaneously. However, when searching for peer-reviewed
material, no relevant articles were found. Therefore, grey literature was decided to include in
order to gain a better understanding of related work. The search procedure was repeated with
the same search strings, however, this time Google Scholar and Google were used. Totally, 114
sources were gone through and three steps were checked to decide whether to include the article
or not. The three steps were:

1. If DevOps, Offshore or Distributed were included in the title

2. If the material in the source considered DevOps in an offshore environment
3. The quality of the source

In order for the sources to pass the quality requirement, the sources needed to be a full text from
a reliable source. For example, a presentation from LinkedIn in about DevOps in an offshore
environment were excluded since it was not a full text. It was a presentation with no coherent
information resulting in the reader having to fill in the gap which may result in
misunderstandings. Another source excluded from this requirement was a forum where users
were allowed to ask and answer questions. This is neither considered a qualitative source since
users are allowed to be anonymous and it is not possible to connect the text to a person or an
organization. So in order to pass the quality requirement, it needed to be a non-anonymous
person or organization that stood for the published text so the text could be connected to a
person or organization with competence within software development. After going through all
114 sources and excluded those who did not fulfill the requirements, only 20 sources remained.
The findings from this pre-study are presented in section 2.4 DevOps in Offshore Project.
However, some information from new sources has been added afterward. Based on this pre-
study, it was found that there is a gap in the literature and very little information about this
subject. That is the reason why this study aims to increase the understanding of how DevOps
can be adopted in an offshore project in order to decrease the gap between development and
operation.

14
3.2 Research Design
In this study, an exploratory research design was chosen in order to be able to answer the
research question. The main reason for this was that the problem is not well understood and the
problem is unstructured. According to Ghauri and Grønhaug, an exploratory research design is
suitable for unstructured problems [53, p. 56]. Furthermore, the purpose of this study is to
increase understanding of how DevOps can be used in offshore projects to bridge the gap
between development and operations. Since the subject is not well investigated, this study aims
to gain familiarity with the subject and to be able to identify variables for further investigation.
That is another reason why exploratory data collection is suitable, because, the purpose of that
kind of data collection is to identify key variables that later may be operationalized
quantitatively [54, p. 37].

Ghauri and Grønhaug mention five different methods which are Historical review, Group
discussion, Case study, Survey, and Experiment. In case of answering “how” and “why”
questions, a case study is the preferred research strategy. [53, pp. 107-110] In this study, it is
not possible to manipulate the behavior of the ones involved in the study, therefore a case study
is a suitable method to follow [55]. Also, a case study is suitable when aiming to answer
questions connected to “how” and “why” and is often associated with either explanatory,
exploratory or descriptive research design [53, p. 110]. Those are the reasons why a case study
was selected as a research method in this study.

Conducting a case study is appropriate when studying a single organization, as well as several
organizations, and identifying factors related to a behavior of the organization [53, p. 110] The
process of conducting a case study consist of four steps which has been followed in this study.
The first step is Drift which is at the beginning of the study and in this phase, the researcher
learns the area of interest, concepts, and terminology. Often, the research question is modified
during this phase. The following phase is called Design and in this phase, the strategy for
collecting data is chosen. In this phase, explanations to the observation that have been made so
far, are formulated and several research areas are refined from the drift stage. The third step is
called Prediction and in this phase, further case construction and analysis proceed with a
purpose of drawing conclusions. Some tentative explanation can also be established. In the
fourth and final step, which is called disconfirmation, the result is tested and analyzed further.
The purpose with this is for example to test the generalizability of the result which can be done
by testing it in different cases [53, pp. 111-112]. These steps were followed when conducting
this study except step four which is out of the scope of this study.

If the wrong method would be used, the research would had wrong focus which may result in
a misleading results. It is therefore important to choose right research design and strategy. In
this case, qualitative method was chosen and an exploratory case study was selected which
means that the research questions should be related to “what”, “why” and “how”. If this is not
the case, another strategy would have been better to use in order to guarantee a more trustworthy
result.

3.3 Data Collection Methods

This study was to the core a qualitative study since an exploratory research design was selected,
the purpose was to increase understanding, and there was a low previous knowledge of the
interest to investigate [53, pp. 196-197]. The data was collected mainly through interviews,
with focus on creating an understanding and to explore how DevOps worked in specific

15
offshore projects rather than project the finding in a large perspective. Interviews were selected
instead of surveys to obtain the possibility to ask further questions to get a deeper
understanding. Observations was an alternative method to consider since it may had provided
a more accurate perception of the situation, but due to the tight timeframe, it was not possible
to visit the sites in this project. When conducting the social network analysis, quantitative data
was collected. This data was used to create graphs that visualize communication patterns and
how well connected the team members are to each other. That is the only use of quantitative
methods in this study.

3.3.1 Qualitative Methods

As mentioned, since the purpose was to increase understanding a qualitative research is
recommended since there was low previous knowledge of the phenomena that were in the
interest to investigate. The selected qualitative methods in this study were conducting semi-
structured interviews and collecting data for the theoretical framework presented in section 2.
Theoretical Framework.

3.3.2 Quantitative Methods

This was a qualitative study, however, one quantitative method was used when conducting the
social network analysis. A survey was conducted (see Appendix C) where the respondent was
asked to answer questions related to knowledge sharing and the questions were weighted 0-5
respectively 1-5. This in order to use the data to create graphs that visualize the communication
flow within the projects.

3.3.3 Primary Data

Primary data is that kind of data that is collected specifically for a study like for example
through observations, questionnaires, and interviews. [53, pp. 90,99]

The company’s projects were studied in order to identify how they managed and organized
development and operation process according to DevOps practices. Information about
challenges the company faced, how they manage them and hoe their way of working had
benefited from adopting DevOps, are examples of primary data that were collected from
interviews. Furthermore, data of how the team members were sharing knowledge is another
example of primary data that were collected using surveys.

3.3.4 Secondary Data

Secondary data have been produced and collected from others who probably have another
purpose than this study. This is important to consider and therefore this kind of sources need to
be critically reviewed. Examples of secondary data are books, journal articles and online data
sources [53].

First, in this study, a more detailed literature review was conducted in order to gain a better
understanding within the area, and to investigate related work. For this, secondary data was
used, mainly in form of books and articles in journals. As mentioned, grey literature was
included to give an insight of related work.

3.3.5 Interviews
Interviews were conducted to collect data that will help find out which DevOps setup was found
most successful in the company’s three projects. Example of information collected was how

16
the team member defined DevOps, how DevOps was distributed in an offshore environment,
and what were the perceived benefit and challenges.

For an exploratory research, it is an advantage to have in-depth interviews with open-ended

questions. This because the respondent is free to answer to their own thinking and the researcher
can ask subsequent questions to bring more value to the data collected. In this study, the type
of the interviews were semi-structured, which means that the topic and issues to be covered
were determined beforehand. Furthermore, the people to interview and questions to ask were
as well determined before starting the interview process [53, p. 126]. The interview questions
for this study can be found in Appendix A and Appendix B. Micael Quinn Patton presented
three approaches to qualitative interviewing [54], a combination of two of them were used in
this study. The approaches Interview Guide Approach and Standardized Open-Ended Interview
Approach were combined, which means that a number of questions were asked to all
respondents, but the interviewer could be flexible and was allowed to explore certain subjects
in greater deep.

The interviews were conducted using a communication tool called Zoom which made it
possible to have video- and phone conferences. Some interviews were conducted individually,
and some were conducted in a group. If the interviews were conducted in a group, a chat
functionality in Zoom was used. The respondents could send private messages when answering
the questions, minimizing the risk for one respondent being afraid to express an opinion in front
of a colleague. However, in the case when group interviews were conducted, the respondents
often discussed their different opinion with each other which in many cases added value to the
data collection. The table below present all the respondent in form of their role in the project,
which site they belong to as well as the project they worked in.

Role Site Project

Project Manager India Project 1
Operation Engineer South-east Asia Project 1
Quality Assurance Lead India Project 1
Developer India Project 1
Developer India Project 1
Developer India Project 1
Project Manager Spain Project 2
Software Architect Spain Project 2
Operation Engineer South-east Asia Project 2
Operation Engineer South-east Asia Project 2
Developer Spain Project 2
Quality Assurance Lead South-east Asia Project 2
Project Manager South-east Asia Project 3
Developer South-east Asia Project 3
Developer South-east Asia Project 3

Table 3. 1. A table over the project members that were interviewed, providing information
about the respondent’s role, location, and belonging project

Almost every interviews were allowed to be recorded which gave the researcher the opportunity
to go back and listen to the interviews again. In case the interview could not be recorded,

17
extensive notes were taken and immediately after the interview ended, the notes were developed
into a text in order to reduce the risk that something was forgotten.

It was hard to determine how many interviews that should be performed in order to reach a
trustworthy result since often it depends on the quality of the interviews. In his study, an
approached mentioned by Johan Alvehus was followed which means that interviews were
performed until finding a fullness that indicated a good coverage. This could be identified when
for example the information obtained from the interviews was recurrent [56, p. 69].

3.3.6 Social Network Analysis

A social network consists of a set of actors and relationships between these. In order to illustrate
the social network a graph can be constructed using nodes and edges were the nodes are
representing the actors and the edges represent the relationship [57, p. 18].

A social network analysis (SNA) was conducted in this study with the purpose to illustrate how
the members of a team interact with each other and members of other teams within the same
project. The goal with doing a social network analysis was to explore the level of integration
across different sites through communication patterns and interaction among people working
in the same team, across teams and with other members within the same project. The expected
outcome was to identify communication patterns, clustering and cohesion within and between
different members of DevOps projects, and detection of areas in which integration should be
fostered. The reason for this information being obtained was that, as mentioned in section 2.3.2.
Distributed Project Challenges, communication is an important factor for a distributed team’s
performance. The graphs can, in other words, be proxies to DevOps team performance.

Communication patterns are impacted by several aspects. For example, how often actors share
information, how aware they are of each other’s work or how much they trust each other. This
study mainly emphasizes the following aspects: how often the project members share
knowledge with each other and the accessibility of the people in the network.

Borgatti, Everett, and Johnson presented two different types of social networks; whole network
research design and personal-network research design. The whole-network research design
aims to plot al edges to all nodes in a given set. A personal-network have one or several nodes
which are the main focus [58]. In this study, a whole-network research was conducted instead
of personal network. This means that all ties among all project members were considered. An
egocentric point of view was not chosen since the aim was to create an overview of the
knowledge sharing within the entire project. A whole network-research was possible to conduct
since the projects’ networks are quite small. In a larger network, if conducting a whole-network
analysis the cost increases quickly with the size of the networks and as a result, the researcher
may lose some data and needs to scale back the questions that are intended to ask. In those
cases, a personal-network can be preferable, if the aim is to gain rich and detailed data [58].

When conducting the SNA an online survey (Appendix C) were sent out to each project member
in the three project. They were asked to rate, on scale Never-Very frequent, how often they
shared knowledge with each other. Both transferring knowledge as well as receiving it. The
purpose of sharing knowledge can differ. For example, the knowledge can be related to the
process which includes knowledge about development tools, ways of working, coding
conventions etc. It can also be knowledge related to the project like for example knowledge
about milestones, delivery schedules, and progress updates. Another aspect is knowledge
related to the product. Product knowledge is knowledge related to the product, in other words,

18
the knowledge about product features and how these different product features relate to each
other. For example, product knowledge includes understanding about product standards,
protocols, reviews, program properties, architecture, concept location within the code etc.
Product knowledge can, among other things, be used to reuse successful implementation
strategies [59] [60]. In this SNA, only they product-related knowledge were considered since
this type of knowledge was found most relevant to this study. Process-related and project-
related knowledge may be interesting, however, in this study, it will not add that much value to
know how often the team members shared knowledge about their way of working or about
project milestones. What will add value is to see how often they share information about the
product itself. The more often they share this type of information, the greater probability that
they avoid an unnecessary problem and perform better.

The response rate in the first project was 9 out of 11. For the second project, it was 13 out of
15 and for the third project it was 19 out of 21. This is considered a very good result since even
though two persons from each project did not answer, the result could still be reliable since a
high rate of other project members had answered. This means that other members had answered
how they are connected to the members that did not answered the survey, therefore, it was
possible to include these roles in the graphs as well. What made it less trustworthy was that the
frequency of the connection was based on one person’s view and not two. Still, this was just
for two persons in each project.

It has been found that the better accessibility team members have to personal knowledge, the
better productivity and efficiency of the development team [37, pp. 73-94]. Therefore a table of
accessibility for each role within the team was constructed. The number could obtain a value
between 1-5 where 1= Very difficult to access and 5 = Very easy to access.

3.4 Data Analyze Methods

The process of analyzing the data can be described as a process to bring order, structure, and
meaning to a set of collected data. However, there is no single agreed way to analyze qualitative
data, but there are some helpful guidelines and advice. For example, to give meaning to
interviews they must not just be read, the researcher must focus, simplify and abstract the
information in order to be able to create a meaning [53, p. 199].

In this study, a method called Memos were used in order for the researcher to be able to
remember thoughts and findings during the whole project. Memos mean that throughout the
study, notes were taken of findings and thoughts that helped the researcher get an overall
perspective and remember findings that were found early in the study process [61, pp. 117-
141].

3.4.1 Analysis of Interviews

In this study, the data from the interviews were first prepared by get the notes clean and
complement with information after going through the recordings one more time. There was no
need for a transcription in this study, therefore the notes were just edited to make it easy to work
with them. Then labels were put on a smaller unit of data, which is a method called coding.
Open coding is a process where the data is broken down, inspected and compared [53, pp. 200-
201]. In the next step, units of data were grouped and put under different categorizations. This
is a method called categorization [53, p. 201]. Once the data had been placed in different
categories a method called abstraction was used. This method builds upon categorization and
group categorizations into more general conceptual classes [53, p. 201].

19
This process was performed to generate meaning to the collected data and make it easier to
overview. More or less the same codes, categorization, and abstract level were used for each
project to be able to identify commonalities and differences in the projects.

3.4.2 Social Network Analysis

In the graph, the nodes represent the project members and the color represents the site they
belong to. How thick the edges was, indicated the frequency of knowledge sharing. The thicker
line the more frequent did they share knowledge. Since each member was asked to answer their
knowledge sharing to all of its project members, a lot of edges were created. Therefore, the
edges that represent an occasional frequency or lower were removed from the graph. In other,
words, the edges shown in the graphs represented a frequent or very frequent knowledge
sharing.

Example of graph:

Figure 3. 1. An example of how a SNA-graph can look like

Also, there was a table where the accessibility of the roles within the project was presented.
The numbers could vary from 1 to 5. The higher number the more accessible.

3.5 Validity
The validity will be described from four different perspectives which are descriptive validity,
interpretative validity, theoretical validity and generalizable validity,

Descriptive validity can be described as the degree to which a description holds true and the
interpretative validity can be described as if the interpretation is actually correct [53, p. 210].In
this study, when conducting the interviews, sometimes the interviewer asked a question like
“Have I understand you correctly if..” in order to confirm different findings. Furthermore, the
use of memos helped remember findings/result from earlier stages and reduced the risk for them
to be colored from later findings. These are examples of actions that were performed to increase
the descriptive and interpretative validity.
Theoretical validity refers to the adequacy of the theory [53, p. 210]. When going through
literature multiples sources with different opinions were mentioned in order to give as objective
result as possible. Important to remember is that the grey literature only was added in order to
gain insight and not to rely on the findings.
Generalizable validity means to which extent the findings of this study can be generalized [53,
p. 211]. In this study, the generalizable validity may not be that good since the aim of this study

20
was to gain increased understanding of how DevOps can be adopted in offshore projects. Three
projects were studied to create an understanding. If aiming to reach generalizable validity, the
findings need to be investigated in a large-scale. This was outside the scope of this study,
If conducting this case study properly there should be no problem regarding the validity.

21
4 RESULTS
In this chapter, the result of this study will be presented. The result has emerged by collecting
data according to the methods described in the previous chapter. Interviews with project
members were conducted to understand how the projects were set up, the workflow and how
DevOps was being adopted. The SNA-survey resulted in graphs which are presented in this
chapter. The graphs aim to visualize communication patterns, clustering, and cohesion within
and between different members of the project.

4.1 Project 1
The members of this project worked on a mobility solution consisted of several modules, like
for example, mobile applications, responsive website and content management. The solution
was centrally driven by a complex middleware and integrated with Big Data, Enterprise
Systems, and Google Analytics

This project had been using DevOps practices since it started three years before this study, but
it needed some initial training and it was difficult to change the mindset of the project members.
One interviewee mentioned that it was important that all project members were open-minded
and ready for a change to make DevOps work. Adoption of DevOps helped the project group
to reduce errors and most of the respondent felt like the quality of the software had become
better by using DevOps practices, however, some found it hard to tell.

4.1.1 Offshore Setup

This project was mainly delivered out of two sites, India and a country in South-east Asia,
however, the account management was managed by a site in Spain. The Operation Engineer
was located in South-east Asia and Developers, Software Architect, QA Engineers and the
Project Manager were located at the Site in India. Between the two sites, there was a 1.5-hour
time difference. In Figure 4.1 the gap that this study investigates is illustrated with a red arrow.

Figure 4. 1. Development and Operation distribution across locations for Project 1

4.1.2 DevOps Definition and Goal

Different definitions of DevOps were found in the interviews for this project. DevOps was
defined as a method increasing the collaboration between development and operation and
makes it possible to achieve continuous integration since a lot of manual effort is being erased.
DevOps was also defined as a culture aiming for optimization and automation of as many
processes as possible.

22
The goal of using DevOps was to reach a shorter development cycle and make sure everything
worked when deploying the software to production. DevOps helped centralize all the builds and
all code that would be built during the production, which helped to make it available for all
people. These goals were more or less the same among all respondents.

4.1.3 Bridging the gap

This section is going to present findings of how Project 1 worked with DevOps and how that
helped to bridge the gap (illustrated in Figure 4.1) between development and operation. The
findings will be highlighted from three different perspectives. The first perspective is roles and
responsibilities which describes how responsibilities connected to development and operation
were assigned among team members. The second perspective describes DevOps practices and
tools project members worked with. The third perspective describes how project members
shared knowledge with each other, or in other words, how the project members communicated
and collaborated.

4.1.3.1 Roles and Responsibilities

When using agile methods, often the product is developed in so-called sprints of two to three
weeks. In this project the cycle was not called a sprint, instead, it was called a release which
lasted during four weeks period. The four weeks cycle began with planning, estimations, and
ended with deploying to production. When the development team started working on a release,
a master branch was created which was taking a cut from previous production branch. The
ownership of this branch belonged to the QA-teams, and Dev-teams used continuous integration
and fixed bugs on a local branch. When the Dev-team had developed a feature and tested it, a
request was made to integrate it into the master branch. They informed the QA-team that the
feature had mastered the branch and then the QA-team made automatic build, tested, reported
the process and certified it. This was a continuous process and when all stories of the release
were completed, the build was handed over to the customer.

This project consisted of collocated teams were for example backend developers formed one
team and QA formed another. There was not any specific DevOps team dedicated, instead,
more or less all project members were working with DevOps practices. In this project, the gap
was reduced having cross-functional roles. In other words, the development department was
taking responsibility for some operational task where the QA-team not only was responsible for
the product being defect free and that it went in line with requirements, the team was also
responsible for deploying the software to production. Operation was instead responsible for
maintaining the toolchain, access control, monitoring, and support. One project member
explained DevOps mindset as “… what operation can do development can do. What
development can do, the operation can answer to.” This mean, in practice everyone could
deploy to production. The roles and responsibilities are described in Figure 4.2.

Figure 4. 2. Roles and Responsibilities in Project 1

23
4.1.3.2 Automated workflow and DevOps practices
Some part of the work process was automated using DevOps practices resulting in once an error
was detected, everyone in the Dev-team could solve it and the time to fix errors was speeded
up. Since the manual effort was reduced there were less human errors, and as a result, the
development cycle was decreased. One interview described it as “the whole development
process was streamlined”. Here DevOps practices and tools help automate some of the
development processes and bridging the gap since once the software was ready for deploying
to production, the one responsible could be more confident in the software being properly
developed and tested.

Practices used in this project, connected to DevOps, were continuous integration, continuous
delivery, automated testing, automated review (which check the quality) and automated backup.
To be able to work with this practices, tools like Jenkins were used to automate processes and
GitHub were used to achieve continuous integration. This way of working provided feedback
throughout the whole process. However, if any of this tools stopped working correctly, the
whole project was delayed.

4.1.3.3 Knowledge sharing

Since adopting DevOps, the project members felt that the collaboration had improved as there
was a smoother workflow. The members of this project were collaborating across the sites using
skype and emails, however, one interviewee said: “…actually, it is not needed so much
communication, only if there is any certain problem with the branch…” In other words, the gap
between development and operation was decreased since communication overheads were
reduced. Still, when communication was required, a challenge identified was due to the time
differences between development team and operation team which make it hard to communicate
across sites, however, since it is a long ongoing project they had learned how to manage it using
the overlapping time for daily meetings. The meetings were scheduled for 15 minutes on the
morning where all project members were present. In a matter of fact, the time differences were
also mentioned as a benefit since, for example, the site in South-east Asia could check the status
of the software before the site in India. For example, the operation team could check for bugs
or problem before the rest of the project group started their day. The operation engineer was
responsible for monitoring the software in production and reported bugs to the project manager,
then the development teams fixed them.

The collaboration, communication, and trust were rated very high in this project. By almost
everyone, all factors were rated “Good” or “Very good”. There were just two persons who rated
the communication across the sites with “neither good nor bad”. This finding goes in line with
the communication patterns from the SNA shown in Figure 4.3, which indicates well-connected
project members. The awareness was rated by most of the members as “Good” or “Very good”,
but two persons rated it “Bad”.

24
 Figure 4. 3. SNA graph Project 1

The overall accessibility to each role within the project were found high as well. (See Table
4.1.)

India Designer 4.83

India Developer 4.91
India Project Manager 4.83
India Quality Assurance Engineer 4.85
India Quality Assurance Lead 5.00
India Software Architect 4.27
South-east Asia Operation Engineer 3.27
Table 4. 1. Role Accessibility Project 1

4.2 Project 2
Within this project, the members were working on two different Content Management Systems
(CMS) with respectively web platform. The two different solutions were supporting different
platforms. Furthermore, the members of this project also worked with a mobile app supporting
both iOS and Android. More specifically, in one part of the project, there was a backend system,
frontend system which is a web back office and, mobile apps for iOS and Android which were
connecting to the same backend. The other part of the project was living on the same
infrastructure but had a separated backend which was connected to the other backend and a
separate frontend as well as separate setup of apps. In this project, Docker and Docker Form
was used to containerize one big platform with loosely coupled components.

The project started 3.5 years ago and began working with DevOps practices for about six
months ago. Since the adoption of DevOps, the project had noticed a less number of bugs and
the lead time to fix them had become shorter. The development cycle had also become shorter
since DevOps where adopted, and all project members that were interviewed thought it was

25
partly due to the use of DevOps practices. The most of the project members, who were
interviewed, thought that the quality, for now, had not become better since it was to short time
frame. Before adopting DevOps the project historically had a problem when the usage of the
platform increased drastically, but this year they had zero production incidents which go back
to better collaboration and communication. If that was connected to the adoption of DevOps
was hard to tell, but it could be a contributing factor according to two interviewees. However,
a challenge with adopting DevOps faced in this project was to change the way developers
worked. Development needed to develop smaller increments more frequent and with better
quality. Otherwise, they were going to break build every time

4.2.1 Offshore Setup

This project was delivered out of Spain and a country in South-east Asia with about 5-hour time
difference between them. At the site in Spain, mainly software architect, account manager,
project manager and backend developers were located. In South-east Asia, mainly operation
engineers, QA engineers, and frontend developers were located. Figure 4.4 illustrates the
distribution of development and operation within this project and the gap between them that
was mainly investigated in this study

Figure 4. 4. Development and operation distribution across locations in Project 2

Important to notice, on the paper just one operation engineer were a member of this project,
however, they were a whole team of operation engineers helping each other. Still, only one
operation engineer was listed as a project member since this operation engineer was always
available for the members and responsible for this project. The other operations engineers were
responsible for other projects.

4.2.2 DevOps Definition and Goal

DevOps were described as a way of working that blurs the line between development and
operation. Instead of having a split ownership, where operation department is in charge of the
production system and development department responsible for developing new features, there
should be a shared ownership. Another definition found from members of this project was that
DevOps is a set of practices that are engaged to reunite two business unit, development, and
operation.

The goal was to speed up the work process, bridge the gap between development and operation,
and decrease the line between them to improve the collaboration and spread knowledge across
the teams. Furthermore, the goal was also to ensure that all members were working toward a
common goal, can easily meet, communicate faster, and deploy easier.

26
In this project, it was found that one project member interviewed did not know what DevOps
actually was. A second member mentioned that the project members never actually had got
time to think about the meaning of DevOps.

4.2.3 Bridging the Gap

This section is going to present findings of how Project 2 worked with DevOps and how that
helped reduce the gap (illustrated in Figure 4.4) between development and operation. The
findings will be highlighted from three different perspectives. The first perspective is roles and
responsibilities which describes how responsibilities connected to development and operation
were assigned among team members. The second perspective describes DevOps practices and
tools project members worked with. The third perspective describes how project members
shared knowledge with each other, or in other words, how the project members communicated
and collaborated.

4.2.3.1 Roles and Responsibility

In this project, one operation team was mainly responsible for the infrastructure, the production
environment and the stage environment of the application. Whatever deployment or operation
that needed to be done in production or in the stage environment were carried out by the
operation team. Furthermore, the operation teams owned the infrastructure and were
responsible for that the servers were up in one test environment and five QA environments. In
these environments, tasks like deployments and version management were owned by the
development team. When development wanted to move it to the next level in stage and to
produce it was done by the operation team.

This project consisted of several teams which mainly did not have any mixed roles within them.
However, the different teams worked closely together. Even though there may have been a split
between the role titles, there was not always a split of tasks. They had to work closely with the
teams. Furthermore, there was not a dedicated DevOps team helping the development team
with the automation chain and continuous delivery meanwhile the operation team was taking
care of the infrastructure. Instead, DevOps was implemented keeping the original structure of
the teams where more or less each role was working with DevOps practices. Developers were
mainly responsible for planning and develop the software meanwhile QA was responsible for
making builds, make sure the requirements were met and test of the software. Operation team
was responsible for the setup of infrastructure, for all different environments and provided a
toolchain for project members, and deployed to production. Moreover, Development Leads,
Software Architect and Operation Engineers worked closely together and communicated
frequently. This was especially needed since the infrastructure of the project was undergoing
changes. Also, these project members were responsible for monitoring the software. Primarily
Operation team monitored the software in production and received notifications about bugs.
Development lead and SA also checked the production environment, logs, etc. with a frequency
of 3-4 times per week on average. Usually, development teams fixed the bugs, but for purely
technical issues and issues specific to the platform the Operation team did bug fixing too. The
project was aiming for continuous deployment which means that Development was going to
deploy the software to production and take responsibility for some operational tasks connected
to deploying the software to production.

In Figure 4.5, some of the roles and responsibilities connected to DevOps are illustrated.

27
 Figure 4.5. Roles and Responsibilities in Project 2

4.2.3.2 Automated Workflow and DevOps practices

The project was working towards continuous integration and continuous delivery, however, that
was a work in progress. In this project, a Docker platform was used which had its own
deployment mechanism, but the goal was to reach continuous deployment, an automated
process to deploy the software. Continuous monitoring was also being used in this project. Each
container had a health-check, a test to say whether the container was healthy or not. If it became
unhealthy, the platform kicked it and started a new instance of the same container. The
automation work had begun this year and there was still a lot of work left.

Further improvements to DevOps setup, in this project, were to continue working on the
automatization processes and use continuous delivery to the production environment. A
common view of the interviews was that the quality was assumed to become better when the
project had come further with automation processes.

The gap between development and operation was reduced by automating parts of the
development process to reduce communication overheads and make sure that the software
frequently could be reliably released. Furthermore, this way of working helped speeding up the
work process since operation and development knew how to talk to each other and developers
could push cleaner code.

4.2.3.3 Knowledge Sharing

It was a common view that the work process was found to be more smoothly and the
communication between had become better due to the adoption of DevOps practices.
Furthermore, development teams seemed to have a better understanding of operational tasks
and the operation team had a better understanding of specific development tasks. However,
there was still a long road to walk regarding creating an understanding of each other’s work,
but as mentioned, most of the project members thought that the understanding of each other’s
work had already become better. One comment from a project member was “since
understanding has become better the confidence of each other has increased and therefore we
trust each other more”. Furthermore, before adopting DevOps there was some finger pointing,
but now the project members collaborated better.

28
A benefit found was shorter response time. Before, it could take several hours before getting
help with an operational related problem, but since adopting DevOps, the response time had
become much shorter. Still, the time zone differences made it more difficult to communicate,
but they were managed by making the most out of the overlapping time. During this period,
meetings were scheduled the first thing of the day in Spain so all project members from both
sites could meet daily. The communication was done through for example email, video-
conferences, and tools called Jira and Zoom.

Another issue that some had experienced in this project was that sometimes the communication
got lost. As a result, knowledge and important information was staying at one site and was not
shared with the other parts of the project. This was a huge problem before but had become better
using DevOps practices, however, it was still an issue which made it difficult to perform
optimally. Cultural differences were as well mentioned to challenge the cross-site
communication. For example, the Spanish developers mentioned that project members from the
other site tended to avoid saying “No” and instead committed to tasks they did not have the
capability to handle.

In this project, the gap was bridged by having not only more frequent communication but also
better communication. Since introducing a type of shared ownership, the project member started
using common practices and needed to collaborate more closely to build a good infrastructure.
As a result, the members understood each other’s work better and could communicate easier.

Generally, the communication was described to be good. The most of the respondents answered
that the communication was "Good", but some describe the communication to offshore project
member as "Neither good nor bad". When describing the trust to project members at other sites,
"Neither good nor bad" or "Good" were chosen by all project members. The project members
from one site generally rated the awareness of the work at the other site lower compared to the
own site. The values varied from "Very bad" to "Good".

The finding regarding the communication goes in line with the communication patterns from
the SNA shown in Figure 4.6 which indicates that the project members were well connected.

29
 Figure 4. 6. SNA Graph for Project 2

The overall accessibility to each role within the project were found high as well. (See Table
4.2.) However, from one interview, the project member wished for more symmetric sites where
some operations engineers were located in Spain as well in order to have close access to
operational expertise.

South-east Asia Developer 4.20

South-east Asia Operation Engineer 4.00
South-east Asia Quality Assurance Engineer 4.52
South-east Asia Quality Assurance Lead 4.53
Spain Quality Assurance Engineer 3.86
Spain Designer 4.00
Spain Developer 4.19
Spain Project Manager 4.40
Spain Software Architect 4.12

Table 4. 2. Role Accessibility Project 2

4.3 Project 3
At the time of this study, the company had been working with a client for two years developing
their mobile app, but the project was about to end. The company was developing a part of a
booking system for a client working with logistic. For the client’s customer to make a booking,
the call went to a call-center which created a solution for the customer. The business system
mainly consisted of different apps for different users of the booking system supporting both
iOS and Android, a backend, one website for the client and one for its customer. Other vendors

30
to the client were responsible for developing the backend, API, the client's website and app.
The company was developing a user application that worked in-between these components and
connected to the client to provide the information of the users that booked.

DevOps practices were adopted at the start of this project, for 2 years ago. The project members
interviewed agreed upon shorter development time has been reached due to use of DevOps
practices. Furthermore, the quality of the software had become better and the number of bugs
had decreased after DevOps practices were adopted. However, a challenge with adopting
DevOps in this project was to convince the developers that it would save time in the long run
because all changes and new tools were overwhelming for them. DevOps practices were found
beneficial in this project since the project was considered a long time project

4.3.1 Offshore Setup

The project members were located in South-east Asia with about 6-7 hour time difference to
the client in Europe. Moreover, the company collaborated with other vendors that were located
in other countries, more specifically Rumania and India. In this project, all project members
from the company were located at the site in South-East Asia (Site A in Figure 4.7) where
mainly development duties were performed. At other sites, where the vendors were located,
development duties were performed and at the site where the customer was located operational
task connected to deploying the software were performed. Adopting DevOps, the gap that
would be tried to bridge was between development at the company and the other vendors, and
operation at the customer. In this study, the gap between development at the company and
operation at the customer were investigated.

Figure 4. 7. Development and Operation distribution across locations in Project 3

4.3.2 DevOps Definition and Goal

In the interviews, DevOps was found defined as a framework help to automate some part of the
software development process as the integration and packaging of the software. Moreover, in
this project, DevOps was not only defined as the use of continuous integration and continuous
delivery. It also considered software architecture, ensure that the application has a good level
of performance and other practices necessary for more reliable deliveries.

One goal of adopting DevOps described, which were mutual for all interviewees, was to reduce
the development time. Moreover, one project member that was interviewed described the goal

31
as well to do more reliable deliveries and improve the quality of the software. A second member
also mentioned the goal of using DevOps to maintain good code standards.

One of the interviewed mentioned that the member's knowledge about DevOps was limited and
did not know much about DevOps definition or practices included.

4.3.3 Bridging the Gap

This section is going to present findings of how Project 3 worked with DevOps and how that
helped to bridge the gap (illustrated in Figure 4.7) between development and operation. The
findings will be highlighted from three different perspectives. The first perspective is roles and
responsibilities which describes how responsibilities connected to development and operation
were assigned among team members. The second perspective describes DevOps practices and
tools project members worked with. The third perspective describes how project members
shared knowledge with each other, or in other words, how the project members communicated
and collaborated.

4.3.3.1 Roles and Responsibility

The Operation Engineer from the company was mainly included at the beginning of the project
and helped with the setup of tools within the development teams. Then there was only operation
support which means help with infrastructure and tools. The project consisted of Developers,
QA and Project Manager, but the Operation Engineer was not there for the whole project. The
project used to have one member visiting the customer, at the beginning of the project it was a
Software Architect but later developers were visiting the customer.

More specifically, the project was using GitHub, where they had a developer branch and a
master branch. In this setup, the developers pushed their work to the developer branch and the
continuous improvement part, the DevOps part, included tools like Jenkins and SonarQube for
continuous code quality. Standard checking was also a part of the work process. Jenkins
packaged the work and automatically uploaded it to a location where the rest of the teams could
download it. Furthermore, one developer from each team (Android and iOS) had greater
knowledge of continuous integration to help with any specific problems that might occur. When
a sprint finished, the software developed were delivered to a QA-team located at another
vendor. In this project, operational tasks connected to deploying the software to production was
managed by the customer site with project members outside the company.

From a perspective of roles and responsibilities connected to DevOps (illustrated in Figure 4.8),
there was no intention of bridging the gap between development and operation.

32
 Figure 4.8 Roles and Responsibilities in Project 3

4.3.3.2 Automated Workflow and DevOps Practices

One benefit of adopting DevOps practices, found in this project, was that everyone did not need
to learn how to do the script, the project member just needed to learn how to run it. Furthermore,
if there were a problem and any person were on vacation the rest of the project group did not
have to wait for this person to come back to solve the problem. This because everyone, within
the project group, could do the work.

Another benefit found was that use of DevOps resulted in less time spent on code review.
Usually, when the development of a feature/bug was done, a code review was conducted where
a developer manually checked some items. Due to DevOps, there were some standard checking
which runs automatically and therefore saves time. This because the code reviewer just needed
to check parts that could not be automatically reviewed

For this project, the DevOps practices mainly used were continuous integration and automated
testing. If tools that were used for DevOps practices were working correctly, it provided
confidence to the project members that everything should be fine and reduced insecurity.
However, sometimes the tools used were not always compatible with what the client requested.
When adopting DevOps practices in this project, the only focus was to improve the
development process and not how to overcome the gap between development and operation.

4.3.3.3 Knowledge sharing

Since the adoption of DevOps, there were not found any changes regarding the collaboration
or communication between development and operation at the company. The communication
within the project group at the company was, unanimously, described as "Very good". The
communication to other vendors and customer was, by all respondents, described as "Neither
good nor bad".

The awareness about tasks performed at other sites, relevant for the company, was described as
"Neither good nor bad" by some member and other described it as "Very bad". The main reason
was that the collaboration was with other companies. The trust of other vendors was neither

33
good nor bad and was found much lower compared to the trust for the customer and the own
project members.

The communication between other vendors was challenging due to the time differences,
however, this was handled by some vendors being “two sprint ahead” the company. As a result,
the components that the company was depending on was already finished when the company
needed them. Furthermore, they used the overlapping time to communicate and have a short
daily meeting. Sometimes they went to work earlier/later to increase the overlapping time. Still,
a problem found with the offshore setup was that information and knowledge were stuck at
different sites. Often the information or knowledge was assumed to be shared, however, that
was not always the case.

The graph in Figure 4.9 illustrates the communication patterns among the project members from
the company which not goes in line with the findings of the interview since it indicates a group
that is not well connected. The graph only illustrates the communication patterns among project
member from the company, it does not illustrate the communication patterns with project
members located at the customer or other vendors.

Figure 4. 9 SNA Graph for Project 3

The overall accessibility to each role within the company’s project group were found high
(see Table 4.3)

South-east Asia Developer 4.34

South-east Asia Operation Engineer 3.25
South-east Asia Project Manager 4.62
South-east Asia Quality Assurance Engineer 4.11
South-east Asia Quality Assurance Lead 4.50

Table 4. 3 Role Accessibility Project 3

34
4.4 Similarities and Differences Between the Projects
In order to get a brief overview of similarities and differences between the projects, following
table were constructed based on findings earlier presented.

Factors Project 1 Project 2 Project 3

DevOps Team No DevOps team No DevOps team No DevOps team

Setup Ops in South-east SA, PM, Dev in All project members

Asia and other in Spain and OPS, Test, in South-east Asia
India QA, Dev in South-
east Asia
Definition DevOps were DevOps blur the line DevOps is a
defined both as a between Dev and framework to help
method fostering Ops and use a shared automate some
better collaboration ownership. Another processes. DevOps is
and as a culture definition was that not only about
aiming for DevOps is a set of continuous
optimization and practices to reunite integration or
automation of two business units. continuous delivery,
processes One member did not it involves software
know what DevOps architecture and
was. other practices
necessary for reliable
deliveries
Goal Reach shorter Bridged gap between Improved quality and
development cycle Dev and Ops, speed reduced development
and guarantee up the work process, cycle, maintaining
everything worked improved good code standards
when deploying it collaboration, spread
knowledge and
ensure everyone
were working toward
the same goal
Worked with For three years For 6 months For two years
DevOps
DevOps practices Continuous Continuous Continuous
integration, integration, integration,
continuous delivery, continuous delivery, automated testing,
automated testing, continuous
automated review, monitoring,
automated backup, automated tests.
Feedback Aiming for
automated
deployment
Performance Time to fix errors Less, problems, less Shorter development
were speeded up, number of bugs, cycles, better quality
bugs were detected sorter lead time to fix and less bugs
before release,

35
 reduced errors, better bugs, quality had not
quality become better
Benefits connected Time differences, Smother process, Not dependent on
to DevOps in smother workflow, better one person, less time
Offshore project reduced manual communication, spend on code
effort, less number of shorter response review, less manual
bugs and shorter time, time work
development cycle differences, shorter
development cycle
Challenges Initial training Time differences, Time differences,
required, time cultural differences, knowledge stuck at
differences, change the way dev different sites, tools
works, Information not always
got lost. compatible with
customers
requirement
Communication Good-Very good Neither good nor bad Very good (own site)
- Good Neither good nor bad
(remote site)
Trust Good-Very god Neither good nor Good (Own site)
bad, or Good Neither good nor bad
(Remote site)
Awareness Most answered Good Variation of values Neither good nor bad
or Very good, Two from very bad to – Very bad
answered Bad good
SNA The SNA graph The SNA graph The SNA graph
indicates that the indicates that some indicates that the
team members were members were well members were not
well connected, connected, however, well connected and
except from the there were some three members were
operation engineer members that were isolated.
who were outside outside of this cluster
this cluster and not as well
connected to this
group.
Accessibility Overall high Overall high Overall high
accessibility, Ops a accessibility accessibility, Ops a
bit lower than others bit lower than others
Table 4. 4. . A table of similarities and differences between the projects

36
5 DISCUSSION
This chapter aims to analyze the collected data presented in previous chapters and connect it
to the theoretical framework presented in Chapter 2. This chapter will begin with analyzing the
findings found when investigating the company’s projects, followed by an analysis of DevOps
characteristic and set up in an offshore environment. The chapter will end with a discussion
aiming to answer the research question

5.1 Analysis of the Investigated Projects

In this section, the similarities and differences between the projects will be presented. First, the
definitions and goals will be presented followed by a discussion regarding how the projects
bridged the gap by adopting DevOps. How the gap was bridged will be discussed from three
different perspectives; roles and responsibilities, automated workflow and DevOps practices,
and knowledge sharing.

5.1.1 DevOps Definition and Goals

A common goal found for use of DevOps was to reach shorter development cycles or speed up
the work process. Furthermore, findings from interviews show that many project members,
from all projects, defined the goal of adopting DevOps as make reliable deliveries in different
aspects. The project members in Project 1 had a more common view of the goal of adopting
DevOps. Meanwhile, it was a more widespread perception in Project 2 were some project
members also mention goals related to bridging the gap between development and operation,
improve collaboration and ensure everyone works towards the same goal. Furthermore, in this
project, it was found that one project member did not know what DevOps was or what they
wanted to achieve by adopting it. One reason for this differences may be that Project 2 adopted
DevOps recently and have not worked with it as long as Project 1. Another explanation may be
that almost all project members in Project 1 are located in the same location making it easier
for them to talk, discuss and be colored of each other’s opinions. In Project 3, the interviewed
members had similar opinion considering the goal covering shorter development times.
However, two other members added that the goal should cover maintaining good code standards
and improve quality. Even though one member mentioned having limited knowledge about
DevOps, the project members had the same view of the goal which may be due to them being
located in the same place, just like for Project 1.

If trying to capture what permeates all the definitions found, it would be that DevOps can be
described as a framework used to bring development and operation closer together, foster better
culture as well as automate and optimize parts of the development process and, make it possible
to do more reliable deliveries.

5.1.2 DevOps Practices

Common DevOps practices used in all three projects were continuous integration and
automated testing. That was all DevOps practices that were used in Project 3. In Project 1 on
the other hand, the use of DevOps practices was larger. In this project, practices like continuous
delivery, automated review, automated backup and feedback tools were used. This may indicate
that they had come further with the adoption of DevOps which can be reasonable since they
have worked with DevOps for 3 years. In Project 2 they had recently begun to automatize the
processes and worked with continuous delivery. Another DevOps practices used in this project
was continuous monitoring and they were aiming for automated deployment. One interpretation

37
is that Project 2 had not come as far as Project 1 with the use of DevOps practices which may
be explained by the fact that Project 1 had worked with DevOps for three years and Project 2
had only worked with DevOps for six months. However, Project 2 seemed to have come further
regarding adoption of DevOps practices compared to Project 3.

5.1.3 Bridging the Gap in the Investigated Projects

This section discusses how the gap between development and operation was bridge in the
different projects. The discussion highlights three perspectives; roles and responsibilities,
workflow and DevOps practices, and knowledge sharing

5.1.3.1 Roles and Responsibilities

All projects were similar in the sense that neither of them had any dedicated DevOps team.
Instead, DevOps was implemented keeping the original structure of the teams. In Project 1
developers, project manager, quality assurance personnel, and software architect were located
at the site in India and one operation engineer was located in South-east Asia. DevOps was
implemented giving mainly the QA-personnel ownership and responsibility of some
operational tasks connected to deployment to production. At the site in South-east Asia, some
operational task connected to the setup of infrastructure and tools were performed. Monitoring
was as well performed by Operation in South-east Asia, but at this site, there was not performed
any development duties. The gap between development and operation was here reduced
introducing cross-functional roles and a shared responsibility. The developers were indirectly
informed how the software behaved in production since operation department monitored the
software which on the other hand was a contributing factor to the gap. In Project 2, the operation
team still had responsibility for deploying to production, however, the operation team,
development lead, and SA closely worked together in order to build a good infrastructure and
monitored the software together. However, Project 2 was aiming for continuous deployment
meaning that development department will take more responsibility for operational duties
connected to deploying to production. The gap was not yet reduced by having development
responsible for operational duties, however, in the near future that was the goal. Since
development lead was included in the monitoring process they had a better understanding of
the behavior of the software in production, which indicates that the gap was reduced.
Furthermore, since operation team, development leads and SA worked close together they may
had avoid some misunderstanding in a later stage that otherwise might had occur.

Both Project 1 and Project 2 implemented DevOps by having a mindset related to a shared
responsibility. Project 1 had focused on a shared responsibility regarding the deployment but
not the monitoring. On the contrary, Project 2 had a shared responsibility regarding the
monitoring but not regarding deploying to production. By having the project members
responsible for some operational tasks, the awareness will increase which might decrease the
risk for bad behavior according to findings in the grey literature (see 2.4.1 Setup of DevOps in
Offshore Project). In turn, this will help to bridge the gap since the task can no longer be thrown
over the wall to another department. In Project 3, there could not be found any intentions to
actually bridge the gap between development and operation through roles and responsibilities.
The operation engineer only worked as a support for the other team members if something was
wrong with the tools or infrastructure, however, none of the project members from the company
was responsible for deploying to production and the DevOps practices were only used out of
the company’s project members at the site in South-east Asia and not by the other sites involved
in this collaboration.

38
Regarding the setup of personnel, Project 2 seemed to have a more challenging offshore setup
than Project 1 since they had a more dispersed project considering the geographical distance,
temporal distance and number of projects members distributed. However, one similarity was
that they both had operation engineers located only at one site. In Project 1, it can easily be
thought that the project had a not that challenging offshore setup since just operation was
located at the other site. However, if the project members did not have this shared responsibility,
it could be difficult for the operation engineer to do the deployment of the software since being
located at another site than developers. As mentioned in section 2.3.1 Global Distributed
Project Setup, in a partially dispersed team the risk for an “Us vs. Them” spirit increases as
well as the risk for conflict and lack of trust. In this project, there might be a risk of the Operation
Engineer being left outside the collocated project group. If the responsibility for deploying to
production is allocated to the operation engineer, the risk for longer deployment time might
increase due to inferior collaboration. Still, this risk was reduced letting the QA be responsible
for deploying to production and operation mainly working as a support and responsible for the
infrastructure. In the second project the operation engineer was not located alone, instead, there
were other project members with different roles located at the same site where it may be easier
to foster better collaboration between development and operation. The distance between
developers in Spain and operation in South-east Asia may result in a greater challenge to foster
a good collaboration due to the distance. Project 3 differ in its offshore setup since all the
company’s project members were located at the same site, but was collaborating with other
vendors to the customer located at remote sites. Since the other vendors were not a part of the
DevOps setup, the DevOps practices only concerned the members within the company’s
project. In that case, the setup reminded more of DevOps in an onshore environment than
DevOps in an offshore environment.

5.1.3.2 Automated Workflow and DevOps Practices

One benefits due to DevOps practices identified in Project 1 and Project 2 were that smoother
work processes were obtained and as one interviewee describe it; the work processes were
streamlined. This due to the automated processes and tools which helped erase a lot of manual
efforts which were another benefit identified in Project 1 and Project 3. In the Project 1, it was
mentioned that anyone in practice could deploy to production which may be a contributing
factor to success. This according to findings in the literature review (see 2.3.1 Global
Distributed Project Setup) where it was found that consistent use of tools was a contributing
factor to success since everyone being familiar with the same tools, environments, and methods.
Furthermore, in this section it was found another contributing factor to successful projects were
to have as few owner changes as possible. By implementing cross-functional roles like in
Project 1 and Project 2 there will be fewer handoffs and fewer owner changes.

As well, it was found in Project 1 and Project 2 that the one responsible for delivering the
product could be more confident in the software being properly developed and tested. The
practices helped increase the trust among members responsible for development duties and
members responsible for operational duties. This is important since it has been found that lack
of trust may result in decreased productivity, quality as well as reduced information exchange
and non-cooperating project group (see 2.3.2 Distributed Project Challenges).

Not only more reliable releases could be done by automating parts of the development process,
communications overheads could as well be reduced. This goes in line with findings from the
literature review (Section 2.4. DevOps in Offshore Projects) where other projects, that had
adopt DevOps in an offshore setup, also found reduced communications overheads. One project
member of Project 1 mentioned that communication across the site more or less only was

39
needed if there was any specific problem with the infrastructure. Moreover, it was found that
automation of development processes helped the members to be more efficient which also goes
in lines with findings in this study.

The DevOps practices adopted in Project 3 only concerned the project members from the
company and not the other members located at the customer or other vendors. As a result, the
DevOps practices adopted only intended to optimize the development process but not the whole
cycle and deployment process. Therefore, this practices was not bridging the gap between
development and operation, especially not since some of the tools used not were compatible
with the customer’s request.

5.1.3.3 Knowledge Sharing

A challenge identified was that the knowledge was stuck in one site or that information gets
lost on the way. This was found both in Project 2 and Project 3 which may be the impact of the
geographical distance since the information discussed in one site easily can be forgotten to be
shared or considered as not that important to share forward. In Project 2 this was a huge problem
before but has become better since adopting DevOps practices. This may be due to the reduced
handoffs and the fact that the understanding of each other’s worked had increased resulting in
it being easier to communicate with each other. Still, temporal distances in an offshore project
make it more difficult to communicate and share knowledge which has shown to decrease the
projects performances. This was a challenge that could be found in all projects as well. The
time differences were mitigated by doing the most out of the overlapping time and by using
daily stand up meeting were all project member attended. In these meetings, the members were
updated on each other's work and the awareness among the member increased. This might have
helped to mitigate one challenge Diel, Marczak and Cruzes mentioned where the geographical
distance results in teams being unaware of each other’s work and team members not taking any
initiatives to communicate since they do not know what to communicate about (2.3.2
Distributed Project Challenges). Furthermore, the last mentioned authors also found that no
frequent communication may result in important information being delayed. However, in
Project 1 and Project 2 the SNA graphs indicated that the team members were well connected
and shared knowledge frequently. Therefore, this risk seemed to be mitigated as well.

The communication was indicated to be very good both in Project 1 and Project 2 if analyzing
findings in the interviews and the result form the SNA graphs. Furthermore, the project
members seemed to have learned how to manage the time differences even though the temporal
distance still was a challenge. In a matter of a fact, the time differences were in both projects
mentioned as a benefit since Operation in South-east Asia could check the status of the system
before the other coming to work and have some time to fix eventual problems so the
development was not delayed that much if anything did not work correctly.

A good communication, or sharing of information, has shown to build trust which in turn results
in improved effectiveness. Since a better understanding requires a better communication, this
goes in line with one finding from Project 2 were the respondent claimed that the understanding
had become better and as a result, the members trusted each other more. As well, in all three
projects, the roles were rated very accessible. According to findings in the literature review
(2.3.3 Knowledge in Offshore Project) the better availability members have to personal
knowledge, the better productivity and efficiency of the development team. In this interviews,
all projects were claimed to perform better which is strengthened by the fact that they had good
access to personal knowledge.

40
However, in Project 3, the SNA graph indicated that the team members were not that well
connected. However, this does not go in line with the findings in the interviews were the team
members described their communication to each other (within the same site) as very good
meanwhile describing the communication to offshore vendors as neither good nor bad. At the
same time, the awareness was described as neither good nor bad which may indicate that the
team members did no communicate that often, however, since they are located at the same site
the SNA-graph were expected to show more well-connected team members. One reason for this
difference can be that the surveys were not answered properly were the project members
perhaps did not understand the meaning of product knowledge. Another reason for this
differences may be that the project was about to end which may result in less communication
and that that the project members refer to the current situation. Another explanation can be that
the interviewees may had misinterpreted the question. Either way, the result from this project
can be used, however, it should be handled carefully since the results from interviews and the
SNA indicates different results.

5.1.4 Performance
All these projects had in common that the time to fix bugs were sped up since adopting DevOps
and fewer bugs were released into production since they were detected beforehand.
Furthermore, in all project, it was found that the development cycle had been reduced. For
Project 1 and Project 3 quality had become better, however, in Project 2 they could not see any
change in the quality yet. This may depend on the fact that they had not used DevOps practices
for more than 6 months which one interviewee agreed upon since the interviewee thought that
the quality would increase in the future.

5.1.5 Most Successful Setup

Project 1 was the project that was found as the project that had adopted most DevOps practices
and made the most progress regarding adoption of DevOps. It was also the project that seemed
to have the best communication within the project group and had good performance. It was not
possible to decide which project that performed the best, however, if looking at the graphs as
proxies it indicates that Project 1had the best performance. However, these project members
were mostly located at the same site except one member which indicated that they more easily
could manage the offshore challenges. Project 2 had a more challenging offshore model, still,
the findings of this report indicated that the project performed very well and the members were
well connected. In the interviews, it was found that communication and performance had
become better since the adoption of DevOps even though they had not come as far with the use
of DevOps practices as Project 1. In Project 3 it could not be found any initiatives taken to
actually reduce the gap between operation and development. As a matter of a fact, the DevOps
practices were only adopted to improve the development process alone. Therefore, this project
might not be a DevOps project, instead, it is a project just working with agile methods.

To summarize, Project 3 could not be considered a DevOps project in this study, and Project 1
seemed to be the project that was most successful. However, Project 2 might have overcome
greater challenges connected to cultural, temporal and geographical distance. Furthermore,
Project 2 had only worked with DevOps practices for 6 months. It might not be possible to tell
which project that was most successful, but it is possible to conclude that both Project 1 and
Project 2 had successfully adopted DevOps, bridging the gap and obtained benefit from it.

41
5.2 DevOps Characteristics
DevOps is a framework which includes several practices that are applied during the
development phase until the software is released to production. However, some DevOps
practices are involved in the planning phase as well, but the focus may be on the later stage of
the development cycle. When DevOps is introduced in the development cycle is illustrated in
Figure 5.2.

Figure 5. 1 DevOps inclusion in development cycle

There are several definitions of DevOps but based on the findings in the projects and in the
literature review, the definition proposed by Riungu-Kalliosaari et.al (2.2.1. DevOps Definition)
seemed to cover the most common aspects. However, no definition found provided a way of
how to tell whether a project is DevOps or not, or in other words, what the minimum
requirements are to be called a DevOps project. Therefore, after going through findings in the
interviews and compared to the theories and related work in chapter 2, a proposal for a
framework was conducted to be able to decide “how DevOps” a project is.

In the studied project the most common practices found were continuous integration and
automated test. Furthermore, Project 1 and Project 2 used continuous delivery and some type
of monitoring of the system or used any other feedback practices. The practices that were found
most common, in the theories and related work presented in chapter 2, were continuous
integration, continuous delivery, automated testing, continuous deployment and continuous
monitoring. Other practices were mentioned as well, for example, tools related to quality
assurance, continuous planning, and process standardizations, but not in a large extension. It is
not clear exactly which practices that count as DevOps practices and some DevOps practices
may not be unique for DevOps since it can be considered an agile practice as well.

Based on findings in this study the minimum practices that need to be adopted for a project to
be DevOps are continuous integration, continuous delivery, automated testing and use of any
monitoring or feedback tools. Continuous deployment is a tool often mentioned, however, it
may not be suitable for all projects to use this practice, and therefore it is not considered as a
requirement for DevOps projects. Being a DevOps project is not just about using the right tools,
it is also important to have the right goals and expected outcome. DevOps practices should be
adopted in order to achieve shorter development cycles, achieve better quality and aim to reduce
the gap between development and operation by foster better communication and collaboration
within the project group.

This factors should be considered the minimum requirements to be a DevOps project. If other
practices are added in order to help achieve some of the outcomes presented, it can be seen as
the project is moving towards being “more DevOps”. Figure 5.1. Describes this framework.

42
 Figure 5. 2 Scale to decide how DevOps a project is

In order to achieve basic DevOps in a project following requirements must be fulfilled:

DevOps practices:
 Continuous integration
 Continuous delivery
 Automated testing
 Monitoring/Feedback tools
Process related outcome
 Shorter development cycles
People related outcome
 Reduced gap between development and operation
 Better collaboration between development and operation
Product related outcome
 Better quality of the software
 Product is satisfying customer requirements (Less bugs and shorter time
to fix them)

If more DevOps practices are added to this, the project will go towards advanced DevOps.
However, this is just a framework based on the findings of this study and needs to be further
investigated.

5.3 Distribution of DevOps in Offshore Environment

After studying the setup in the projects and connected the findings to the other findings in
chapter 2, it was found that four different ways to distribute development and operational duties
in offshore projects. These four possibilities are described in Figure 5.3. The first setup has
both development duties and operational duties at several sites. The second setup has
development duties at one site and operational duties at another. Development duties and
operational duties are not located at the same site. The third setup has both development duties
and operational duties at one site but have duties that are not connected to development or
operation at another, for example, account management. The fourth setup has duties connected
to development and operation at one site and at the other, there are duties connected to either
development or operation. However, this are the possible setups for projects with two sites, if
the number of sites increased, so do the distribution possibilities of duties connected to
development and operation.

43
 Figure 5. 3. Different distribution possibilities of Development duties and Operational
duties in offshore setup

In the first setup, the distribution of development and operation were according to setup 2,
however, after adopting DevOps framework and a shared responsibility, the distribution of
development duties and operational duties may instead be according to setup 4. In this case,
operational duties were performed at the site in South-east Asia and duties connected to both
development and operation were performed at the site in India. Project 2 originally had a setup
reminded of setup 4 with development duties at the site in Spain and development and
operational duties at the site in South-east Asia. Since adopting DevOps practices and shared
responsibility, the setup now reminds more of setup 1 were development and operational duties
were performed at both sites. The third project had a different setup since several sites were
involved. However, DevOps practices were only affecting one site.

All setup, except setup 3, can be considered offshore setups were development and operation
are distributed so the gap between them may be affected by temporal, geographical and cultural
distance. Setup 3, on the other hand, has development and operation distributed similarly to
DevOps in an onshore setup. Therefore, setup 3 is not considered a possible setup to implement
DevOps so it is affected by temporal, geographical and cultural distance due to offshore
environment.

It was identified different ways of managing the roles in the project when adopting DevOps.
One way, which was used in the Project 1 and Project 2, was to keep original roles and blur the
line between the roles. In other words, cross-functional roles where established by letting
development department take some responsibility for operational duties. This way of working
was also found in the literature review (2.4.1 Setup of DevOps in Offshore Projects). Another
way identified from the literature review was to introduce a role called DevOps engineer to
facilitate the processes of DevOps. (2.2.1. DevOps Definition). However, no project
investigated used DevOps engineers and neither did they use a DevOps team. From the
literature review it was found different opinions regarding what a DevOps team actually is
44
(2.4.1 Setup of DevOps in Offshore Projects). Some claims that a DevOps team should have
cross-functional responsibilities connected to both development and operation. The DevOps
team can also be described as a link between development and operation, responsible for
deployment. However, some claims that a DevOps team more or less is the same as the work
of operation teams were the team is responsible for providing a toolchain, and coach as well as
support other teams way of working. If having this shared ownership with cross-functional roles
and no dedicated DevOps team, one problem may be to decide who is actually responsible for
what. For Project 1 and Project 2 it worked well however, this is quite small projects where it
may be easier to coordinate all project members. If having a large-scale project, it may be more
difficult to coordinate the project members and decide who should be responsible for what. In
this case, a DevOps team may be suitable since it will make it more clear who is actually
responsible for what. Still, some claims that putting a team between development and operation
will not help project member take responsibility for their action and they will not be aware of
what is required (2.4.1 Setup of DevOps in Offshore Projects).

The teams can either be dispersed or collocated (2.3.1 Global Distributed Project Setup). If
having a collocated DevOps team, it may be difficult for project members at other sites to access
the DevOps team making it difficult to work optimally. If having the DevOps team dispersed,
it can, on the other hand, be difficult for the DevOps team to collaborate and work closely
together. If adopting DevOps by not using any DevOps team and letting the roles within the
project groups be blurred, it may be easier to access the help needed to solve a problem since
the knowledge is spread over the project members and not located to one person or team.
However, the problem that might occur with this setup is who is responsible for what and who
is responsible for the work between two tasks.

5.4 Adoption of DevOps in Offshore Projects

According to the findings of this study, there are four possible distribution possibilities for
development and operation in offshore projects, but one setup could not be considered a
DevOps setup affected by the offshore environment. These setups are described in section 5.3.
Distribution of DevOps in Offshore Environment and visualized in Figure 5.3. Furthermore, it
was found that roles could either be cross-functional or DevOps team could be used which
either could be collocated or dispersed. As well, a DevOps project characterizes by automation
of development processes. More specifically, DevOps projects are characterized of practices
like continuous integration, continuous delivery, automated test and use of feedback/monitoring
tools. Moreover, the outcome by using DevOps should be to reduce development cycles, reduce
the gap between development and operation, foster better collaboration between development
and operation, and increase the quality of the software. According to these findings, both
Project 1 and Project 2 can be considered project working with DevOps framework affected by
the offshore setup. Project 3 could not be considered a DevOps project since the expected
outcome was only to gain better quality and develop the product faster. Furthermore, the only
practices used were continuous integration and automated test. The project could instead be
seen as an offshore project working with agile practices.

Mainly three perspectives of how DevOps help reduce the gap between development and
operation were found. The first finding was that cross-functional roles and a shared ownership
help reduce handoffs which have shown as a contributing factor to success in an offshore
project. This goes in line with related work where DevOps has been adopted in offshore projects
(2.4 DevOps in Offshore Project). Reduced handoffs reduce the risk for important information
get stuck at one site. However, a risk with this setup is that it may be unclear who is responsible

45
for what. However, this can be mitigated by having a good communication and collaboration
across the teams. Despite, a shared responsibility required a changed mindset within the
projects. In interviews, it was found that changing the mindset of project members were a
challenge that required time and a lot of work. Having an offshore setup with either collocated
or dispersed team may make it more difficult to create a common goal and culture.

A second fining to bridge the gap was connected to automation and DevOps practices. Here it
was found that the automation of development process help reduce the gap between
development and operation since the one responsible for deploying the software to production
can be more confident in the software being properly developed and tested. Furthermore, by
using automated practices and common tools or environments, communication overheads can
be reduced. That communications overheads can be reduced goes in line with findings presented
by Stillwell and Coutinho (2.4 DevOps in Offshore Project) Also, the automation of
development processes helps to achieve shorter development cycle, resulting in more frequent
feedback from the customer. If this feedback can be obtained faster, the project can easier
respond to changes and if the feedback reaches the development department directly some
misunderstanding that might occur in later stages of the development process can be reduced.

The third finding of bridging the gap between development and operation were due to
knowledge sharing. If project member shares knowledge more frequent they can be considered
more well connected and perform better. Better knowledge sharing were obtained using stand
up meeting and make the most out of the overlapping time, however, with a shared
responsibility, the understanding and awareness of each other’s work increased resulting in the
gap being bridged.

Findings of this study indicated that adopting DevOps in offshore projects can help decrease
the gap between development and operation, however, the offshore setup will make it more
difficult.

46
6 CONCLUSIONS
This chapter aims to conclude the study and answer the research question. The chapter will
begin with emphasis central findings and it will end with a short description of this study’s
contribution.

6.1 Conclusion
In this study, it was investigated how DevOps can be adopted in offshore projects in order to
decrease the gap between development and operation. The result of this study emerged from
investigating three offshore projects working with DevOps and connect the findings to related
work. This study aimed to answer how DevOps bridge the gap between development and
operation in offshore projects. In order to answer this research question, three sub-questions
were established.

The first sub-question aimed to investigate what actually characterize a DevOps project. In this
study, a proposal on a DevOps framework was established. Here a basic DevOps project was
using practices like continuous integration, continuous delivery, automated test and practices
for monitoring or feedback. In addition, for a basic DevOps project, the outcome should be to
reach shorter development cycle, better quality of the software and reduced gap between
development and operation as well as better collaboration. If more practices were adopted for
reaching this outcome, the project can be seen as a project with a more advanced use of DevOps
framework. However, this is just a suggestion and needs to be further investigated. The second
sub-question regarding how DevOps can be distributed across locations in offshore projects
were answered as well. Four different suggestions of how development duties and operational
duties can be distributed across locations were presented. This distribution of development and
operation can be structured either having a sharp line between the role’s responsibilities, or
cross-functional roles can be used. It was also found that DevOps team can be used when
adopting DevOps in an offshore project where the team can either be collocated or dispersed.
The third sub-question aimed at answering which of the three projects were found most
successful in order to see if any setup of DevOps in an offshore environment were found more
beneficial. It was found that one project could not count as a DevOps project, regarding the
other two, it was difficult to determine which was most successful. The first project had come
further with the adoption of DevOps and seemed to be better connected, however, this project
did not have as challenging offshore setup as Project 2 which as well had only worked with
DevOps practices for six months.

To answer the research question, the gap between development and operation can be reduced
in an offshore project. One way to bridge the gap is by using cross-functional roles or DevOps
team which mitigate the risk for important information being stuck at one site. A second way
to decrease the gap is by aiming for an automated workflow and use of common tools which
help reduce communication overheads. This goes in line with findings presented by Stillwell
and Coutinho who also found that communication overheads can be reduced adopting DevOps
in offshore project. A third way to decrease the gap is to improve the communication and
knowledge sharing among the project members.

As a final conclusion, the results of this study indicates that DevOps can be adopted in an
offshore project in order to decrease the gap between development and operation. These

47
findings goes in line with earlier findings where DevOps has been adopted in offshore projects
(2.4 DevOps in Offshore Project). However, an offshore strategy will make it more difficult to
adopt DevOps and it may not be as effective as using a nearshore or onshore strategy. Still,
DevOps can help reduce the gap and shorter development cycles can be obtained by using
DevOps meanwhile keeping an offshore strategy. These findings need to be further defined and
generally tested in for example a large-scale project.

6.2 Contribution of this Study

Before this study a gap in the literature was identified where it could not be found much
information about how DevOps can be adopted in offshore projects. DevOps is a popular topic
to investigate since it bridges the gap between development and operation which makes it
possible for software projects to decrease the development cycle and become more competitive
in the market since they quickly can respond to changes. As the focus has been on definition
and practices of DevOps, there has not been much research on whether DevOps actually can be
useful in global projects were factors like cultural distance, temporal distance, and geographical
distance, traditionally pulls the project members apart, which inhibit the communication and
collaboration within the project. Many companies want to stay global in order to obtain some
benefits as get hold of specialized talent, reduce development cost, gain globalized presence
and close customer proximity. The gap in the literature is arisen due to lack of research about
whether it is possible for a software organization to use DevOps framework in an offshore
project. This in order to decrease the gap between development and operation so shorter
development cycle can be obtained, meanwhile keeping an offshore strategy. Since there is not
much research in this area, this study aimed to increase the understanding of this subject for
future research. That is the contribution of this study.

48
7 RECOMMENDATIONS AND FUTURE WORK
This chapter present suggestion on future work based on the findings of this study.

7.1 Suggestions of Future Work

One suggestion of future work is to investigate and verify minimum factors for a project to be
considered a DevOps project based on the framework that was presented in this study. In
other words, how to decide whether an organization is DevOps or not.
Another suggestion of future work is to investigate the findings of this research further. The
findings of this research need to be tested in projects outside this company, in large-scale
projects, in projects with dedicated DevOps-team, and within other projects with different
characteristics. This in order to provide general validity to the findings.
One more suggestion is to investigate how DevOps can be adopted in an offshore project with
a focus on different roles and responsibilities. Is a DevOps team preferable or not, and if it is,
when should a DevOps team be used. Furthermore, if having cross-functional roles with
shared responsibility, will it work in small-scale projects as well as large-scale project and
who is responsible for what.

49
AFTERWORDS
The topic of this study is new and underdeveloped, as a result, the understanding comes
gradually and takes time. Using an explorative research method, it was possible to discover new
things during the study process and change direction when finding something new. This flexible
approach was helpful since the topic is new, however, due to the short timeframe, it was difficult
to do some major changes. If having more time available, more interviews would have been
conducted in order complement current findings. Furthermore, the scope of this thesis was very
wide in order to obtain an increased understanding of the subject and due to the timeframe, it
was not possible to do in-depth investigations.

REFERENCES

[1] L. Riungu-Kalliosaari, S. Mäkinen, L. E. Lwakatare, J. Tiihonen and T. Männistö,

"Study, DevOps Adoption Benefits and Challenges in Practice: A Case Study," in
Abrahamsson P., Jedlitschka A., Nguyen Duc A., Felderer M., Amasaki S., Mikkonen T.
(eds) Product-Focused Software Process Improvement, Trondheim, Springer Cham,
2016, pp. 590-597.
[2] P. G. Smith and D. G. Reinertsen, "Shortening the product developement cycle,"
Research Technology Management, vol. 35, no. 3, pp. 44-49, 1992.
[3] L. Chen, "Continuous Delivery: Huge Benefits, but Challenges Too," IEEE Software,
vol. 32, no. 2, pp. 50-54, 2015.
[4] E. Carmel, Global Software Teams - collaborating across borders and time zones, 1 ed.,
Upper Saddle River: Prentice Hall P T R, 1999.
[5] V. Yadav, "A Flexible Management Approach for Globally Distributed Software
Projects," Global Journal of Flexible Systems Management, vol. 17, no. 1, pp. 29-40,
2016.
[6] D. Smite, "Distributed Project Management: Ten Misconceptions That Might Kill Your
Distributed," in Software Project Management in a Changing World, Berlin,
Heidelberg, Springer, 2014, pp. 301-320.
[7] M. Hütterman, DevOps for Developers, 1 ed., New York: Apress, 2012.
[8] A. Bartusevičs, A. Lesovskis and V. Ponomarenko, "Model-Driven Approach and
Library of Reusable Source Code for Automation of IT Operations," Applied Computer
Systems, vol. 21, no. 1, pp. 5-12, 2017.
[9] I. Sommerville, Software engineering, Boston: Pearson, 2011.
[10] K. Edström and A. Kolmos, "PBL and CDIO: complementary models for engineering
education development," European Journal of Engineering Education, vol. 39, no. 5,
pp. 539-555, 2014.
[11] L. Bass, I. Weber and L. Zhu, DevOps: A Software Architect's Perspective, New Jersey:
Pearson Education, 2015.
[12] G. Kim, J. Humble, P. Debois and J. Willis, Imagine a World Where Dev and Ops
Become DevOps - How to Create World-Class Agility, Reliability, and Security in
Technology Organizations, IT Revolution Press, 2016.

50
[13] E. Diel, S. Marczak and C. D. S., "Communication Challenges and Strategies in
Distributed DevOps," in IEEE 11th International Conference on Global Software
Engineering, Irvine, CA, USA, 2016.
[14] F. Erich, C. Amrit and M. Daneva, "A qualitative study of DevOps usage in practice,"
Journal of Software: Evolution and Process, vol. 29, no. 6, pp. 1-20, 2017.
[15] H. Holmström, B. Fitzgerald, P. J. Ågerfalk and E. Ó. Conchúir, "Agile Practices
Reduce Distance in Global Software," Information Systems Management, vol. 23, no. 3,
pp. 7-18, 2006.
[16] A. Danait, "Agile Offshore Techniques - A Case Study," in Proceedings of the Agile
Development Conference , Denver, 2005.
[17] R. J. Adams, P. Smart and A. S. Huff, "Shades of Grey: Guidelines for Working with
the Grey Literature in Systematic Reviews for Management and Organizational
Studies," International Journal of Management Reviews, vol. 19, no. 4, pp. 432 - 454,
2017.
[18] E. Tom, A. Aurum and R. Vidgen, "An exploration of technical debt," The Journal of
Systems and Software, vol. 86, no. 6, pp. 1498-1516, 2013.
[19] B. Kitchenham, R. Pretorius, D. Budgen, O. Pearl Brereton, M. Turner, M. Niazi and S.
Linkman, "Systematic literature reviews in software engineering – A tertiary study,"
Information and Software Technology, vol. 52, no. 8, pp. 792-805, 2010.
[20] M. Soni, DevOps Bootcamp, Birmingham : Packt Publishing, 2017.
[21] L. Banica, M. Radulescu, R. Doina and A. Hagiu, "Is DevOps another Project
Management Methodology?," Informatica Economică, vol. 21, no. 3, pp. 39-51, 2017.
[22] R. Jabbari, N. bin Ali and K. Petersen, What is DevOps? A Systematic Mapping Study
on Definitions and Practices, Edinburgh: XP ’16 Workshops, 2016.
[23] A. Q. Gill, A. Loumish, I. Riyat and S. Han, "DevOps for information management
systems," Vine Journal of Information and Knowledge Management Systems, vol. 48,
no. 1, pp. 122-139, 2018.
[24] C. Eber, "DevOps," IEEE Software, vol. 33, no. 3, pp. 94-100, 2016.
[25] A. Balalaie and A. Heydarnoori, "Microservices Architecture Enables DevOps -
Migration to a Cloud-Native," IEEE Software, vol. 33, no. 3, pp. 42-52, 2016.
[26] M. Callanan and A. Spillane, "DevOps Making it Easy to Do the Right Thing," IEEE
Software, vol. 33, no. 3, pp. 53-59, 2016.
[27] D. Spinellis, "Being a DevOps Developer," IEEE Software, vol. 33, no. 3, pp. 4-5, 2016.
[28] L. Zhu, L. Bass and G. Champlin, "DevOps and Its Practices," IEEE Software, vol. 33,
no. 3, pp. 32-34, 2016.
[29] D. Šmite, C. Wohlin, Z. Galviņa and R. Prikladnicki, "An empirically based
terminology and taxonomy for global software engineering," Empirical Software
Engineering, vol. 19, no. 1, pp. 105-153, 2014.
[30] D. Šmite, M. Kuhrmann and P. Keil, "Virtual Teams: Guest Editor’s Introduction,"
IEEE Software, vol. 31, no. 6, pp. 41-46, 2014.
[31] L. Plotnick, S. R. Hiltz and R. Privman, "Ingroup Dynamics and Perceived
Effectiveness of Partially Distributed Teams," IEEE Transactions on Professional
Communication, vol. 59, no. 3, pp. 203-229, 2016.
[32] E. Carmel and R. Agarwal, "Tactical Approaches for Alleviating Distance in Global
Software Development," IEEE Software, vol. 18, no. 2, pp. 22-29, 2001.

51
[33] R. Battin, R. Crocker, J. Kreidler and K. Subramanian, "Leveraging Resources in Global
Software Development," IEEE Software, vol. 18, no. 2, pp. 70-77, 2011.
[34] K. Swigger, F. Alpaslan, R. Brazile and M. Monticino, "Effects of culture on computer-
supported international collaborations," Computer Science and Engineering, vol. 60, no.
3, pp. 365-380, 2003.
[35] C. Bird, N. Nagappan, P. Devanbu, H. Gall and B. Murphy, "Does Distributed
Development Affect Software Qulaity? An Empirical Case Study of Windows Vista," in
IEEE, Vancouver, 2009.
[36] A. Piri, T. Niinimäki and C. Lassenius, "Fear and distrust in global software engineering
projects," Journal of Software Maintenance and Evolution: Research and Practice, vol.
24, no. 2, pp. 185-205, 2012.
[37] A. Aurum, R. Jeffery, C. Wholin and M. Handzic, Managing Software Engineering
Knowledge, Berlin Heidelberg: Springer Berlag, 2003.
[38] J. Kotlarsky, "Social ties, knowledge sharing and successful collaboration in globally
distributed system development projects," European journal of information systems,
vol. 14, no. 1, pp. 37-48, 2005.
[39] C. Harper-Ashton, "Will DevOps Kill the offshore Model?," Salmon, 24 May 2016.
[Online]. Available: https://www.salmon.com/en/what-we-think/blogs/will-devops-kill-
offshore-model/. [Accessed 08 02 2018].
[40] P. Bendor-Samuel, "Can devops be delivered in a distributed labor model?," CIO, 19
October 2017. [Online]. Available: https://www.cio.com/article/3234389/devops/can-
devops-be-delivered-in-a-distributed-labor-model.html. [Accessed 5 02 2018].
[41] L. Gordon, "How to leverage offshore developers for devops," InfoWorld, 1 May 2018.
[Online]. Available: https://www.infoworld.com/article/3269487/devops/how-to-
leverage-offshore-developers-for-devops.html. [Accessed 5 May 2018].
[42] T. Bosch, "Reduce your costs with distributed DevOps," Salmon, 06 June 2017.
[Online]. Available: https://www.salmon.com/en/what-we-think/blogs/reduce-your-
costs-distributed-devops/. [Accessed 13 02 2018].
[43] J. Betteley, "On DevOps in Distributed Teams...," devopsnet, 02 December 2016.
[Online]. Available: https://devopsnet.com/2015/11/09/on-devops-in-distributed-teams/.
[Accessed 08 February 2018].
[44] forgeahead, "How Distributed Product Teams Should Communicate in the DevOps and
Agile Age," forgeahead, 24 January 2018. [Online]. Available:
https://www.forgeahead.io/blogs/how-distributed-product-teams-should-communicate-
in-the-devops-and-agile-age/. [Accessed 15 February 2018].
[45] M. Stillwell and J. G. F. Coutinho, "A DevOps Approach to Integration of Software,"
Proceedings of the 1st International Workshop on Quality-Aware DevOps., pp. 1-6,
2015.
[46] M. Fazal-Baqaie, B. Güldali and S. Oberthür, "Towards DevOps in Multi-provider
Projects," 2nd Workshop on Continuous Software Engineering, pp. 18-21, 2017.
[47] Bendor-Samuel and Peter, "How DevOps changes the delivery of IT functions," CIO, 13
June 2017. [Online]. Available: https://www.cio.com/article/3200824/it-industry/how-
devops-changes-the-delivery-of-it-functions.html. [Accessed 05 02 2018].
[48] A. Valdes, "6 Reasons your DevOps team in same time zone is more productive –
Nearshore DevOps," ClickIT, 12 July 2017. [Online]. Available:
https://www.clickittech.com/devops/nearshore-devops-outsourcing/. [Accessed 10 02
2018].

52
[49] P. Smith, "2iWill embracing Agile put an end to Offshore Outsourcing?," 2i, 17 October
2016. [Online]. Available: https://2itesting.com/media/blog/agile-and-offshore-
outsourcing/. [Accessed 10 February 2018].
[50] J. Bird, "DevOps is Killing Maintenance. Let's Celebrate.," DZone, 23 May 2015.
[Online]. Available: https://dzone.com/articles/devops-killing-maintenance. [Accessed 8
February 2018].
[51] J. Humble, "There's No Such Thing as a "Devops Team"," Continious Delivery, 19
October 2012. [Online]. Available: https://continuousdelivery.com/2012/10/theres-no-
such-thing-as-a-devops-team/. [Accessed 14 03 2018].
[52] B. Pariseau, "Distributed DevOps puts IT communication strategies to the test,"
TechTarget, 17 November 2016. [Online]. Available:
https://searchitoperations.techtarget.com/news/450403156/Distributed-DevOps-puts-IT-
communication-strategies-to-the-test. [Accessed 6 February 2018].
[53] P. Ghauri and K. Grönhaug, Research Methods in Business Studies, vol. 4, Edinburgh
Gate: Pearson Education, 2010.
[54] M. Q. Patton, How to Use Qualitative Methods in Evaluation, California: SAGE
Publications, 1987.
[55] P. Baxter and S. Jack, "Qualitative Case Study Methodology: Study Design and
Implementation for Novice Resaerchers," The Qualitative Report, vol. 13, no. 4, pp.
544-559, 2008.
[56] J. Alvehus, Skriva uppsats med kvalitativ metod: En handbok, Stockholm: Liber AB,
2013.
[57] G. Robins, Doing Social Network Research - Network-based Research Design for
Social Scientist, 1 ed., London: SAGE Publications Ltd, 2015.
[58] S. P. Borgatti, M. G. Everett and J. C. Johnson, Analyzing Social Networks, London:
SAGE Publications , 2013.
[59] D. Šmite, Moe, N. Brede, A. Šablis and C. Wohlin, "Software teams and their
knowledge network in large-scale software development," Information and Software
Technology, vol. 86, no. JUN, pp. 71-86, 2017.
[60] C. Ebert and J. D. Man, "Effectively utilizing project, product and process knowledge,"
Information and Software Technology, vol. 50, no. 6, pp. 579 - 594, 2008.
[61] B. o. Q. R. 3e, Corbin, Juliet; Strauss, Anshelm, California: SAGE Publications, Inc,
2008.

53
APPENDIX A: INTERVIEW– PROJECT MANAGER

About the person:

 Name: Site:
 Which is your role in the company/project?
 How many years of experience do you have of working within this company?
 How many years of experience do you have of working within this project?
 Have you always worked at this site?

Project information/setup:
 Characteristic of the product to develop:
o Size, complexity etc.
 Which sites are involved?
 Which are the roles in each project/team?
 How many people are in each team?
 How are the teams dispersed?
o Mix of Development and Operation at each site?
o Development at one site and operation at other?
o Management from one site and Development/Operation at another?
 Do you have personnel with only development task respectively operation tasks or is
one person responsible for development tasks as well as operation tasks?
 When did you adopt DevOps?

DevOps
 How do you define DevOps?
 What is the goal with adopting DevOps in your project? What do you want to obtain
by adopting DevOps?
o Do you feel like your goal with adopting DevOps has been or will be reached?
 How do you work with DevOps within this project? Can you describe the workflow?
 Do you use any specific practices that you would classify as typical DevOps practices?
o For example continuous planning, continuous monitoring, continuous
integration, automated testing, automated deployment
 What are the benefits you feel this project have obtained from adopting DevOps?
 What are the challenges you have identified working with DevOps?
 What are the main differences in your project workflow from not working with
DevOps to adopt DevOps?
 Do you notice any differences regarding the collaboration between development and
operation after adopting DevOps?
o If yes; which differences,
o How does DevOps help decreasing the gap and foster collaboration between
development and operation?
o Do you think that the collaboration have become better due to adoption of
DevOps?

54
  Do you notice any differences regarding the collaboration between other work roles
within the project since you adopted DevOps?
 Do you notice any differences regarding the communication between other work roles
within the project since you adopted DevOps?
o More specifically, have it been better between operation and development?
o On a scale 1-5 (5 very good) how good would you say the communication is
within the team?
o On a scale 1-5 (5 very good) how good would you say the communication is
among the teams at the same site?
o On a scale 1-5 (5 very good) how good would you say the communication is
among the teams from different sites?
 Do you feel like you have better understanding for your co-workers at
development/operation?
 Do you feel like there are less bugs or/and problem?
o Has the lead time and the number of bug reports changed after the
implementation of the DevOps strategy?
 Do you feel like shorter development cycle have been or will be achieved?
 How do you think your quality assurance have been affected by adoption of DevOps?
 What could, in your opinion, be improved in the setup or the DevOps implementation
strategy to achieve better performance?

Offshore
 What are the perceived benefits of offshoring?
 Which challenges imposed by offshoring have been faced?
 How do you within the team mange time zone differences when collaborating with
other teams?
 Are you aware of what the other teams are doing?
 On a scale 1- 5 (5 is the highest) how much trust would you say you have to the team
at the different sites?
 On a scale 1- 5 (5 is the highest) how aware are of what the other teams from different
sites are doing?

55
APPENDIX B: INTERVIEW– PROJECT MEMBER

About the person:

 Name: Site:
 Which is your role in the company/project?
 How many years of experience do you have of working within this company?
 How many years of experience do you have of working within this project?
 Have you always worked at this site?
DevOps
 Are you aware that this project have a DevOps mindset?
 How do you define DevOps?
 What is the goal with adopting DevOps in your project? What do you want to obtain
by adopting DevOps?
o Do you feel like your goal with adopting DevOps has been or will be reached?
 How do you work with DevOps within this project? Can you describe the workflow?
 Do you use any specific practices that you would classify as typical DevOps practices?
o For example continuous planning, continuous monitoring, continuous
integration, automated testing, automated deployment
 What are the benefits you feel this project have obtained from adopting DevOps?
 What are the challenges you have identified working with DevOps?
 What are the main differences in your project workflow from not working with
DevOps to adopt DevOps?
 Do you notice any differences regarding the collaboration between development and
operation after adopting DevOps?
o If yes; which differences,
o How does DevOps help decreasing the gap and foster collaboration between
development and operation?
o Do you think that the collaboration have become better due to adoption of
DevOps?
 Do you notice any differences regarding the collaboration between other work roles
within the project since you adopted DevOps?
 Do you notice any differences regarding the communication between other work roles
within the project since you adopted DevOps?
o More specifically, have it been better between operation and development?
o On a scale 1-5 (5 very good) how good would you say the communication is
within the team?
o On a scale 1-5 (5 very good) how good would you say the communication is
among the teams at the same site?
o On a scale 1-5 (5 very good) how good would you say the communication is
among the teams from different sites?
 Do you feel like you have better understanding for your co-workers at
development/operation?
 Do you feel like there are less bugs or/and problem?

56
 o Has the lead time and the number of bug reports changed after the
implementation of the DevOps strategy?
 Do you feel like shorter development cycle have been or will be achieved?
 How do you think your quality assurance have been affected by adoption of DevOps?
 What could, in your opinion, be improved in the setup or the DevOps implementation
strategy to achieve better performance?

Offshore
 What are the perceived benefits of offshoring?
 Which challenges imposed by offshoring have been faced?
 How do you within the team mange time zone differences when collaborating with
other teams?
 Are you aware of what the other teams are doing?
 On a scale 1- 5 (5 is very good) how much trust would you say you have to the team at
the different sites?
 On a scale 1- 5 (5 is very good) how aware are of what the other teams from different
sites are doing?

57
APPEND
IXC
:SURVEYFORSNA

1
. Pl
eas
ese
lec
tyou
rnam
einth
eli
st

 N
ame1
 N
ame2
 am
N e3
 …
 N
amen

2
.Atwh
ichs
itedoy
ouwo
rk?

 Spa
in
 South
-ea
stA
sia
 Ind
ia
 O
ther

3
. Howfr
equentdoyout
rans
ferr
elevan
tprodu
ctknowledge
,toth
ispe
rson
,ino
rde
rto
he
lpth
erec
eive
rso
lveata
skspeci
ficfo
rit
sro
le?(Igno
r eyou
rownname)

N
eve
r Very R
are
ly O
cca
sion
ally F
requ
ent
ly Ve
ry
R
arely F
requen
tly
N
ame1 o o o o o o
N
ame2 o o o o o o
N
ame3 o o o o o o
… o o o o o o
N
amen o o o o o o

4
.Howf
requ
entdoy
our
ece
iver
elev
antp
rodu
ctknow
ledg
e,f
romth
isp
erson
,ino
rde
rto
b
eab
letoso
lveat
asksp
eci
ficfo
ryou
rro
le?(
Igno
rey
ourownnam
e)

N
eve
r Very R
are
ly O
cca
sion
ally F
requ
ent
ly Ve
ry
R
arely F
requen
tly
N
ame1 o o o o o o
N
ame2 o o o o o o
N
ame3 o o o o o o
… o o o o o o
N
amen o o o o o o

58
5. It is easy for you to access this person. (Ignore your own name and the persons you do
not interact with)

Strongly Disagree Neither Agree Strongly

Disagree disagree agree
nor agree
Name 1 o o o o o
Name 2 o o o o o
Name 3 o o o o o
… o o o o o
Name n o o o o o

59
 Department of Industrial Economics
Blekinge Institute of Technology, Campus Gräsvik, 371 79 Karlskrona, Sweden