Comparative Analysis of Software Development Practices across Software Organisations: India and Sweden

(1)

Comparative Analysis of Software

Development Practices across Software

Organisations

India and Sweden

Abheeshta Putta

Faculty of Computing

Blekinge Institute of Technology SE–371 79 Karlskrona, Sweden

(2)

This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science of Software Engineering. The thesis is equivalent to 20 weeks of full time studies.

Contact Information: Author(s): Abheeshta Putta E-mail: abpu15@student.bth.se University advisor: Dr. Kai Petersen Professor

Department of Software Engineering

Faculty of Computing 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

(3)

Context. System Development Methodologies (SDM’s) have been an area of inten-sive research in the field of software engineering. Different software organisations adopt different development methodologies and use different development practices. The frequency of usage of development practices and acceptance factors for adop-tion of development methodology are crucial for software organisaadop-tions. The factors of acceptance and development practices differ across geographical locations. Many challenges have been presented in the literature with respect to the mismatch of the development practices across organisations while collaborating across organisations in distributed development. There is no considerable amount of research done in context of differences across development practices and acceptance factors for adop-tion of a particular development methodology.

Objectives. The primary objectives of the research are is to find out a) differences in (i) practice usage (ii) acceptance factors such as organisational, social and cul-tural b) explore the reasons for the differences and also investigate consequences of such differences while collaborating, across organisations located in India and Sweden.

Methods. A literature review was conducted by searching in scientific databases for identifying common agile and plan-driven development practices and acceptance theories for development methodologies. Survey was conducted across organisations located in India and Sweden to find out the usage frequency of development prac-tices and acceptance factors. Ten interviews were conducted to investigate, reasons for differences and consequences of differences from the software practitioners from organisations located in India and Sweden. Literature evidences were used to sup-port the results collected from interviews.

Results. From the survey, organisations in India have adopted a higher frequency of plan driven practices when compared to Sweden and agile practices were adopted at higher frequency in Sweden when compared to India. The number of organisa-tions adopting "pure agile" methodologies have been significantly higher in Sweden. There was significant differences were found across the acceptance factors such as cultural, organisational, image and career factors between India and Sweden. The factors such as cultural, social, human, business and organisational factors are re-sponsible for such differences across development practices and acceptance factors. Challenges related to communication, coordination and control were found due to the differences, while collaborating between Indian and Sweden sites.

Conclusions. The study signifies the importance of identifying the frequency of development practices and also the acceptance factors responsible for adoption of development methodologies in the software organisations. The mismatch between these practices will led to various challenges. The study draws insights into various non-technical factors such as cultural, human, organisational, business and social while collaborating between organisations. Variations across these factors will lead to many coordination, communication and control issues.

Keywords: Development Practices, Agile Development, Plan Driven Development, Acceptance Factors, Global Software Development.

(4)

Acknowledgements

I would like to express my deep gratitude to my supervisor Dr. Kai Petersen for his unconditional support and exceptional guidance during the entire journey of my masters thesis. His motivation and encouragement during the process of my research is highly commendable. This work would have not been possible without his immense knowledge, valuable suggestions and discussions. I would like to express my heartfelt gratitude to my parents and my brother for their moral support. I would like to thank my cousins and relatives, everyone in name for their everlasting love and blessings. I would also like convey my special thanks to my friends and seniors for their continuous support. Lastly, I would like to pay my tribute to the sacred syllable “a-u-m”.

(5)

Abstract i

Acknowledgements ii

1 Introduction 1

1.1 Context . . . 1

1.2 Research Problem . . . 2

1.2.1 Choice of country selection . . . 3

1.3 Aim and Objectives . . . 4

1.4 Research Questions . . . 4

1.5 Expected Research Outcomes . . . 5

1.6 Structure of the Thesis . . . 5

2 Background and Related Work 6 2.1 Plan Driven Development Methodologies . . . 6

2.2 Agile Development Methodologies . . . 7

2.3 Acceptance factors for Adoption . . . 8

2.3.1 Theoretical Models of Acceptance . . . 8

2.3.2 Framework for Agile Acceptance Factors . . . 10

2.4 Role of Culture and Organisation Culture . . . 13

2.4.1 Organisational Culture . . . 13

2.4.2 Culture . . . 14

2.4.3 Global Software Development and Culture . . . 14

2.4.4 Collaborations between India and Sweden . . . 17

3 Research Method 19 3.1 Overview of the Research Process . . . 19

3.2 Literature Review . . . 20

3.3 Method Selection . . . 20

3.4 Implementation of Survey . . . 21

3.4.1 Research Objectives . . . 21

3.4.2 Survey Objectives . . . 21

3.4.3 Identification of the Target Audiences . . . 22

3.4.4 Design of the Sample plan . . . 22

3.4.5 Design of the Survey Questionnaire . . . 23

3.4.6 Validation of Survey Instrument . . . 23

3.4.7 Data Collection Process . . . 24

3.4.8 Consistency of Survey Data . . . 24

3.4.9 Analysis of the Survey Data . . . 25

3.4.10 Validation of Survey Results . . . 26 iii

(6)

3.5 Interviews . . . 26

3.5.1 Overview . . . 26

3.5.2 Interview Structure . . . 27

3.5.3 Selection of Interviewees . . . 27

3.5.4 Formulation of Interview Questionnaire . . . 28

3.5.5 Interview Design . . . 28

3.5.6 Analysis Protocol for Interviews . . . 30

4 Results and Analysis of Survey 34 4.1 Overview of the results . . . 34

4.2 Demographic Results . . . 34

4.2.1 Analysis of characteristics of Organisation . . . 34

4.2.2 Analysis of Collaborations across Organisations . . . 36

4.3 Analysis of Development Methodology . . . 36

4.4 Agile Practices and Global Software Development . . . 40

4.5 Analysis Development Practices Usage . . . 40

4.6 Analysis of Acceptance Factors . . . 42

4.6.1 Statistical Significance Testing for Development Practices and Acceptance Factors . . . 43

4.7 Development Methodologies and Acceptance Factors . . . 47

4.8 Key Findings . . . 50

5 Results and Analysis of Interviews 52 5.1 Results of Open Coding . . . 52

5.2 Results of Axial Coding . . . 54

5.3 Results of Selective Coding . . . 56

5.4 Analysis of the Interviews . . . 56

5.4.1 Reasons for Differences across Development Practices . . . 56

5.4.2 Consequences of Differences across Development Practices . . . 61

5.4.3 Reasons for Differences across Acceptance Factors . . . 63

5.4.4 Consequences of Differences across Acceptance Factors . . . 67

5.5 Validation of the data . . . 68

6 Discussion and Limitations 70 6.1 Reflections on differences in Practices, Reasons and Consequences . . . 70

6.2 Reflections on differences in Acceptance Factors, Reasons and Consequences . . . 73

6.2.1 Research Implications . . . 75 6.3 Threats to Validity . . . 81 6.3.1 Internal Validity . . . 81 6.3.2 External Validity/Generalisability . . . 82 6.3.3 Construct Validity . . . 82 6.3.4 Conclusion Validity . . . 83

7 Conclusions and Future Work 84 7.1 Conclusions . . . 84

7.1.1 Revisiting the Research Questions . . . 84

7.1.2 Research Contributions . . . 85

7.1.3 Lessons Learnt . . . 86

7.2 Future Work . . . 86 iv

(7)

Appendices 104 A Appendix A 105 B Appendix B 109 C Appendix C 122 D Appendix D 141 v

(8)

List of Tables

2.1 Construct Mapping . . . 11

2.2 Acceptance Factors for Traditional Models . . . 12

2.3 Acceptance Factors for Agile Models . . . 12

2.4 Non-Technical Factors of Adoption . . . 14

2.5 Cultural Dimensions and Differences . . . 18

2.6 Studies between India and Sweden . . . 18

3.1 Mapping of research questions and research methods . . . 20

3.2 Units of analysis . . . 22

6.1 Validation of Interviews with the Literature Evidences . . . 76

D.1 Survey Questions . . . 142

D.2 Survey Questions Mapping . . . 143

D.3 Survey Questions mapping with theories of acceptance . . . 144

(9)

2.1 Overview of Background and Related Work . . . 7

2.2 Agile Family . . . 8

2.3 Innovation Assimilation Stages . . . 11

2.4 Organisational culture with Iceberg . . . 13

2.5 Different cultural Dimensions . . . 15

2.6 Virtual Onion:Layers of culture . . . 16

2.7 Mapping between Cultural Dimensions and Acceptance factors . . . 17

3.1 Research Process . . . 19

3.2 Flow of events in the survey . . . 27

3.3 list of interviews . . . 29

3.4 Flow of events for Interview Questionnaire . . . 30

3.5 Flow of events in the Interviews . . . 33

4.1 Primary role the organisation in India and Sweden . . . 35

4.2 Years of experience of the respondents in India and Sweden . . . 35

4.3 Team Size . . . 36

4.4 Size of the organisation . . . 37

4.5 Quality Certification . . . 37

4.6 Type of location . . . 38

4.7 Type of sourcing . . . 38

4.8 Collaborating organisations location in India . . . 39

4.9 Collaborating organisations location in Sweden . . . 39

4.10 Development Methodology . . . 40

4.11 Development Process: In-sourcing and Outsourcing . . . 41

4.12 Development Process: Outsourcing . . . 41

4.13 Development Process: In-sourcing . . . 42

4.14 Frequency Distribution of Development Practices between India and Sweden . . 44

4.15 Differences across Development Practices between India and Sweden . . . 45

4.16 Distribution of Acceptance Factors between India and Sweden . . . 46

4.17 Differences across Acceptance Factors between India and Sweden . . . 48

4.18 Mann-Whitney U test for Development Practices between India and Sweden . . . 49

4.19 Mann-Whitney U test for Acceptance Factors between India and Sweden . . . 49

4.20 Multinomial Regression Analysis . . . 51

5.1 Bridging between Survey and Interviews . . . 53

5.2 Axial Coding . . . 54

5.3 Codes identified for Reasons for differences differences across Development Prac-tices and Acceptance Factors . . . 55

(10)

5.4 Codes identified for Consequences of differences across Development Practices and

Acceptance Factors . . . 57

5.5 Selective Coding . . . 58

5.6 Axial Coding :Relationships . . . 69

7.1 Synthesis of the Findings for Development Practices . . . 88

7.2 Synthesis of the Findings for Acceptance Factors . . . 89

B.1 Questionnaire . . . 115 B.2 Questionnaire . . . 115 B.3 Questionnaire . . . 116 B.4 Questionnaire . . . 116 B.5 Questionnaire . . . 117 B.6 Questionnaire . . . 117

B.7 Pre-coding : Transcription Process . . . 118

B.8 Express Scribe . . . 118

B.9 Transcription . . . 119

B.10 Cluster Analysis : Nvivo 10 . . . 119

B.11 Word Frequency Report . . . 120

B.12 Nodes and Relationships . . . 120

B.13 Frequency of the Open Code Categories Consequences . . . 121

B.14 Frequency of the Open Code Categories Reasons . . . 121

C.1 Normality Test for development practices . . . 124

C.2 Normality Test for acceptance factors . . . 125

C.3 Hypothesis Testing for Development Practices . . . 126

C.4 Hypothesis Testing for Acceptance Factors . . . 127

C.5 Logit transformation for R1 . . . 128

C.24 Logit transformation for R20 . . . 138 viii

(11)

C.27 Logit transformation for R23 . . . 139 C.28 Logit transformation for R24 . . . 140

(12)

Chapter 1 Introduction

1.1 Context

A Systems Development Methodology (SDM) is defined as set of policies, procedures and pro-cesses that are commonly used by software development teams [1]. SDMs could be further elaborated as the following [2]:

• A system development approach: This involves a philosophical view, it includes set of goals, principles and beliefs which drives the process of actions.

• A systems development process model: It is the sequence of stages through which a system evolves.

• A systems development method: It is a set of guidelines, tools, techniques and practices. • A system development technique: It is a set of well-defined procedures to carry out the

activities.

The SDM’s have been evolving over time with the change in the technologies and to meet the dif-ferent user needs [3]. The traditional systems were developed by using the code and fix method, initiated in United States, which involved coding then followed by the correction of the errors then iterations till the completion of the project [4]. This particular method of the system devel-opment is presently known as ad-hoc method. The next model, which followed the ad-hoc is the stage wise development. It can also be called as an older or less developed version of the water fall model [4]. From phase wise models there was shift to evolutionary models, which base their phases on iterative processes and incremental models [4].

Based on the above models, the most commonly used development methodologies can be broadly classified into rigid or plan driven methods and agile development methods [3]. The traditional or plan driven methods largely focus on the upfront planning, extensive documented plans, low change, emphasis for contracted provisions and one way communication [3] [5]. Whereas the agile development is oriented towards rapid value, high change frequency, on-site customers [3]. There have been many factors responsible, which have been identified for the acceptance of devel-opment practices across various organisations [1]. In the recent years there has been shift from traditional practices towards agile practices. Research also showed adoption of the combined approaches of rigid development and agile practices have benefited the organisations [3]. Agile methods are adopted as they are more flexible in handling the change in requirements compared to plan driven development [6]. Many factors such as technical, individual cultural, social and or-ganisational have contributed towards acceptance of different development methodologies across different organisations [1].

(13)

1.2 Research Problem

Due to the rise in globalization, the organisations are moving towards product onshore and off-shore outsourcing, in-sourcing by building strategic alliances with organisations located in various parts of the world [7] [8] [9] [10] [11]. Economic factors have motivated the national markets to turn into global markets, this impelled to form new mechanisms of cooperation and competi-tion across nacompeti-tional boundaries [12]. This subsequently resulted in Global Software Development (GSD), which led to transformation from a single-site to a multi-site, multi-cultural, multilingual and globally distributed endeavours [13]. It has been evident from from the literature distributed development is not an easy and straight forward task, organisations have been facing formidable challenges at various levels from technical to socio-cultural [12]. Apart from different geograph-ical, temporal, organisational, cultural and social challenges [14], several studies in GSD, have reported, inconsistency in the development practices, tools, work practices, different maturity and development process mismatch as major hindrances, while collaborating across organisations [15] [16] [17] [18] [19] [20].

Different studies have compared the development methodologies across organisations [21] [22] [23]. These methodologies reflect viewpoints and perceptions of the people who involve in adopt-ing the methodologies [2]. Research has also documented the role of beliefs, organisational culture and technical factors on the practices and also has mentioned the connection between practices, organisational culture and individual culture [24]. Many factors have been contributed towards acceptance of different development methodologies and adopting across the organizations [1], these acceptance factors are categorised into technical, social and organisational [1].

The global survey on development practices adopted by different organizations shows that de-velopment practices vary across organizations depending upon the variation in the acceptance factors [25] [23]. No considerable amount of systematic research has been done across differences in acceptance factors and usage frequency of development practices. Many studies have reported the comparison of plan driven practices across organisations [25], but in these studies only few agile methods were surveyed [25] [23], this draws the need to conduct a survey which includes the agile development methods as most of the organisations have shown interest towards agile global software development [26] [20].

For successful global software development there is a need for the organisations to understand the current development practices and also the acceptance factors, which are responsible for adop-tion of practices across organisaadop-tions. Different challenges are associated with differences in these practices across collaborating environment [20]. It is important to know the state of practice of the development practices to coordinate and collaborate across organisations. Differences in such practices will also lead to misalignment. Therefore is crucial to find out the usage of develop-ment practices adopted in different organisations and cultural, organisational, and social factors of acceptance associated for acceptance of these practices. It is crucial to explore the variations between usage of practices, acceptance factors of adoption and investigate into consequences of such differences while collaborating between organisations. Hence it draws the need to know the practices adopted by organizations located in different countries for successful distributed software development. The research problem is summarised into the following research gaps:

• State of practice of usage of agile and plan driven practices across different organisations has not be reported in the literature [23] [25].

• Agree-ability of different acceptance factors has not been investigated [1].

• Individual cultural and organisational acceptance factors have not been inquired in the context of acceptance of development process [1].

(14)

Chapter 1. Introduction 3 researched [20].

• Challenges in the context of mismatch of practices are not yet discovered in the literature [20]

• Different contextual factors for the organisations adopting agile practices in GSD are not analysed [27] [26].

For successful distributed development, across organisations it is necessary to address these research gaps. There is a need for the organisations to reflect on the factors related to mismatch of practice usage and consequences of such mismatch in globally distributed projects to leverage the benefits of GSD. Hence, this research tries to explore the factors and consequences, which would support the framework of suggestions for practitioners and researchers for process standardisation in GSD.

1.2.1 Choice of country selection

Two countries have been selected to compare the development practices and the respective ac-ceptance factors for adopting such practices. These countries are given below:

India:

Economic imperatives have been driving forces for the different organizations to move towards global software development [28]. Offshore Attractive Index (OAI) has identified many countries suitable as the outsourcing destinations [28], India has been ranked on top. Significant global development efforts has been taken place in Israel, Ireland and India (3I’s). India continues to be the undisputed outsourcing and off-shoring location [28]. India has also been a leading GSO subcontractor, nearly developing around four billion US dollars in software for foreign companies. It also been observed that offshore development to India has reduced the costs by 50 percent [29]. India is often perceived as a homogeneous nation according to the western perspective but in reality it is not.

India has been referred as a subcontinent due to the size and population. It is made up of 29 states and 22 scheduled (official) languages [8]. It has been also evident that the cultural, lin-guistic and ethnic diversity is only exceeded by Africa [8]. Hence the software industries located in India are highly influenced by such diversified culture [8]. Therefore it justifies the choice of India to study the development practices, factors which have influenced the acceptance of agile methods and other development models. It can help foreign organizations for better strategic alliances for outsourcing and off-shoring with organisations located in India.

Sweden:

Sweden also has been involved in different global software development many software organiza-tions have been involved in collaborating with other organizaorganiza-tions, for example Ericsson. Sweden is also involved in many large global projects like the GNOME [30]. It has also observed that, Sweden has the second largest group of active researchers in GSD [31]. Scandinavia (part of North Europe) has rich cultural, ethnic and linguistic diversity, Sweden belongs to Scandinavian peninsula, which has a different culture when compared to Indian culture [32].

Benefits:

India and Sweden belong to the top seven locations for GSD [33]. Various studies have reflected collaborations between India and Sweden [34] [35] [36] [37] [35], this shows organisations interest in strategic alliances between India and Sweden [38] [39] [40] [41]. Studies have not explored the usage of development practices and challenges due to the differences.

Different organisations located in India, Sweden and also other countries, can gain insights into the usage practices and acceptance factors across India and Sweden. Due to presence of highest frequency of collaborations in GSD with India (specially with Europe and USA) [33],

(15)

organi-sations can use the learning and understanding gained through the present research and reflect on their collaborations. This helps in understanding usage frequency of practices and factors responsible for such practices in the organisation by delving into factors such cultural, organisa-tional, human and social. The reasons and consequences of differences could be used to mitigate the challenges that organisations face during the process of collaborating. Therefore it justifies the choice of Sweden and India for comparison. Other countries which are keen to form alliances either with Sweden or India could leverage from this study.

1.3 Aim and Objectives

The aim of the research is to find the state of practice of different development practices and acceptance factors for adopting the development practices in different software organisations located in India and Sweden.

The aim could divided into following objectives:

• Study the usage frequency of development practices across organisations in India and Swe-den.

• Understanding the agree-ability of acceptance factors such as organisational, cultural, social and human across India and Sweden.

• Capturing the factors responsible for mismatch of development practices and acceptance factors.

• Investigating the consequences of such differences while collaborating between India and Sweden.

1.4 Research Questions

The following research questions have been formulated to fulfill the objectives of research. RQ1. What are differences in (a) usage of development practices and (b) acceptance factors across software organisations in India and Sweden?

• (a). The frequency of the development practices is influenced by different social factors of the organisation [42]. The software development elements have been classified into useless SDM elements, Inefficient SDM elements, Unadopted SDM element, Usefull SDM elements based on technical and social suitability of the development practices in the organisation [42]. Hence, usage of development practices differs from one organisation to another. As reported from the literature, mismatch of practices as most common challenge [43], it is important to understand the frequency of adoption of the development practices.

• (b). Different acceptance factors such as technical, organisational, cultural and social have been influencing the adoption of development processes across software organisations [24] . Limited amount of research has been done in the context of non- technical acceptance factors (organisational, cultural and social) [1] [44]. These factors have contributed towards different development processes and approaches. The agree-ability of these factors has never been captured across different organisations.

RQ2. What are the (a) reasons for such differences and (b) consequences for existence of such differences while collaborating between organisations in India and Sweden ?

(16)

Chapter 1. Introduction 5 • (a). Mismatch of the development practices has been a reported to be most common challenge in GSD [15] [16] [18] [19] , but the reasons for such mismatch of practices across collaborating organisations are not yet explored [43] [20]. Challenges due to differences in social, organisational and cultural differences in GSD has been investigated but in relation with acceptance factors of adoption of development process has not been analysed [20] [43]. The reasons for differences across acceptance factors also has not been investigated. Cap-turing the factors responsible for such differences could help in suggesting new development approaches that could be adopted in distributed development [43] [20].

• (b). Studies have conducted research based on differences organisations due to differences in organisational factors, socio-cultural factors and reported cultural, intra-organisational and socio technical challenges, but the consequences of such differences in the context of mismatch development practices and acceptance factors has never been investigated. These consequences could help in forming the base for listing the mitigation strategies for such differences across sites in global projects and help in designing a framework for new approaches of development practices suitable for distributed teams [20] [43].

1.5 Expected Research Outcomes

The thesis report is expected to fulfill the research aim and objectives by reflecting the knowledge and understanding gained by answering the research questions. This includes:

• Understanding the differences across the usage of development practices and different ac-ceptance factors such as organisational, cultural and social between organisations in India and Sweden.

• Reasons for differences across the differences between practices and acceptance factors. • Consequences of differences while collaboration between organisations in India and Sweden.

1.6 Structure of the Thesis

The thesis is structured into six different chapters. Chapter 1, consists of the Introduction, which defines the terminology, relevant concepts, the context, research gap, research objectives and re-search questions. Chapter 2, describes about the background and related work, it explains about different development paradigms, acceptance models, and studies which have explored the rela-tion between acceptance factors for different development methodologies cultural theories and its construct mapping with acceptance theories. It also illustrates the studies in global software engineering and differences in socio-cultural aspects.

Chapter 3, Research method, provides detailed description of research methods namely literature review, survey and interviews. It also explains about how the results of survey and interviews have been analysed. The Chapter 4, presents the survey results, analysis and interpretation using descriptive statistics. The Chapter 5, describes the results and analysis of interviews using the grounded theory.

Discusions and limitations are presented in Chapter 6, which discusses the overall results sup-porting with the literature and threats to validity are reported. The Chapter 7, expounds about the conclusions, presents answers to the research questions and scope of future research.

(17)

Background and Related Work

Development methodologies need to be accepted to be adopted across organisations. Here we investigate the factors of acceptance that led to acceptance of development methodologies. We start by describing the development methodologies in the section 2.1 and Section 2.2, then we go the theoretical models of acceptance in the section 2.3 and empirical evidences of the acceptance factors. Culture factors are part of the acceptance factors, which are not reviewed in context of acceptance factors in the literature, Section 2.4 describes about the organisational culture, cultural theories and mapping of the cultural theories with theoretical models of acceptance. In section 2.5, we discuss about the different studies, which focused on cultural dimensions, social factors and studies concerning to Europe and India especially to Sweden and India in context of GSD to the understand the differences. The overview of the background section is pictorially represented in the Figure 2.1.

2.1 Plan Driven Development Methodologies

Plan driven development focuses on strategic planning, heavy documentation and sequential ex-ecution of the development activities [45]. It has designated responsibilities for the individual software development disciplines for example requirement engineering, architecture design, im-plementation and quality assurance [45]. The most commonly used plan driven practices are Waterfall model, Rational Unified Process model and V-Model. These are described below:

• Waterfall Model: The waterfall model is most notable instantiation of the plan driven development. It has different phases, when each phase is completed the product of that particular phase is handed over to next subsequent phase [46]. The waterfall model given by Walter Royce includes: System Requirements, Software Requirements, Analysis, Coding, Testing and Operations [46].

• Rational Unified Process Model: It is divided in four phases: Inception, Elaboration, Construction and Transition. These different phases are overlapping throughout the devel-opment life-cycle and activities focus in phase depends on the develdevel-opment phase [47]. It has extensive documentation of the risk plans, management plans [48].

• V Model: The V-Model is an extension of the waterfall model of development [45]. Each phase of the model is mapped with verification and validation of the respective phase [45]. After the product is delivered, it is followed by operations and maintenance [45]. Each phase is verified and validated.

The common practices used in plan driven development across software organisations are : all the desired functions, properties, specifications are specified well in advance, requirements are specified in detailed orientation [45] [49], the process of change of the requirements is carried by the change request and change management [45][49], design and architecture are completed

(18)

Chapter 2. Background and Related Work 7

Figure 2.1: Overview of Background and Related Work

before the implementation is started, programing is implemented only in the development phase, testing is done at the end of the project, quality assurance is handled in a formal manner [49] [45].

2.2 Agile Development Methodologies

Agility is defined as “stripping away as much of heaviness, commonly associated with the tra-ditional software development methodologies, as possible to promote quick response changing environments, changes in the user requirements, accelerated project deadline and the like” [50]. In the year 2001 [50], “the agile manifesto” was written, which states four core values [51], they are

• V1: Individuals and interactions over processes and tools • V2: Working software over comprehension documentation • V3: Customer collaboration over contract negotiation • V4: Responding to change over following plan

Twelve agile principles [51] related to the core values are AP01: Customer satisfaction, AP02: Welcome Change, AP03: Frequent deliveries, AP04: Work together, AP05: Motivated individ-uals, AP06: Face-to-conversation, AP07: Working software, AP08: Sustainable pace, AP09: Technical excellence, AP10: Simplicity, AP11: Self-organising teams, AP12: Continuous reflec-tion.

The most common agile methodologies are Crystal Methodologies, Dynamic Software Develop-ment Method, Feature Driven DevelopDevelop-ment, Adaptive Software DevelopDevelop-ment, Scrum and Ex-treme Programing(XP) [52] [53].

Different agile practices that have been adopted in the organisations, the most common practices have been defined in the Appendix A (refer to Section A. The agile family with the characteristic features has been represented in the Figure 2.2.

(19)

XP foredeveDesigningtestsbe-lopment ,stand-ups,40hoursperweek

Scrum _agementpartMorefocuson man-_,spr_ints

FDD listoFeaturewfrequiseirements,priorit,featureized teams,inspection,ownership

DSDM F_trequentde_iveuserinvolivery_lvement

,ac-ASD Disturbeddeve_at_ive_{,constantprototyp}lopment,iter-_ing

Crystal _s_ionStag_,reﬂecting,rev_ionworkshopsiew,rev

i-Figure2.2: AgileFamily

2 .3 Acceptancefactorsfor Adopt

ion

The methodologyadoptioninanorganisationcouldbedrivenbythefollowingfactors[54][1]: •Presenceoftheorganisationalmandateattheorganisationtouseaparticularmethodology

[54][1].

•Compatibilityofthe methodologywithotheraspectsofwork[54][1].

•Opinionsoftheindividual’s,co-workersandsuperiorsworkingintheorganisation[1].[54].

2 .3

.1 Theoret

ica

l Mode

lsof Acceptance

ManydifferenttheoreticalmodelshavebeenadoptedintheISliteraturetofindoutthedifferent factorsofacceptancebyindividualsinanorganisation. These modelshavesimilaritiesand differences,thesehavebeenvalidatedinthecontextofindividuallevel,enduserlevel,socialand organisationallevel[54][1]. Theconstruct mappingofallthetheoretical modelsofacceptance factorsisrepresentedin Table2.1. Thecharacteristicdescriptionofeach modelisdescribed below.

Technology Acceptance Model(TAM): This modelwasintroducedby Davisealand Davistoexplaintheknowledgeandindividualadoptionfactorsforinformationtechno logyadop-tionattheorganisationalworkplace[55][56]. Accordingtothismodelthetwocrucialacceptance factorsthathaveinﬂuencedthedevelopment methodologyadoptionare:

(20)

Chapter 2. Background and Related Work 9 • Usefulness: In this model usefulness is from the perspective of the individual who has accepted a particular method or a development practice in his/her work. This can also defined as the extent to which the person thinks using this method will enhance the job performance [54].

• Ease of Use: The extent to, which the person who is using the system or a method is free from effort [54]. Both of these factors typically the perceived usefulness of the individual has a strong influence on the usage of a particular method and ease of use has a significant secondary effect [54].

Technology Acceptance Model 2 (TAM2): TAM could not include all the factors of ac-ceptance, hence an extension was made by including additional constructs [57]. Two important components, voluntariness and mandatory usage were included in the model [54]. The two con-structs are defined below:

• Subjective Norms: It is an extent to, which a person think who are important to them want them to perform these methods in their work [54].

• Voluntariness: The extent to, which the adopters perceive the adoption of the methodology into their work as non-mandatory [54].

Perceived Characteristics of Innovation (PCI):Moore and Benbasat published an instru-ment to measure the extent to, which a new method or technology is accepted by the individuals at the workplace [58] [59]. Seven constructs were defined in this model they are as follows:

• Relative Advantage: The degree to, which an individual perceives the new innovation or technology introduced in the organisation better than the previous one [54].

• Complexity: The degree to, which an individual perceives the new innovation as being difficult to use [54].

• Compatibility: The degree to, which an individual perceives as being consistent with the existing values, needs and past experiences [54].

• Image: The degree to, which adopting a new technology is perceived to enhance an indi-vidual’s image or status in the organisation .

• Result Demonstrability: The degree to, which the new innovation or technology is able to demonstrate its advantages.

• Visibility: The degree to, which the new technology are observable by others in the organ-isation.

• Voluntariness: The degree to, which the usage of the new technology or innovation is non-mandatory in the organisation. This is similar to the one of the factor that has been defined in the TAM2 and also measured in the similar pattern.

Theory of Planned Behaviour (TPB): This is model was introduced by Ajzen and his colleagues in social psychology. There are three determinants for this theory they are defined as follows:

• Perceived Behaviour Control: It the degree to, which one’s internal or external perceptions effect the behaviour. Further divided into

(21)

– External Constructs: The organisational factors.

• Subjective Norms: This is similar to the TAM and also measured in the same way. • Attitude: The degree of favourableness or unfavourableness of an individual to perform a

method or target behaviour which conceptually equivalent to TAM’s usefulness construct. Model of Personal Computer Utilization (MPCU):Thompson has introduced this model which was based on Triandis model of interpersonal behaviour from social psychology [60]. The factors are defined below:

• Social Factors: This refers to the subjective culture, interpersonal agreements that an individual working in an organisation has made with others [54].

• Affect: This is defined as the positive or negative reactions to a particular act at the organisation [54]. These are again divided into following:

– Long- term factors:

∗ Career Consequences: This refers to how an individual thinks about his future opportunities this might include preferred assignments and promotion [54]. – Near- term factors:

∗ Complexity: The degree of how easily an act can be performed [54].

∗ Job Fit: The degree of usefulness of the methods which is similar to the perceived useful from TAM [54].

• Facilitating Conditions: The external environment that makes the person to do this meth-ods or practices easily [54].

Diffusion of Innovation (DOI): The description of the assimilation of innovation into an organisation, group of individuals, or individual, Gallivian has introduced the model of diffusion of innovation [59] [61]. The model consists of the following six steps (refer to Figure 2.3) [61] :

• Initiation: It is a match of the innovation and the suitability to the application. • Adoption: The decision is made to adopt a particular method in the work [61].

• Adaption: The decision to adopt is adjusted according to the needs, it is installed and training is provided for the new method [61].

• Acceptance: The adoption of the methods by people will commit to use the method [61]. • Routinization: The new method is carried out as a normal activity and usage is always

encouraged [61].

• Infusion: The new innovation is used in an comprehensive manner so the effectiveness and productivity of the method increases [61].

The six different stages of the diffusion of innovation has been depicted in the Figure 2.3 . This concludes, that its a long and a cyclic process.

2.3.2 Framework for Agile Acceptance Factors

The acceptance models have been discussed in the previous section could be crucial for finding the factors of adoption of SDMs. But in case of agile methodologies there is a need to examine the customer related factors as well. The users and customers play an important role in case of agile methodology adoption [1]. The conceptual framework of agile factors could be divided into following categories [1]:

(22)

Chapter2. BackgroundandRelated Work 11

Initiation Adoption

Adaption Accep-tance Routin i-zation Infusion

Figure2.3:InnovationAssimilationStages

Table2.1: Construct Mapping

Factors/Theories TAM TAM2 PCI TPB MPCU Usefulness[54] yes yes yes yes yes Easeofuse[54] yes yes yes yes SubjectiveNorms[54] yes yes yes

Aﬀect[54] yes

Voluntariness[54] yes yes Compatibility[54] yes Result demonstrability

[54] yes

Image[54] yes

Visibility[54] yes BehaviourcontrolInternal

[54] yes

BehaviorcontrolExternal

[54] yes yes

(23)

Table 2.2: Acceptance Factors for Traditional Models

Source Methodology Factors of acceptance

Hardgrave et al [62] Structured development Usefulness, social pressure, compatibil-ity, organisational mandate

Khalifa and Verner [63] Waterfall and prototyping Facilitating conditions

Templeton and Byrd [64] SDM Ease of use, compatibility, trial-ability, knowledge of probability

Iivari abd Hogan [65] SDM Organisational culture, social norms, voluntariness

Robert and Hughes [66] SDM Management commitment, external support

Table 2.3: Acceptance Factors for Agile Models

Source Methodology Factors of acceptance

Cehiet at [50] Agile(Scrum and XP) Team work, individual ability, motiva-tion

Cockburn and Highsmith

[67] Agile Individual competence,compatibility,team work, project type Cohn and Ford [68] Scrum and XP Past experience, micromanagement,

ca-reer consequences,developers ability Drobka et al [69] XP External support

Schatz and Abdelshafi [70] Scrum External support, teamwork, compati-bility

Nerur et al [71] Agile Organisational culture, customer rela-tionship, management style

MC Manus [72] Agile Experience, compatibility, communica-tion

• Knowledge Outcome Factors : Knowledge creation, retention and storage [1]. • Ability Related Factors: Self-efficacy, experience, training, external support [1].

• Motivation Related Factors: Career consequences, top management support, voluntariness, organisational culture [1].

• Opportunity Related Factors: Shared understanding, team work, communication, adrous relationship [1].

• Agile Methodology Characteristics: Perceived usefulness, perceived ease of use, compatibil-ity, perceived maturity [1]

The acceptance of system development methodologies represents much more radical change com-pared to other technology or tools acceptance [54] [1]. Factors of acceptance here mean that they contributing to the acceptance and use of methodology in the organisation. Different factors other than theoretical models (discussed in Section 2.3) have contributed for accepting develop-ment methodologies, these differ from one study to another, this merits to further investigation by considering larger number of data points. The summaries from the previous studies have been presented in the Table 2.2 and Table 2.3 of this section.

(24)

Figure 2.4: Organisational culture with Iceberg

2.4 Role of Culture and Organisation Culture

Clifford Greetz defined culture as " a historically transmitted pattern of meanings embodied in symbols, as system of inherited conceptions expressed in symbolic form by which individuals com-municate, perpetuate and develop their knowledge about attitude towards life" [73] [74]. The concept of culture has been studied in the domain of information systems and information tech-nology from the early days of its emergence [74]. The values, beliefs, which have influenced individuals have been studied under various categories such as national culture, organisational culture, ethnic culture, professional culture [74]. This section describes about the organisational culture and different cultural theories that have influenced software organisations.

2.4.1 Organisational Culture

Organisational culture is defined as set of values, beliefs and assumptions that are shared by the members who are working in an organisation. These values have influenced the behaviour and decisions of the individuals working in an organisation [75]. The organisational culture forms the context where the system development takes place [65]. There is a common understanding that beliefs and behaviour are related to each other, to find out about the different development practices that an individual adopts it is necessary understand them [24]. Organisational culture has influenced the deployment of the SDMs, and adoption of the development methods into the organisation [65]. The values beliefs belong to the invisible layer of the organisational culture (OC), this has been represented in the Figure 2.4 [76]). Different studies have reflected the influence of organisational culture on SDM adoption, few studies have reflected the influence of OC on development methodologies this have been presented in Table 2.2, Table 2.3 and Table 2.4.

(25)

Table 2.4: Non-Technical Factors of Adoption

Category Adoption Methodology Acceptance Factor

Organisational Culture X XP Innovation and Risks, Detailed Orientation, Outcome Orienta-tion, People OrientaOrienta-tion, Team Orientation, Aggressiveness, Stability [81].

Innovation X Scrum Relative advantage, diffusion of innovation, TAM2 [61].

Individual culture

fac-tors X SDM Power Distance, Collectivism,welfare orientation [44] Social Factors X SDM Frequency of usage, Consistency

of use [42]

2.4.2 Culture

Various cultural theories have described, different dimensions of culture, which have influenced the software organisations [77] [78] [28] [79]. The construct mapping between all the cultural theories is presented in the Figure 2.5, which has been summarised from [77] [28] [78] [79]. The relationship between the national, organisational and work culture has been presented with the help of Virtual Onion [80] [74]. The metaphor onion suggests that, just like onion, culture has various overlapping layers [74]. Each layer may represent one component of culture and virtual means these layers are not consistent they may overlap or change according to the time and situation [74]. The national culture may correspond to the religious, political groups, which may influence the professional and organisational culture. The individual interacts with other layers as well. Further it will influence the work culture and individuals working in the organisation [74]. All the layers have been represented in the Figure 2.6 [80] [74]. Different cultural, organisational cultural, social factors have an impact on the adoption of the software development methodologies [1]. Analysis of these different levels of organisational culture will improve the perception of the organisation’s global culture [76]. Many aspects of the organisation are usually hidden at the lower levels [76]. People might get wrong interpretations by looking at the higher levels of the organisational culture, may be due to the influence of the underlying assumptions of the organisation [76] (refer to Figure 2.4). The studies, which reflected the role of culture, organisational culture and social factors in adoption and acceptance of development methodologies have been described in the Table 2.4.

The relationship between the cultural dimensions from the cultural theories and the accep-tance factors from accepaccep-tance theories and agile accepaccep-tance framework have been mapped in the Figure 2.7. This shows how the acceptance factors are influenced by the cultural factors. This mapping has been made by analysing the cultural theories and models of acceptance factors from [28] [54] [82] [83].

2.4.3 Global Software Development and Culture

Culture appears to have a greater influence on software engineering practices, than originally envisioned. Culture has been stated as a centrifugal issue and cultural diversity as a barrier for distributed development [28]. Like, any other discipline, software engineering also posses its own culture, which has been evolved over time across different national and organisational cultures. Several studies have reflected the influence of culture in GSD [82] [83]. Studies have compared the

(26)

(27)

(28)

Figure 2.7: Mapping between Cultural Dimensions and Acceptance factors

different dimensions of culture [82] [28] (refer Figure 2.5)(construct mapping of the theories have been made in the figure from [28][82][77]), and reported the differences between these dimensions (refer Table 2.5). These studies have serious limitations of applying the cultural dimensions to various software practices in different geographical locations [82]. These studies have reflected culture to be static having predefined dimensions and generalised their finding by stereotyping [82]. In this particular study cultural dimensions were not compared directly, rather used to support the en-captured culture from the development practices and acceptance factors from the qualitative study.

2.4.4 Collaborations between India and Sweden

India is considered to be as one of the main outsourcing destination [28]. India and Sweden have high frequency of global collaboration projects [33]. Studies have reflected the experience of working with Indian teams and Sweden teams. Different challenges were mentioned in such studies, but these never reflected on the usage practices and impact cultural, organisational and social factors on development practices. The description of various studies between India and Sweden is presented in Table 2.6.

(29)

Table 2.5: Cultural Dimensions and Differences Countries Research

method

domain Dimensions Australia and USA Case study Requirement

Engi-neering Cultural differences- Greet Hof-stede’s theory- power distance [84]

USA and India Grounded

the-ory Agile methods Cultural differences [85] China - Germany Case study Requirement

Engi-neering CulturalHofstede’s-power distance, indi-Dimensions-Greet vidualism uncertainty avoidance, orientation and masculinity [86]. - Survey Issues in Global

teams Cultural differences Greet Hofst-ede’s dimensions [83] India and others - software practices Cultural differences Greet

Hofst-ede’s dimensions [87] Bangladesh Case study Software Process

Improvement Greet hofstede’s organisationalculture and cultural dimensions [88]

- - agile practices culture, values, beliefs clashes [89].

India Inductive

grounded theory projectment manage- Cultural dimensions- power dis-tance [8] Ireland and Malaysia Case study and

action research GSD Cultural dimensions- power dis-tance, Gender [28] India, Japan and USA - Software

develop-ment problems Greet Hofstede’s cultural dimen-sions power distance, individual-ism, uncertainty avoidance [90]

Table 2.6: Studies between India and Sweden Authors Sourcing Strategy Description of the study D. Smite and C.

Wohlin [91] Offshore-Outsourcing Product transfer from Sweden to In-dia for cost benefits and free up the re-sources in Sweden.

N.B. Moe and D.

Smite [38] Offshore-sourcing Out- Development phase outsourced to In-dia, turnover challenges and temporal distance are mentioned.

R. Jabangwe and

D. Smite [40] Offshore-Outsourcing Development and maintenance phaseand quality of the product. D. Smite and

V.Steinbergacase [41]

Offshore -

Out-sourcing India (Service Provider) and job satis-faction of the outsourcing site is stud-ied.

(30)

Chapter 3 Research Method

3.1 Overview of the Research Process

This section of the document explains about the methods that have been selected to find out the answers to the research questions and fulfilment of the research objectives. This section also provides the details about how the research process is carried out and how the results are analysed and interpreted. Three different approaches were selected to carry out the research process:

• Literature Review • Questionnaire • Interviews

A literature review is carried out to find the different practices used in agile development and plan driven development. Different acceptance factors for adoption, such as technical, cultural and organisational are researched. To determine what practices do organisations in India and Sweden have adopted and different acceptance factors, a survey was conducted. After analysis of the results from the survey, interviews were conducted to find out the reasons for differences in development practices, acceptance factors across organisations and also consequences due to such differences while collaborating between India and Sweden. These interviews also served as a base to check the validity of the results obtained from the survey. The results obtained from the interviews were analysed using Grounded Theory and validated with the help of literature. The research approach is represented by a diagrammatic presentation Figure 3.1. The research starts with literature review and ends with validating interview data with literature evidences. The mapping between research questions and research methods is given in Table 3.1.

The next sections of this chapter will elucidate about the process of survey, the instruments used for survey and process of interviews and results analysis.

Figure 3.1: Research Process

(31)

Table 3.1: Mapping of research questions and research methods RQ/Research

Method Literature Review Survey Interviews

RQ.1.a. X X

-RQ.1.b. X X

-RQ.2.a. - - X

RQ.2.b. - - X

3.2 Literature Review

A literature review is carried out in order to find the relevant literature in the research area chosen. It helps to form the base knowledge about the research domain and also helps in analysis, interpretation and validation of the results. The key areas of the literature review are mentioned below:

• Different development practices used in agile and plan driven methodologies. • Factors of acceptance for adoption of development methodologies.

• Validation of Interviews.

A literature review helped in identifying the list of development practices in agile and plan driven methodologies and different categories of the acceptance factors such as technical, social, organisational factors. This served as an input to the survey. Different plan driven and agile development methodologies, theoretical models of acceptance, cultural theories and mapping between acceptance factors and cultural dimensions have been presented in the background and related work (Chapter 2). The literature review also used to support the results from interviews. The detailed process of literature review is given in the Appendix A (refer to Section A).

3.3 Method Selection

Commonly used methods in software engineering research are controlled experiments, surveys, case studies, action research and simulation[92]. From these methods survey was found to be the most suitable method in order to fulfill the research objectives and answer the research questions formulated to address the research objectives [92]. The motivation and reasons for the choice of the method are given below:

Case Study: It is defined as "an observational request that explores a contemporary wonder inside of its genuine connection; when the limits in the middle of marvel and setting are not unmis-takably obvious; and in which numerous sources of proofs are used" [93]. They have units of analysis and a well defined process of data collection and analysis. They use source triangula-tion and multiple methods of data collectriangula-tion. Case studies focus on “investigating contemporary phenomena in their context”, they have a specific problem area pertaining to an organisation or group of individuals and involves an in-depth investigation of the phenomenon focusing on a specific research area or problem [94]. As the objectives of the research focus on development practices in different organisations located in different geographical locations. By studying two units of analysis, one organisation from Sweden and one organisation from India, would limit the generalisability to a larger degree (access to wider range of organisations is limited). In this particular phenomenon case study is eliminated.

(32)

Chapter 3. Research Method 21 on another in a controlled environment" [95]. The variables are divided into independent and dependent variables [96]. The variables other than the independent variables should not effect the experimental setup [96]. Primary objective of the research is to observe the differences across variables (development practices and acceptance factors) between different organisations (India and Sweden) and investigate the reasons and consequences of differences in an uncontrolled set-ting. Hence experiment based controlled setting has been eliminated.

Action Research: The goal of action research is to "introduce an intervention to the existing system and observe the cause and effect relationship" [97]. The objective of the research is not generation of an intervention, as we are not introducing any new development practices in organisation rather we gather data about the existing practices (frequency) and the factors of acceptance for adoption (agree-ability). Hence action research is inappropriate.

Survey: The term "survey" is defined as the selection of relatively large sample of people from pre-determined population, followed by collection of data from individuals [98]. The research produces data based on the real world observations. As the data is collected from wider range of population it is more generalizable. "A survey is considered to be a feasible means of providing data for any study investigating the state of practice" [99]. As this study involves capturing the state - of - practice of usage of development practices and acceptance factors, across organisa-tions in India and Sweden, it is possible to derive conclusions from wider range of population (characteristic population under study) and portray the current state of development practices and acceptance factors. Therefore survey has been chosen.

3.4 Implementation of Survey

The survey was conducted by following the guidelines given by Sardar Muhammad Sulaman and Rafael Maiani De Millo [100]. The different steps and the process has been described in this section. The target population, sample space, instrument that been used for survey, how it is designed and validated are discussed. Finally, how the results are analysed and validated are explained. The flow of events of the survey process have been represented in the Figure 3.2.

3.4.1 Research Objectives

The research objectives are listed below:

• To find the differences in usage frequency of development practices across organisations in India and Sweden.

• To find differences in acceptance factors across organisations in India and Sweden. • To find out the reasons for existence of such differences and consequences of such differences,

while collaborating between organisations located in India and Sweden.

3.4.2 Survey Objectives

The survey objectives serve as a base to fulfill the research objectives. The objectives of the survey as specified as follows:

• To find state of practice of development practices across organisations in India and Sweden. • To find the agree-ability of acceptance factors across organisations in India and Sweden.

(33)

Table 3.2: Units of analysis Target Audience Units of analysis Units of

observa-tion Search Unit andSampling Software profes-sionals working in software organisa-tions. Software organ-isations/ indus-try/companies located in India and Sweden Software pro-fessionals from software industries, India and Sweden

List of software or-ganisations located in India and Swe-den from personal contacts and super-visor contacts.

3.4.3 Identification of the Target Audiences

Target Audience

Target audience is a group of people to whom the survey is targeted or to whom the survey is applicable [101] [100]. In this context the research is aimed at software organisations, which are located in two different geographic locations, namely India and Sweden. The organisations located in both countries were identified for the survey. Different software professionals working across software organisations have been selected. Software professionals with varied roles such as project managers, developers, business analysts, software engineers are targeted.

Population

A population consists of set of accessible elements from the target audience, which represents the target audience [101]. In this context the population, which represents the software organisations are the software professionals who work in the software organisations across India and Sweden, as specified above (Target audiences).

Units of Analysis

In case of surveys, data is always collected from individuals these are called as primary objects or units of observation [100]. The next higher level to units of observation is the units of analysis, where the units of observation is a subset. The units of observation and units of analysis has been given in the Table 3.2.

Sampling Frame

Sampling frame is a source from which a subset of target audience is retrieved [100]. The establishment of the sampling frame is a choice of the researcher. The sampling frame has the following characteristics:

• Definite number of units (software professionals) were identified. • All Identified units fall under the target audiences.

3.4.4 Design of the Sample plan

"A valid sample is a representative sample of the target population" [101]. According to kitchen-ham, sampling strategies are sorted into two types, probabilistic sampling and non-probabilistic sampling [101]. In Probabilistic sampling, all the units from sampling frame must have the same

(34)

Chapter 3. Research Method 23 probability to be selected. In non-probabilistic sampling, respondents are picked on the basis of availability or based on the trust on the sample population. This kind of sampling includes, snowball, convenient, quota and focus group. In this context non-probabilistic convenient sam-pling was chosen. This involved "getting responses from the individuals who are willing and are available" [101]. Snowballing sampling was also used where some personal contacts have rec-ommended other subjects who were verified (if they fall in target audiences) and contacted via professional platforms such as Linked-In and e-mail [102].

The list of organisations from India and Sweden was sorted as per the availability of contacts from organisations. The contacts from different software organisations located in India and Sweden was obtained with the help of the supervisor and network of the author. The author/researcher belongs to India, therefore it was possible to get data from organisations located in India. As the research is carried in Sweden, it was possible to collect data from organisations in Sweden as well, in an efficient manner.

3.4.5 Design of the Survey Questionnaire

The survey questionnaire consisted of three different sections. The details of the questions and relevance to the research questions is given below.

• Demographic details: This section consisted of 13 questions, it included optional ques-tions pertaining to the personal information; domain (20 domains), primary role in the organisation (11 roles), experience in software industry; location of the organisation and collaborating organisations (Country name) type of sourcing and location of sourcing were asked to find out the global sourcing strategies adopted in the organisation.

• Development Practices and Acceptance Factors: This section consisted of 4 questions, first question was about the development process/methodology adopted in the organisation (such as agile, plan driven or hybrid) (his maps to RQ.1.a), second question was related to description of the development process used in the organisation (this maps to RQ.1.a), third question consisted of 21 development practices (both agile and plan driven), third question was composed of 20 factors of acceptance factors from different theoretical model of acceptance and cultural theories. (this maps to RQ.1.b).

• Organisational Acceptance factors: This consisted set of questions, to measure the organisa-tional acceptance factors (4) (this maps to RQ.1.b) and other (4) to get general information about the organisation.

The list of development practices (21) have been taken from the literature. The acceptance factors (24) have been taken from different acceptance models by making a construct mapping of all the models (analysing the common factors from models literature studies on acceptance factors), detailed mapping of these factors to the different theoretical models has been given in Appendix D (Table D.2, Table D.3 and Table D.1). The survey questionnaire is attached in Appendix B (refer to Section D.2).

3.4.6 Validation of Survey Instrument

Validation of the survey instrument was carried out to test the understandability and clarity of the questionnaire, this was done in three different steps, they are described below [100].

Expert Review

Two types of expert reviews were carried out during process of validating the instrument, design expert review, this was done to make sure that, the questionnaire is designed according to the

(35)

best practices in the survey research [100]. The next part was subject matter expert review this was done to check the wordings, understandability of the questionnaire. Initial reviews were taken from the supervisor regarding the structure, technical details and grammar of the questions. After few iterations the questionnaire was sent to an industrial expert (project manager) with 16 years of experience with software industry and 6 years of experience with global projects. This helped in aligning the survey instrumentation to the main survey objectives. After the review was taken, the questionnaire was slightly modified with the support the supervisor according to suggestions given by the industrial expert.

Focus Groups

A focus group of 5 people was used to evaluate the questionnaire, different opinions and sug-gestions were taken on the subject matter, understandability and clarity. Few sugsug-gestions were given on the number of sections and length of the questionnaire and order of the questions. The questionnaire was slightly modified and was shown to the supervisor for final review. Focus group was also used to check the time taken to answer the questionnaire. The average time taken to answer the questionnaire was 18 minutes.

Pilot Study

A small number of people from the respondents were taken to answer the survey questionnaire. After obtaining the results the consistency of the results were checked. This was followed by a telephonic conversation with respondent to collect the feedback of the questionnaire. This feedback was discussed with the supervisor and finally the questionnaire was ready to be broad-casted within the sample space.

3.4.7 Data Collection Process

After the questionnaire was finalised it was sent to different organisations, through personalised contacts across India and Sweden. The on-line questionnaire was prepared using the Google forms (Appendix B refer to Section B). The questionnaire was sent via electronic mail to the contacts working in different organisations. The link of the questionnaire was mailed; it also had an ancillary document, introductory message and thanking note. The link was also sent via social networking sites (FaceBook and Linked-In) and messenger (WhatsAppWeb) to personal contacts of the researcher. The survey was scheduled for a span of 30 days from 5 th of May 2016 to 5 th of June 2016. Due to availability of personal contacts across Sweden and India it was possible to reach organisations and collect responses in span of 30 days. Data from 33 organisations was collected. The responses were collected in spreed-sheets and separated by geographic location (India and Sweden).

3.4.8 Consistency of Survey Data

To check the consistency of the data, the questionnaire consisted of questions which were similar to each other (asked in different way, but measure the same phenomenon) . The answers to these questions were compared for each respondent. For example in case of acceptance factors, supervisor role and power distance factor should be consistent, questions related to complexity and ease of use should be aligned. The questions were placed in different order to check the consistency of the responses from the respondents. The same was checked across development practices, the organisation, which has higher frequency for documentation has lesser face to face communicationand same with sequential flow of phases and short iterations and releases. After