Catherine Gillo Nilsson and Daniel Karlsson

Implementing Agile project methods in

globally distributed teams

Project Management

Master Thesis

Termin: Hösten - 2014

Handledare: Tomas Gustavsson

iii

iv

Abstract

The objective of the study was to generate a ‘theory’/ ‘hypothesis’ on the important

factors to focus on in implementing agile project methods in globally distributed teams.

Using the grounded theory method, five key categories emerged from the so-called

theoretical sampling, which entails the joint collection of data, coding and analysis. The

study involved 33 individuals in four different companies, three in the Philippines and

one in Sweden. The data collected for this thesis consisted of individual interviews in the

Philippines and Sweden (Sept-Dec 2014), focus group sessions, observations of formal

agile practices and experiences in the substantive area, conducted in the Philippines

during the period Sept-Nov 2014. The following five key categories emerged as the main

concerns of the individuals involved in implementing agile project methods in globally

distributed teams in software development projects: (i) Working Communication, (ii)

Self-organizing Teams, (iii) People-centric organization, (iv) Continuous Learning and

(v) Sustaining Infrastructure. The respondents meant that these concerns should be

addressed and resolved in such a way that the implementation of Agile project methods

would resemble the case of a collocated Agile project team. The key categories, their

fundamental characteristics and the subconcepts behind them were presented and

analyzed in relation to the empirical data. The analysis included reported incidents and

direct citations from the respondents, focus groups and from observations during the field

study, in order to shed light on the process used to arrive to the categories, as well as

explain the characteristics of the concepts in the emerging ‘grounded hypothesis’.

Keywords: Implementation, Agile methods, Agile software development, Globally

distributed teams

v

Sammanfattning

Syftet med denna studie var att generera en “teori” / “hypotes” om de viktiga faktorer

som man ska fokusera på när man implementerar agila projektmetoder i globalt

distribuerade team. Genom att använda sig av ‘grundad teori’ som metod, uppstod fem

huvudkategorier från det så kallade teoretiska urvalet, som innebär att insamlingen av

data, kodningen och analysen gick hand i hand. Studien involverade 33 individer i fyra

olika företag, tre på Filippinerna och ett i Sverige. Data som har samlats in i denna

uppsats består av individuella intervjuer i Filippinerna och i Sverige (Sept-Dec 2014)

samt fokusgruppsessioner, observationer och erfarenheter i fältet, vilka utfördes under en

8 veckors period (Sept-Nov 2014) i Filippinerna. Följande fem kategorier framstod som

huvudfråga för de individer som är involverade i implementering av Agila projektmetoder

i mjukvaru-utvecklingsprojekt med globalt distribuerade teams: (i) Fungerande

kommunikation, (ii) Självorganiserande teams, (iii) Människo-centrerad organisation (iv)

Kontinuerligt lärande och (v) Stödjande Infrastruktur. Respondenterna framhävde att

dessa frågor ska adresseras och lösas på ett sådant sätt att implementeringen av Agila

projektmetoder liknar fallet med ett samlokaliserat agilt projektteam. Huvudkategorierna,

deras fundamentala egenskaper och de underliggande koncepten i varje kategori är

presenterade och analyserade i relation till den empiriska datan. Analysen inkluderar

rapporterade incidenter och direkta citat från respondenterna, fokusgrupper, observationer

och erfarenheter i fältet, för att beskriva processen som genomfördes för att komma fram

till kategorierna, samt att förklara deras innebörd i den framkomna ’grundade hypotesen’.

Acknowledgements

We wish to acknowledge the people that have made it possible for us to write and

complete this Master thesis. A special thanks to our supervisor Tomas Gustavsson who

actually was the first person to introduce to us the realm of Agile methods at Karlstad

University. Through meaningful meetings and insightful advices, he has guided us

through this Master thesis. We want to acknowledge the four companies that provided us

with the unique opportunity to do the field research, interviews, and observations. To all

the respondents in the Philippines and Sweden, who gave us their valuable time and

showed great openness and willingness to contribute with data, we extend our warmest

appreciation and gratitude. We are also grateful to Sida and the Minor Field Study (MFS)

scholarship programme that has made it financially possible to do the field study in the

Philippines. Moreover, we want to seize this opportunity to thank Dr. R. Sison of De La

Salle University for sharing with us his reflections and experiences as a Grounded

Theorist and to our ‘anonymous’ contact person in the Philippines for his practical

assistance during the field study. Maraming salamat! Tack så mycket!

Finally, our heartfelt thanks to our families that have supported us all the way and

encouraged us so that we could find the time and the stamina to work on this great

endeavour. We therefore dedicate this work to Maria, Theo and Staffan. Thank you so

much!

Catherine and Daniel

January, 2015

2

Table of contents

1 Introduction ................................................................................................ 5

1.1 Background ............................................................................................................ 5

1.2 Problem discussion ................................................................................................ 7

1.3 Main research question ........................................................................................ 10

1.4 Objectives and delimitations ................................................................................ 11

2 Theory ....................................................................................................... 13

2.1 Agile Software Development ............................................................................... 13

2.1.1 Understanding Agile software development. ................................................... 13

2.1.2 Agile method family ........................................................................................ 15

2.1.3 The concept of Critical Success Factors (CSF) ............................................... 20

2.1.4 Agile Practices and Trust ................................................................................ 22

2.2 Distributed Teams ................................................................................................ 23

2.2.1 The concept of Distributed Software Development ....................................... 23

2.2.2 Distributed Project Teams ................................................................................ 23

2.2.3 Globally distributed software development and Quality:................................. 25

2.3 Distributed Agile Software Development ............................................................ 26

2.3.1 Potential Problems in GSD .............................................................................. 26

2.3.2 Challenges and Mitigation mechanisms in Agile DSD ................................... 27

2.3.3 Benefits of implementing Agile methods to globally distributed teams .......... 30

2.4 Implementation .................................................................................................... 31

2.4.1 Assimilation theories………………………………………………………….28

3 Method ...................................................................................................... 33

3.1 Introduction to Grounded Theory: ground and discovery .................................. 33

3.2 The constant comparative method and the study’s research process ................... 35

3.3 Credibility of GroundedTheory, Validity and Reliability .................................... 37

3.4 Integrated processes: the Data collection and Analysis. ..................................... 38

4 Empirical Study ........................................................................................ 44

5 Analysis .................................................................................................... 46

5.1 Working communication ..................................................................................... 46

5.2 Self-organizing Teams ......................................................................................... 50

5.3 A People-centric Organization ............................................................................. 56

5.4 Continuous Learning ........................................................................................... 58

3

5.5 Sustaining Infrastructure ...................................................................................... 60

6 Discussion ................................................................................................ 63

7 Conclusions.............................................................................................. 65

8 References ................................................................................................ 69

4

List of Figures

Figure 1 Shows Conboy's concept development scheme [17] .................... 14

Figure 2. Scrum process p 66 [25] ................................................................. 16

Figure 3. Scrum artifacts p14 [25] .................................................................. 18

Figure 4. Potential Critical Success Factors ................................................ 20

Figure 5. Challenges and mitigation factors [31] p28 ................................... 27

Figure 6. Examples of the initial open coding ............................................... 35

Figure 7. Example of grouping initial codes into a first level concept ........ 36

Figure 8. Example of grouping the 'first level concepts' to a key category 36

Figure 9. Respondent and company description .......................................... 45

Figure 10. Working communication ............................................................... 47

Figure 11. Self-organizing teams ................................................................... 53

Figure 12. People-centric Organization ......................................................... 56

Figure 13. Continuous learning ...................................................................... 59

Figure 14. Sustaining infrastructure .............................................................. 60

Figure 15. Matrix of category and concepts linked to open coding of

respondents. .................................................................................................... 73

5

1 Introduction

The signing of the Agile Manifesto (Agile Alliance, 2014) in 2001 brought about

significant transformations in the field of software engineering and project management.

The manifesto itself “evolved from personal experiences and collective wisdom” of 17

software community “thought leaders” (Dingsør, T.,Nerur, S.,Balijepally,V. &

Moe,D.,2012). Although there were critics and sceptics, the agile principles and

methodologies spread rapidly and were accepted by both researchers and practitioners, by

the academia as well as companies. The increase in its popularity can be seen in the

extensive number of publications (e.g. scientific journals, thesis, conference papers) in the

subject in the past decade. A ‘scholar Google’ literature search (2014-03-08) on ‘Agile

software development’ resulted in 113000 hits with publications, articles and citations

from different parts of the globe. Papers and research articles have been presented

annually at two international Agile conferences: the International Conference on Agile

Software Development and Agile, based in Europe and the US respectively. And this is

setting aside the other top conferences and conventions on various scientific domains and

communities (Dingsør et al. 2012), e.g. software development, software engineering,

project management, systems architecture.

One of the core principles in the agile manifesto reflects the importance of individuals,

collaboration and interaction over processes and tools. However the beginning of the 21st

century has also seen the accelerating pace of globalization affecting organizations and

working environments. The process of globalization now challenges many companies,

which have embraced and adopted agile principles and methodologies, to reconcile agility

with global distribution. In order to describe the status of research in this area, Jalili, S.

and Wohlin, C. published in 2011 a systematic review of 81 peer-reviewed research

papers dealing with combining agile methods and global software engineering. They

concluded that there was not sufficient research that provides analysis of the challenges of

applying agile methods in global software engineering (Jalili,S. & Wohlin,C., 2010).

This thesis will therefore investigate further agile methods applied to globally distributed

teams. The focus will be on the three key concepts namely implementation, agile

methods and distribution. By utilizing the theoretical framework of these three concepts

and empirical study of four companies (one in Sweden and three in the Philippines), that

has implemented agile methods to globally distributed teams for a significant period of

time, this thesis aims to take a step in generating a theory on the important factors to

focus on when implementing agile project methods in globally distributed teams.

1.1 Background

In the beginning of the 1990s Roland Gareis introduced the concept “new project-

oriented company” (Gareis,R., 1990), describing organization where projects and project

management are very much a part of everyday processes for both employees and

employers, a rule instead of an exemption in the company’s core activities. The

increasing number of projects to be led and managed in an organization has implications

on amongst others the organization’s management and leadership, human resources’

structures and competencies as well as the organizational content and working cultures.

6

R. Gareis (1990) asserted that the main implications of integrating numerous projects into

the core business of the organization concerned an effective adaptation and interaction

between the existing organizational structure and the project management structure (ibid).

This means accepting a high level of uncertainty and complexity in roles and

responsibilities as well as coordination, planning and staffing. It also entails putting in

place major strategic decisions and mechanisms. The key concepts in this thesis are

closely woven together in this type of companies. Organization development,

implementation processes of the chosen project models and methodologies and the

impact of the growing global market situates the focus of this thesis in the very heart of

many project-oriented companies.

Organization development practice dated back in the 50s. A scan of organization

development as practice and research field during the second part of the 20th century

reveals a diversity of processes and approaches, with focus on implementing planned

change and organizational effectiveness, on the set of values that should inform the

organizational goals and the methods to reach them (Gallos,J., 2006). The Agile

manifesto and the introduction of agile methodologies in many project-oriented

companies explicitly connected the field of project management to the field of

organization development, from traditional organizations to agile organizations.

While these historical events were unfolding during the turn of the century, companies

were experiencing globalized market trends, amongst others, in terms of information and

skills, knowledge and technology. Many companies have engaged in offshore outsourcing

and/or offshoring with offices, units and staff scattered around the globe. Organization

leaders and managers are therefore in the present time confronted with the challenges of

integrating virtual organization units and geographically distributed teams into

meaningful wholes.

R. Sison et al. (2006) noted the lack of research in the area of software development

practices in Southeast Asia, which is a fast-growing offshoring destination for many

European and North American companies (Sison, R., Jarzabek,S.,Hock,O.S.,

Rivepiboon,W.& Hai, N.N.,2006). This is the case in spite of the fact that four of the top

six countries delivering offshore services were Southeast Asian (Malaysia, Philippines,

Singapore, Thailand) according to AT Kearney’s Global Services Location Index for

2005. In one of the companies in the empirical study in this research, we explore agile

project management practices in a firm headquartered in Europe with offices in Southeast

Asia. Unlike most of the global surveys on software development practices, this

research’s respondents will be mainly from the Asian office. Furthermore, Sison, R. et al

concluded with recommendations for future research, and stated the need for “more case

studies on successful use of agile methods on software development offshore, including

Association of Southeast Asian Nations” (ibid), consisting of the following countries:

Indonesia, Malaysia, Philippines, Thailand, Singapore, Brunei, Cambodia, Laos, Burma

and Vietnam.

Through both theoretical analysis and empirical case studies involving implementation,

agile project methods and globally distributed teams, this research will conceptualize the

relationship between these concepts and draw conclusions to contribute to generating a

theory on the important factors to focus on, in the context of implementation of agile

project methods in globally distributed teams.

7

1.2 Problem discussion

“Facilitating change is more effective than attempting to prevent it. Learn to trust in your ability to respond

to unpredictable events; it's more important than trusting in your ability to plan for disaster.”

-M. Fowler, J. Highsmith, 2 Signatories to Agile manifesto

The above quote captures the essence of agility and agile processes which are central

concepts in this thesis. It is about “trusting one’s ability to respond to unpredictable

events more than trusting in one's ability to plan ahead for them” (Agile Alliance, 2014).

Moreover, it is about designing and implementing practices based on the agile manifesto.

The Agile manifesto: purpose, values and principles defined the processes and methods

that could be labelled as agile. Some examples of well-known agile project methods are

Scrum, XP (Extreme programming) and DSDM (Dynamic systems development

method).

The Agile manifesto (ibid.) stated the following purpose:

"We are uncovering better ways of developing software by doing it and helping others do

it. We value:

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan."

This declaration of purpose is supported by twelve specific principles. The purpose and

principles in the Agile manifesto have caused a number of difficulties in implementation

processes. One of these difficulties is that it requires a new mindset and ability in

organization development and project management.

Early researches in the area of agile project methodologies revolve around adoption

issues, different aspects of group dynamics and post-adoption issues (Dingsør et al.,

2012). Another major research topic in this area is about the question of formally

defining, explaining and understanding the concept of agility and the application of its

principles to project management. There have been extensive debates on the gap between

agility and the chosen practices that were supposed to reflect the agile principles (ibid.).

Efforts from both theorists and practitioners are still very much needed to bring about

agreements and unity in the present discourse on agility.

Another research focus in the area of agile methods and development is to understand

theoretically its distinct characteristics compared to ‘traditional’ project management.

Implementing agile methodologies normally entails an organization development process

from traditional project management approaches to agile methodologies. “Traditional”

project management (e.g. Waterfall model) assumes that “events affecting the project are

predictable and that tools and activities are well understood” (Hass, K., 2007). A

traditional method has a sequential flow while Agile methods have iterative and

incremental processes (ibid.). Moreover, the agile project methods rely on self-organized

teams that could respond to change in project requirements at any stage of the

8

development process (Dingsør et al., 2012). This means that the organization structure

and environment is assumed to be conducive to support agile teams in creative and

productive problem solving processes. Important factors to focus on in implementing

agile project methods in an organization are thus interconnected to the important factors

for a successful organization development and change. Any significant increase in the

number of agile projects in an organization will definitely need a new mindset and

working culture, not only in project-based processes but in the entire organization.

Explaining and comprehending agile methodologies and its practices need a point of

departure, a theoretical perspective or perspectives. One of “the most comprehensive

definition of agility” (Dingsør et al., 2012) in the context of software development was

formulated by K. Conboy (2009). He was able to provide connections, show similarities

and differences between related terms (e.g. leanness) as well as go beyond them.

Dingsøyr et al. (2010) published a book that contains an overview of mainstream research

in agile development. A survey and analysis of the topics of 452 research publications on

agile development between 2001-2010 through ISI’s Web of Science revealed a wide-

range of theoretical approaches with keywords such as knowledge management (9),

personality theories (6), organization learning (1), complex adaptive systems (2), social

facilitation (2), chaos theory (1), complexity theory (1), distributed cognition (1), graph

theory (1), game theory (1) (Dingsør et al., 2012). This clearly shows the multi-

disciplinary and multifaceted theoretical underpinnings of agile methodologies and

implementation practices. Most relevant to this thesis is the fact that the majority of the

research studies in agile development did not seem to consider any theoretical

underpinnings, which strengthens the “perception that agile research is a-theoretical”

(ibid.).

Agile and Distribution: One of the key elements and basis for Agile project management

and agile development is co-located high performing teams (which includes

customers/users) for the purpose of increasing the quality of interaction, coordination,

and communication (Hass, K.,2007). This again is a premise that makes agile

implementation practices challenging when distribution is a parameter to consider. Sharp

and Robinson (2006; 2008; 2009) presented studies in this area. These studies focused on

the issues of distributed cognition, the role of physical artifacts and perspectives on

interaction through technology. Since distribution poses challenges in the context of

agile development and methods, there is a need to explore distribution as a parameter

when implementing agile methods. The systematic review of a decade of agile

methodologies showed an urgent need to study distribution involving “mature” agile

project teams, instead of projects where agile methods have just been introduced (Dingsør

et al., 2012).

The concept of ‘distributed teams’ and ‘distribution’ means introducing a concept of

“distance” in the equation. A quick review of the search results involving ‘distributed

teams’ in software development showed distribution in three dimensions: temporal,

geographical and socio-cultural. Prikladnicki, Audy and Evaristo (2003) proposed criteria

for measuring different degrees of distribution between project team, customer and user.

They provided a model for understanding and defining the level of distribution in this

context. Among the criteria mentioned and analyzed in their study were physical distance

between the actors, cultural differences, distribution of project teams, project size and

development outsourcing (Prikladnicki et al., 2003). The researchers above defined DSD

9

(distributed software development) as “a software development process where at least one

of the actors (project team, customer or user) is physically distant from the others”. In

their study they identified that the physical distance between the actors and the

distribution of project development team are the two criteria that are important to

consider in characterizing the distributed development environment. Jalili, S. and Wohlin,

C. (2010) noted that many research studies in the past decades were unclear in their

definition and description of the specific environment and context of distribution (Jalili,S.

& Wohlin, C., 2010). More clarity and specification in this regard would contribute to

making the results more useful to future research and other practitioners in the area.

Distributed teams, experiencing large physical distance between the actors, cultural and

time zone differences, face various challenges and difficulties. Some categories that are

presented in research are (i) strategic issues (e.g. decision making), (ii) cultural issues

(e.g. ethics, team culture), (iii) inadequate communication (iv) knowledge management,

(v) project and process management issues, (vi) technical issues, and (vii) risk

management issues (e.g. risk identification, coordination) (Shrivastava, S.V. & Date, H.,

2010). In 2001, a group of top researchers in software development were asked if it would

be possible to have an agile development when the team is globally distributed. A

unanimous verdict of “we wouldn’t even try” was heard (Prikladnicki, et al., 2003). Five

years later, Ramesh et al. asked the question “can distributed software development be

agile” and studied distributed agile software development in three large companies. The

research gave an affirmative answer and recommendations on how to balance “agility”

and “distribution” in practice by mapping challenges with practices (Ramesh, B.,Cao, L.,

Mohan, K.,& Xu, P., 2006). In 2010 (four years after Ramesh’ paper), Shrivastava, S. V.

& Date, H. published a review of distributed agile software development with a new

perspective by shifting the focus to the benefits of combining agile with distributed

software development (Shrivastava & Date, 2010).

Implementation + Agile methods + distributed teams: Reviewing the theoretical and

empirical results in the past decade opens new areas and issues to explore in the domains

of implementation of agile methods in distributed teams. Some of the issues that were

brought out concerns comprehending the core ideas of agile methodologies, explaining

the distinct characteristics of agile methods compared to traditional project methods,

establishing compatibility between principles and practices, and exploring challenges as

well as benefits of combining agile methodologies and globally distributed teams.

Another critical problem in the analysis of research in the area of implementation of agile

methods in global software engineering is connected to the numerous types of modified

versions of agile project methods, or tailored combination of different types of methods

(Jalili; S. & Wohlin, C.,2010), both traditional and agile. The process of adoption,

adaptation and changes made in agile methods resulted in varying degrees of agility in the

resulting project methods.

10

1.3 Main research question

By using the Agile Manifesto’s purpose and value statements (Agile Alliance, 2014) as a

frame of reference, we explore briefly the issues that could arise when these values and

principles are challenged by large geographical distances between the actors.

Individuals and interactions over processes and tools.

Processes and tools are important in project management and even more when the actors

are globally distributed. Organization and coordination in teams often require certain

tools and a set of well-planned processes. However the agile manifesto stated that the

interaction between competent individuals is more important.

Working software over comprehensive documentation.

Documentation plays an important role in projects especially in terms of knowledge

transfer and learning within and after the project life cycle. However, from the agile

manifesto’s perspective, the ultimate goal is delivering a valuable end product that meets

the requirements of the customer. The manifesto statement does not imply that

documentation is not important but rather ask the actors to reflect on the degree of the

documentation’s comprehensiveness and its relation to the end product.

Customer collaboration over contract negotiation.

Contracts, like documentation, also have a critical role in projects especially when the

actors are globally distributed. One aspect of the global scenario that is most relevant here

pertains to cultural differences. To guarantee that all parties know and understand the

working terms and conditions, negotiations normally take place, the terms are formulated

as a written agreement and contracts are drawn. However, the value statement in the agile

manifesto claims that customer collaboration is more important than contract negotiation.

Collaboration as opposed to the word negotiation points towards the idea of a ‘win-win’

solution rather than a competitive situation where winning means the other party losing.

Responding to change over following a plan.

On one hand, planning the processes involved in the project life cycle is crucial in project

management especially if the team is globally distributed. On the other hand, change is a

factor that is continuously present in the same time-span. How do we deal with change as

well as follow a carefully designated plan? The Agile manifesto stated that we don’t.

Responding to change is prioritized over following a plan. There is no compromise or

negotiations in this regard, the answer is to use the ability of individuals to collaborate

effectively and respond to the change that is happening.

The above discussion reflects the challenges in adopting and implementing Agile

methods to distributed teams. The global scenario as well as the lack of unity in the

discourse on agility and agile practices makes this undertaking even more difficult and

complex.

This thesis therefore aims to contribute to a conceptual and practical understanding of

agile implementation to distributed teams by determining important issues for the

individuals who are involved in the process. Merging the problems of a distributed team

in agile projects with the challenges in implementing agile practices results in this thesis’

main research question:

11

What are the important factors to focus on in implementing agile project methods in

globally distributed teams?

1.4 Objectives and delimitations

The objectives of this research are:

i. to explore and analyze the implementation of agile project methods to globally

distributed teams

ii. to provide a practical understanding of the concept of globally distributed agile

teams.

iii. to contribute in generating a “theory”/ hypothesis on important factors to focus

on when implementing agile project methods in globally distributed teams

iv. to suggest constructive guidelines/framework to future adopters of agile project

methods in globally distributed teams

To clearly set the focus and narrow the problem field, the following delimitations are set

for this research:

i. The empirical research will be focused on agile project methods although

comparisons to traditional project methods based on existing research will be a

part of the analysis.

ii. The case studies, analysis and discussions are only relevant for globally

distributed teams and Distributed Software Development (DSD) environment.

Globally distributed teams are defined in this research as teams with members

that are located across the globe (in at least two different continents).

iii. The factors studied and concluded are limited to the adoption process of Agile

practices.

iv. The main focus of the study will be on the globally distributed agile team.

v. Recommendations for further studies and practices are based on ‘mature’

companies that have utilized agile practices in DSD. ‘Mature’ project companies

in this context are companies that have implemented agile project methods for at

least a year.

vi. The study does not evaluate or take into consideration the outcome of the

implemented Agile method in terms of project success.

13

2 Theory

2.1 Agile Software Development

2.1.1 Understanding Agile software development.

According to Merriam-Webster dictionary (Merriam Webster, 2014), the word agile is

an adjective which means “able to move quickly and easily” or “having a quick

resourceful and adaptable character” as opposed to “uncoordinated, rigid, stiff”. Using

the word agile to describe software development could therefore mean a process with

resourceful and adaptable character. It highlights the ability of being ready to adapt and

move easily. However, trying to gain a conceptual understanding of agility and finding

measures in order to compare varying degrees of agility in different software

development environment proves to be a complicated task. The Agile alliance 2001

agreed on a notion of agility in software development through a set of values and guiding

principles (Agile alliance, 2014) for software development activities and practices. Since

then, ‘agile methods’ have been promoted and implemented by practitioners around the

world. However, the concept of agility still poses challenges for its application into

different fields other than software development. Implementations to large development

teams and to distributed software development were also affected by the limited academic

research in this area. Since the focus of this thesis is on implementing agile project

methods in globally distributed teams, it is imperative to take a closer look at existing

conceptual researches on the concept of agility and on theories regarding agile methods as

a point of departure.

As mentioned earlier, K. Conboy (2009) made a thorough study and attempt to

reconstruct the concept of agility in Information Systems Development (ISD) (Conboy,

K., 2009). He reviewed systematically different literature about agility in various

disciplines in order to develop a definition and classification of agility that could be

applied when studying agile methods in practice. In this context, method was defined as

“the complete range of practices involved in the process of designing, building,

implementing and maintaining an information system, how these activities are

accomplished and managed, the sequence and frequency of these activities, as well as the

values and goals of all of the above.” (Gareis, 1990) p329

In his study, Conboy chose to adopt the concept of method as “an idea and enactment, as

opposed to a rigorous prescription” [ibid]. Furthermore, the study also applied the so-

called “first principle approach” which means that in order to develop a definition and a

conceptual understanding of agility, it is important to analyze the basic concepts behind

agility, which are leanness and flexibility (Conboy, K., 2009). By mapping the three

concepts (agility, flexibility and leanness) as well as 13 subconcepts against a total of 195

literature, Conboy could compare the components of agility with that of flexibility and

leanness respectively.

14

Figure 1 Shows Conboy's concept development scheme (Conboy, K., 2009)

This approach led to Conboy’s final definition of ISD method agility which states:

“the continual readiness of an ISD method to rapidly or inherently

create change, proactively or reactively embrace change, and

learn from change

while contributing to perceived customer value (economy, quality,

and simplicity),

through its collective components and relationships with its

environment.” (Conboy, K., 2009) p340

The first part of the definition suggests the four ways in which a practice can contribute to

agility when change is a fundamental part of the development process. These four ways

stated in the definition have much to do with the characteristic of being ‘flexible’ in

relation to the change that occurs. The second part poses a condition that there should be

a “perceived customer value” in at least one of three specific aspects without jeopardizing

the others. This second part has a clear connection to ‘leanness’, where added customer

value in terms of quality is achieved by eliminating waste. The same idea was also

expressed by Eriksson, Lyytinen & Siau (2005) as:

“agility means to strip away as much of the heaviness, commonly associated with the

traditional software-development methodologies, as possible to promote quick response

to changing environments, changes in requirements…” (Eriksson et al., 2005)

The final part of the above definition stresses the requirement that all the method’s

components collectively support and strengthen the ability to easily respond to change.

Abrahamsson,P., Salo, O., Ronkainen, J. & Warsta, J. (2002) published one of the first

reviews on agile software development methodologies based on existing literature at that

time. He stated that the core aspects of agile methods are “simplicity and speed” which

Conboy also expressed by choosing to include “rapidly or inherently” in the definition of

Flexibility Leanness

Agility vs Flexibility

Agility vs Leanness

Agility in ISD

15

agility in ISD. Subsequently, Abrahamsson, P. et al. (2002) proposed that to be

considered agile, a software development should be “incremental, cooperative,

straightforward and adaptive” (Abrahamsson, P. et al. 2002). In both definitions above,

change and readiness to respond to change are important parameters in the agile software

development project method as opposed to the traditional plan-based methods where

changes in requirements and specifications can be seen as problematic once the software

development has started.

“…With the Waterfall approach, a great idea late in the release cycle is not a gift, it’s a

threat. “ (Sutherland, 2012) p12

In this regard, the incremental and short cycles, the collaboration between customers and

developers, simplicity of rules and straightforward processes are all essential elements in

the agile software development project method.

Agile software development is a collaborative problem solving task. In its core is a group

of participants, namely the agile software development team that is highly self-organizing

and performing. Alistair Cockburn, an agile manifesto signatory called it “the

cooperative game” and uses the metaphor of a “community writing an epic poem

together” with a given timeframe and cost. (Cockburn,A., 2007) Dybå, T. & Dingsøyr,

T. published in 2008 a systematic review of then existing empirical studies of agile

software development with focus on four themes namely: “introduction and adoption,

human and social factors, perceptions on agile methods and comparative studies” (Dybå

& Dingsør, 2008). The results of this review suggest that it is possible for agile

practitioners and customers to experience increased satisfaction as well as improved

productivity. The studies that were done on mature agile teams pointed towards the

importance of focusing on “human and social factors” to succeed in implementing agile

methods. The individual’s freedom to act, execute task and make decisions should be

balanced by a strong sense of team spirit with shared responsibility and goal. It also

seems that the agile team should be composed of individuals who firmly believed in their

own capabilities to perform the task at hand as well as possess high levels of

“interpersonal skills and trust” (ibid.).

2.1.2 Agile method family

Some examples of agile development methods are Scrum, eXtreme Programming, Crystal

methodologies, Dynamic software development method (DSDM), Feature-driven

development, and Lean software development (Dybå & Dyngsør, 2008). In this section,

we present the concepts and method that were commonly implemented by the companies

in this thesis’ empirical study namely Scrum and the Kanban board concept.

SCRUM

Background: The first Scrum was implemented at Easel Corporation in 1993 by Scrum

creator Jeff Sutherland and co-creator Ken Schwaber. Together they formalized the

Scrum development processes at the OOPSLA (Object-oriented Programming Systems,

Languages and Applications) conference in 1995. The main reasons for adopting Scrum

in software development at Easel were amongst others the uncertainty in the development

processes, unclear and changing requirements as well as the continuous evolution in

technologies and tools. Scrum was inspired by best practices in Japan, where

development was team-based with a set of “simple rules” to strengthen self-organization

16

in order to deliver an evolving system. Sutherland and Schwaber were particularly

influenced by the works of Takeuchi and Nonaka at Hitotsubashi University in Japan

(Sutherland et al., 2007). In 1986, Takeuchi, H. and Nonaka, I. published in Harvard

Business Review, ”The new new product development game” with the headline ”Stop

running the relay race and take up rugby”. Scrum can be compared to rugby, in which a

group of software developers constantly interact and perform as one, “passing the ball

back and forth” in the scrumfield from start to finish. Takeuchi and Nonaka stressed the

importance of speed and flexibility to compete effectively in the global market.

(Takeuchi& Nonaka, 1986)

Agile software development with Scrum: As an extended version of his so-called Spiral

methodology, Barry Boehm introduced the iterative methodology in order to address the

limitations of Waterfall methodology in addressing the issue of how to respond to

unpredicted results during the different development phases. Boehm introduced “risk

assessment and prototyping activity” at the end of each of the Waterfall phases

(Sutherland, J., 2012). The ultimate project deliverable is chopped into “prioritized

subsystems”. Each iteration then consists of all the phases of a traditional waterfall

method, but only focusing on delivering a predefined set of requirements or

functionalities. The main difference between Scrum and the iterative methodology is that

all processes in the iterative methodology are all pre-defined while in Scrum, only the

planning and closure in the iterations are specifically defined. The Sprint in Scrum

remains open and responsive to changes in the requirements as well as in the

environment. In this regard, maximum team flexibility and creativity is a prerequisite.

(ibid.)

K. Schwaber, the co-creator of Scrum, labeled the different groups of phases in Scrum as

Pregame, Game and Postgame (Sutherland, J., 2012). In the diagram below, K. Schwaber

presented the phases involved in each of the group.

Figure 2. Scrum process (Sutherland, 2012)p66

In the Scrum Guide (July 2013), provided by its creator J. Sutherland and K. Schwaber.

Scrum is defined as: “a framework within which people can address complex adaptive

problems, while productively and creatively delivering products of the highest possible

value.” (Sutherland & Schwaber, 2013)

17

The Scrum roles: Scrum applies an iterative and incremental approach to complex

product development process. The productive and creative delivery of products is

performed by a Scrum team with defined roles that are connected together through Scrum

events and artifacts, as well as by a set of simple rules: the Scrum rules. The Scrum team

roles are the self-organizing, cross-functional Scrum development team responsible for

developing and building the product, the Product owner responsible for the Product

Backlog management and the Scrum Master responsible for ensuring that all the members

of the Scrum team understands the Scrum theory and performs according to the Scrum

rules and practices. The Product owner is often the same as the customer. The Scrum

Master is responsible for educating the team members and facilitating the team’s

implementation of Scrum. He/She is often designated as a “servant-leader” because

he/she serves the development team, the product owner and the organization. The Scrum

Master’s task is to clear the ground and help remove obstacles or impediments that could

endanger the team’s effectivity. It is also the Scrum Master’s responsibility to help others

outside the team to understand which interactions with the team can maximize or

decrease the team’s efficiency and productivity. The recommended team size for the

development team is 7 plus minus 2 persons. Too small teams could be limited in the

skills needed to perform the task on their own and too large teams could entail critical

management and coordination challenges. (ibid.)

The Scrum events: The Scrum events are designed with a holistic approach in order to

provide opportunity for adaptation, as well as ensure “transparency and inspection”. The

events are “timeboxed” which means that there is a designated maximum time for each

event. The core Scrum event is the “Sprint” which has a constant duration during the

development process. The Sprint defines an increment wherein prioritized items in the

product backlog are delivered at the end of the increment. A Sprint is time-boxed to a

maximum of four weeks or one calendar month, which is a condition for predictability in

the requirements of what is being developed. The following events are executed during

the Sprint: the sprint planning, the daily scrums, the development work, the sprint review

and the retrospective. (Sutherland & Schwaber, 2013)

The sprint planning is mandatory for everyone in the Scrum team. It is where the Scrum

team defines the deliverable and how they will work to deliver it at the end of the sprint.

The sprint planning is divided into two meetings: the sprint planning part 1 and sprint

planning part 2. In the sprint planning 1, the Product owner and the Development team

go through the high priority items in the Product Backlog that the Product owner wants to

prioritize in the new sprint. This part is about giving the development team an

opportunity to understand what the Product Owner requires. In the sprint planning part 2,

the development team do a detailed planning of the items that they will commit to deliver

at the end of the sprint. The items are taken in the order of priority in the Product

Backlog, beginning with the item with highest priority which is at the top of the list in the

Product backlog. The items are then broken down into “individual tasks” and the team do

a time and effort estimate for each task. A sprint planning meeting lasts for a maximum

of 8 hours for a 4-week sprint. The output of the Sprint planning is the Sprint backlog

which is a set of selected items from the Product backlog that the team commits to deliver

at the end of the sprint and the estimates in time for each item. (Sutherland, J., 2012) It is

not mandatory for the Product Owner to attend the sprint planning part 2. The definition

18

of Done for each item ensures that everyone in the scrum team understands when the item

is completed.

The daily scrum or daily stand-up is a 15-minute ‘timeboxed’ activity wherein each

development team member answers the following three questions:

“What did I do yesterday that help the Development team meet the sprint goal? What will

I do today to help the Development team meet the sprint goal? Do I see any impediment

that would prevent me or the Development team from meeting the sprint goal?”

(Sutherland & Schwaber, 2013)

The daily scrum is used to communicate what is going on, to better coordinate the team’s

efforts and to monitor progress towards meeting the sprint goal. The scrum master

reinforces the rule that the development team should do the daily scrum and only the

development team members participate in the activity. The daily scrum ensures constant

communication within the development team members and identifies impediments that

could prevent the team from meeting the sprint goal. Furthermore, Scrum uses the inspect

and adapt approach. One important event that supports this approach is the so-called

sprint review. The participants in the sprint review are the scrum team and other

stakeholders, who are usually invited by the Product Owner. During the sprint review,

the Product owner presents the items that has been done during the sprint and discusses

its impact on the current Product backlog. The team and stakeholders review the items on

the Product backlog, as well as the time and budget constraints, in order to have an in-

depth discussion and collaborate on the way forward. The result of a sprint review is

often a revised Product backlog that better meets the needs and requirements of the

stakeholders. (Sutherland, J. & Schwaber, K., 2013) After the sprint review, the sprint

retrospective takes place. The Scrum Master facilitates the sprint retrospective. If the

Sprint review is an informal meeting, the sprint retrospective is a formal opportunity for

the team to further inspect and adapt for the next sprint. The objective of the sprint

retrospective is to inspect the different aspects of the last sprint. The team is encouraged

to reflect on what went well and what can be improved in the next sprint. The Scrum

master encouraged the team to identify areas of improvement and what the team can do

about it in the next sprint. (ibid.)

Figure 3. Scrum artifacts (Sutherland, 2012) p14

19

The Scrum artifacts:

The Scrum artifacts are project documents or information that are produced in order to

provide transparency and common grounds for the team. It is important that the team

members understand the artifacts in exactly the same way so they can organize and

manage their work with regards to achieving its goal.

The Product Backlog: The product backlog is a prioritized list of requirements and

features to be delivered or the work that is to be performed to the product so it evolves

towards the client’s vision. Each item in the product backlog is described, prioritized,

estimated and valued. The Product Owner is responsible for the product backlog’s

content and its order of priority as well as updating the product backlog items. The

Development team is responsible to assess an item’s level of complexity and estimate the

effort needed to deliver the item. The product backlog is dynamic in the sense that it

changes as the product evolves. “The product backlog is a living artifact” since it is

influenced by the conditions in the market, the developments in technology and the needs

of the business (Sutherland & Schwaber, 2013).

The Sprint Backlog: The Product Owner discusses with the team/Scrum Master the

objective of the sprint so that the Development Team can select and predict the items that

they can get “Done” within the sprint, where “Done” is defined in relation to the

acceptance criteria agreed upon by the team. This will enable the scrum team to formulate

the Sprint Goal. The Sprint Goal together with the selected items from the Product

Backlog and the detailed plan on how to get the items to Done is called the Sprint

Backlog. The Development Team is exclusively responsible for estimating the number of

items that they can accomplish within the sprint as well as to explain how it proposes to

work as a team and execute the plan in order to achieve the Sprint Goal (Sutherland &

Schwaber, 2013).

The Kanban Board

The Kanban system was developed in the 1950’s by Taichi Ohno, the former Executive

Vice-President of Toyota Manufacturing Corporation (Toyota web page 2015). The

system was introduced to the Production line in order to minimize waste and increase the

effectivity of the work flow in manufacturing. It was coined as the “supermarket method”

because T. Ohno got his inspiration while observing customer behavior in the

supermarket. It is about “supplying what is needed and when it is needed”. It is about

manufacturing “just in time” exactly what is needed for the next process, as the

supermarket staff replaced exactly the same quantity of product that the customer took

from the shelf (Toyota web page 2015-01-07).

Kanban is a Japanese word that means billboard or signboard. The Kanban board is an

important concept in the context of Agile software development and in the context of this

study. The Kanban board visualizes the flow of work through a set of columns associated

with the different stages of executing a specific task or a so-called ‘user story’. The

simplest Kanban board has three columns which represent three stages: To do, In

progress, and Done. Others have for example 6 columns to represent Backlog, To do,

Development (with 2 columns for In progress and Done), Testing (with 2 columns for In

20

progress and Done), Deployment and Done. In order not to fall into the Waterfall

method, each ‘in progress’ column is usually associated with a “work in progress limit”.

There is a maximum number of items that is being worked on. If the limit is reached, one

cannot start a new one before they are moved to Done. In Agile teams, the team members

automatically self-organize and support each other so that the work flow is not blocked

(guide.agilealliance.org 2015-01-07)

2.1.3 The concept of Critical Success Factors (CSF)

Two of the mainstream researches on software projects are research theories on failures

and research theories on success. Focusing on Agile software projects, Dr. Dac-Buu Cao

and Dr. Tsun Chow from the Capella University in Minneapolis, published in 2008 a

study that identified and presented the factors that are critical for the success of these

projects. They introduced the concept of Critical Success Factors (CSF) in this area. The

study combined literature analysis and a survey using a quantitative approach. Project

success was assessed in terms of four aspects namely (i) quality of the end product, (ii)

scope related to fulfilling the achieved objectives, (iii) delivering on time and (iv) within

the estimated effort and cost. The possible critical factors were identified from the so-

called “failure factors” and “success factors” from existing literature on Agile software

projects. By analyzing the reliability of the factors and their relationship to each other in

influencing the success or failure of an agile software project, the researchers came up

with a list of 12 critical success factors which were divided into the following 5

categories: organizational, people, process, technical and project factors (Tsun & Cao,

2007).

ORGANIZATIONAL

FACTORS

PEOPLE

FACTORS

PROCESS

FACTORS

TECHNICAL

FACTORS

PROJECT

FACTORS

1.Management

commitment

2.Organizational

environment

3.Team environment

4.Team

capability

5.Customer

involvement

6.Project

management

process

7.Project

definition

process

8.Agile

Software

techniques

9.Delivery

strategy

10.Project

nature

11.Project

type

12.Project

schedule

QUALITY SCOPE TIME COST

Figure 4. Potential Critical Success Factors

These 12 factors gave rise to 48 principal hypotheses by linking each factor to the above

mentioned four aspects of success. The next step was to validate these hypotheses by

using quantitative methods. The data was collected through a web survey that involved

21

professionals from 109 Agile projects from a diverse group of organizations and

industries in different locations around the globe. 89% of these projects were from the

Americas and Europe, 9% from Asia/Pacific and 1.8% from Africa. The survey then

confirmed 10 of the 48 hypotheses and reduced the list of critical success factors to the

following three critical factors: (i) accurate Agile delivery strategy, (ii) uncompromising

practice of Agile software engineering techniques and (iii) Agile team with high

capability. This means that the technical and people factors were predominant. In other

words, as long as these three factors were fulfilled the organizational factors provided

little or no effect on the project success. However, the researchers pointed out that this

could be a result of the fact that Agile methods are relatively new at the time of the study

so that the effects on project success of the organizational factors or Agile-friendly

environment have not yet been firmly established. Furthermore, it is important to note

that the project dimension which includes the nature and type of the project, as well as the

project schedule were not in any way critical for Agile project success. (Tsun & Cao,

2007) The latter therefore opens up a wide range of opportunities for applications with

regards to Agile project methodologies.

The self-organizing Agile team: The conclusions and results regarding the above

mentioned research on critical success factors for Agile software projects focused our

attention to the Agile software development team. The three critical success factors were

directly connected to the team’s implementation of the Agile delivery strategy and

software engineering techniques as well as the ability of the “high-caliber” (Tsun & Cao

2007). Agile team to overcome the challenges of being self-organizing. In 2013, Hoda,

R., Noble, J. & Marshall, S. published in the IEEE Transactions on Software Engineering

a research paper about the “self-organizing roles on Agile software development teams”

(Hoda et al. 2012) . Using Grounded theory and involving 58 participants from 23

software organizations in New Zealand and India over a period of 4 years, the researchers

generated a theory which explains and describes “six informal, implicit, transient, and

spontaneous roles” that facilitate self-organization in Agile software teams. The theory

presented the following roles: Champion, Coordinator, Mentor, Promoter, Terminator

and Translator (Hoda et al. 2012). The Mentor is the person that sees to it that the team

adheres to the Agile principles and methodologies as well as provides guidance with

regards to constructive practices towards self-organization. The Coordinator is the team’s

representative in customer collaboration. The Translator is the bridge between the

technical and the business language. Their task is to insure that there is a shared

understanding of what has been communicated between client and the team. The

Champion communicates with the senior management on the team’s behalf. Contrary to

the conclusions drawn by Tsun Chow and Dac-Buu Cao on organizational factors, the

theory generated this role and its importance in order to secure and maintain management

support for the self-organizing team. The Promoter builds up the customer’s knowledge

and involvement in Agile implementation in order to support the team’s self-organizing

strategy and Agile engineering techniques. Finally, the Terminator identifies and

removes from the team the individuals that threaten the efficiency of self-organizing

teams. Again, this entails a strong support from the senior management and

organizational structure. The grounded theory presented in the study was considered “first

of its kind in the field”. The authors encouraged other researchers to conduct further

studies on self-organizing teams in Agile software development in order to integrate more

data into the result and thereby contribute to a more generalized theory (ibid.).

22

2.1.4 Agile Practices and Trust

The two research papers presented above shed light on the people factors’ impact to Agile

software development projects. McHugh, O., Conboy, K. and Lang, M. (2012)

conducted on the other hand, three cases studies to highlight the impact of Agile practices

on agile team members. The empirical case studies focused on three Agile practices

namely sprint planning, daily stand-up and sprint retrospective. The data was mainly

experiences of members in three Agile teams from different organizations. Two of the

cases were developing software for internal business units and for insurance industry with

a distributed team and a co-located team respectively. Data collection was conducted

over a period of six months with 25 participants and roles such as scrum masters,

developers, product owners (PO), quality assurance personnel and technical architects as

well as project managers. The main result of the case study was that all interviewees

from the three cases confirmed that Agile practices promoted trust among the team

members. The three Agile practices increased opportunities for frequent communication

and feedback, as well as collective responsibility, transparency and accountability which

have a positive impact on trust among team members as well as raise trust issues that

existed in the team (McHugh, O., Conboy, K. & Lang, M., 2012). In this context, the

authors chose to refer to Roger Mayer et al. (1995) when defining trust as:

“the willingness of a party to be vulnerable to the actions of another party based on the

expectation that the other that the other will perform a particular action important to the trustor,

irrespective of the ability to monitor or control that other party”

(Mayer, R.C., Davis, J. & Schoorman, F.D. 1995) pp 709-734

While promoting trust, the participants also mentioned experiencing new challenges that

are connected to the Agile practices.

The following challenges were mentioned: (McHugh, O., et al., 2012)

(i) visibility and transparency could create “self-inflicted” team pressure to deliver

tasks within the agreed time frame

(ii) strained relationship between the PO and the Development team due to

differences in opinion regarding the membership of the PO within the team and

the POs engagement in the practices

(iii) PO feels that they can approach the Developers at any time

(iv) performing estimates on new tasks can be problematic

(v) the team does not fully understand the value of retrospective and practices it as

pure routine.

However, in spite of these challenges the compulsory Agile practices supported trust

building among the members of the Agile team and helped the team to function as one

unit. The conclusions in the study are limited to relatively small teams and to building

trust among the team members. Recommendations for further research include therefore

examining the impact of Agile practices in larger teams as well as building trust between

the team and other stakeholders (ibid.).

23

2.2 Distributed Teams

2.2.1 The concept of Distributed Software Development

The term Distributed Software Development (DSD) was introduced to the software

development industry in connection with the increasing number of organizations that are

distributing their software development processes to different physical locations. Thus,

DSD can be defined simply as software development processes that involve teams with

members at different geographical locations and environments. Software development

processes that are distributed worldwide is commonly known as Global Software

Development (GSD). Pressman R. S. (2001) defined the concept “software process” as:

“a set of activities, methods, practices and technologies that people and companies use to

develop and to keep related software and products.”

(Pressman, R.S., 2001)

GSD has been introduced during the “IT downturn” to deliver software development to a

low cost and with high quality. By taking advantage of high skilled labor and low-cost

offshore resources in developing countries the globalization in software development is

increasing. (Hossain et al. 2011) Ågerfalk and Fitzgerald (2006) define the benefits as

reduced development costs; taking advantage of working 24x7 (following the time-

zones); modularization of development work; accessing skilled/knowledgeable workers

around the globe; sharing innovations and best practices in larger teams; and finally

possibilities to be closer to the customers. (Ågerfalk,P.J.& Fitzgerald, B.,2006)

Prikladnicki, R. et al. (2003) identified three types of actors that are involved in software

development projects namely the Project team (P), the Customer (C) and the User (U).

The Project team was described as the individuals who are “involved in the development

of the project”. Besides the developers, this includes amongst others the business-oriented

personnel, project managers, testers, quality assurance people, and technical support. The

Customer is the individual that contracted the development of the project. The User

represents the stakeholders that are responsible for providing the project team with

information on requirements as well as the individuals that will eventually use the end-

product (Prikladnicki et al. 2003). The main result of their paper was a proposal for

classifying the different levels of distribution in DSD based on the physical distance

between the actors. They presented the following five scenarios in order to describe the

‘distance’ between the actors:

(i) Physically co-located scenario: all the involved actors are in the same

physical location.

(ii) Cross town scenario: the involved actors are in the same city

(iii) No time shift scenario: the actors are all located in the same country or State

(iv) Continental scenario: the project team is distributed in the same continent

(v) Global scenario: where the situation is that each team member (P, C, U) are

located worldwide. (ibid.)

2.2.2 Distributed Project Teams

The physical distance between the actors in a software development project poses various

challenges concerning different aspects of the project life cycle. In this section, two of the

24

aspects that are inherent in distributed projects will be presented based on two specific

research papers.

Electronic collaboration: Qureshi, S., Liu, M. & Vogel, D. (2006) presented an analysis

of the ‘effects’ of distributed work environments for virtual teams (Qureshi et al., 2006).

The development of virtual teams are influenced by the characteristics of the team (e.g.

size, geographic distribution) and the task (e.g. complexity). Virtual team members

usually live in different locations around the globe and are culturally diverse.

Collaboration is often carried out and managed through the use of “networking and

collaborative technologies”. The team relies entirely on computer-aided technology or

electronic collaboration [ibid.]. The successful interplay between the team characteristics

and the task characteristics as well as the process support provided by the chosen

information and communication technologies are key elements affecting the effectiveness

of distributed project teams. Qureshi et al. collected data from distributed virtual teams

composed of students from the Netherlands and Hongkong. The data was collected

through observations and logs of electronic collaboration. In this case, the collaboration

was managed through the use of so-called “eRoom”. The eRoom provided the virtual

teams with opportunities for “file sharing, discussion, voting and chat tool” (Qureshi et al.

2006) . By using the Grounded theory approach, the researchers explored the effects of

electronic collaboration that are crucial for the success of the distributed project. The data

collected brought out concepts such as time zone differences and involvement. Concepts

were grouped afterwards into three final categories that represent the effects of electronic

collaboration. The three categories that have impact on project team success and that

could be positively or negatively affected by electronic collaboration were

communication, coordination and adaptation (ibid.). So in spite of the advances in

technology, distributed teams tend to suffer difficulties in bringing about shared

understanding and mutual knowledge among the members of the project team, as well as

encounter problems in leadership and project management.

Conflict in Distributed Project Teams: Since geographically distributed teams are more

and more common in many organizations, it is important to understand the dynamics of

this kind of teams in comparison to collocated teams. Hinds, P & Mortensen, M. (2005)

published in Organization Science, a comparative study that was conducted among 22

collocated and 21 distributed teams from a big multinational company (Hinds &

Mortensen, 2005). One of the reasons why Hind and Mortensen chose to focus on

conflict was that recent research in the field suggested that task and personal conflicts

affect performance negatively especially when the task is highly complicated.

Furthermore, there were also arguments regarding distributed teams as having more

serious conflicts that are difficult to resolve compared to co-located teams. The

researchers therefore proposed that “geographic distribution contribute to conflicts and

that this effect could be moderated by shared identity and shared context” (ibid.). The

above mentioned comparative study aimed therefore to provide knowledge on how to

mitigate conflicts on distributed teams. The researchers devised a model for the

relationships between geographic distribution, shared identity, shared context,

spontaneous communication and conflict. Theories on “in-groups (those perceived as

similar) and “out-groups” (those perceived as different) suggest that members of in-

groups are evaluated more positively than those of out-groups. A strong sense of shared

identity over distributed teams can for example decrease negative perceptions,

stereotyping and distrust. In line with this, a hypothesis on shared identity as a

25

mechanism for moderating interpersonal conflicts in distributed teams was formulated.

Furthermore, the study also suggested that a shared context in terms of, amongst others,

transparency in information and working procedures, standardization of tools and

processes can make it easier for members in a distributed team to relate to each other’s

working approaches and culture. This led to the study’s second hypothesis which stated

that a shared context can “moderate the relationship between geographic distribution and

conflict”, and in particular conflicts where the task is the core issue (Hinds & Mortensen,

2005). How to achieve a shared context with colleagues can be challenging especially

when it is done across time and space. One of the mechanisms that this study presented

was called “spontaneous communication” wherein they refer to unplanned, open and

informal interactions between individuals. In collocated teams, interaction of this kind

can occur frequently and even without explicit verbal communication. Compared to

collocated teams, opportunities for more visual and other more expressive type of

information in distributed teams are limited. According to the authors, the described

“spontaneous communication” is however a medium for creating the above mentioned

shared context (ibid.).

To test the different hypotheses in the study, a web-based survey measuring conflict,

shared context and performance was conducted. The first result suggested that conflict is

‘greater’ in distributed teams than in collocated teams. Most significantly is that the

study also confirmed that shared identity and shared context can be achieved through

spontaneous communication, which in turn helps distributed teams to identify and resolve

conflicts at an early stage (Hinds & Mortensen, 2005).

2.2.3 Globally distributed software development and Quality:

It has been established in a number of researches that globally distributed software

development entails challenges that are specifically associated with geographical

distribution (e.g. delays in communication, cultural barriers). However, another vital

question to ask in connection with globally distributed software development is how it

affects the quality of the end product. By examining the data from the implementation of

Windows Vista, Bird, C., Nagappan, N., Devanbu, P., Gall, H., & Murphy, B., (2009)

tested the hypothesis “that globally distributed software development leads to more

failures” and in that way answer the question about quality in terms of “post-release

failures”, which are the failures that affect the end-user most (Bird et al. 2009). The

“failures” were identified at the so-called binary level (individual files containing code).

“Failure” was defined in the paper as:

“the inability of a system of component to perform its required functions within specified

performance requirements…” IEEE Standard 982.2-1988

The study was a comparative study between post-release failures in the binaries that were

developed by distributed teams (“distributed binaries”) and those developed by

collocated teams (“collocated binaries”). Distributed binaries are defined as binaries

wherein at least 25% of the commits were developed in locations other than the binary

owner’s residence site. The study focused on an extensive software development

operation involving approximately 4000 binaries and 3000 developers in one company.

The study categorized the different levels of geographical dispersion of the developers

into the following: i) same building (ii) same cafeteria, different buildings (iii) same

26

city, different campus (iv) same country, different localities that require air-travel or

multi-day trips (v) same continent, different country (vi) worldwide (different

continents). Each binary is then classified into this hierarchy of dispersion. Binaries that

are classified in the first two levels are considered within collocated development and the

rest as distributed development. Focusing on code quality and code ownership, the study

concludes that in the case of the Vista development (wherein most of the development

occurred in the US and India), distributed development does not necessarily lead to more

number of post-release failures as compared to collocated development (Bird et al. 2009).

2.3 Distributed Agile Software Development

2.3.1 Potential Problems in GSD

In 2010, Shrivastava and Date presented a review of the issues regarding the combination

of two important movements in software development namely Agile and Distributed

software development. The paper started by discussing seven potential problems in GSD

and in the end aimed to provide a better understanding of the advantages of combining

Agile and GSD. The latter part will be explored in section 2.3.3 (Shrivastava & Date,

2010).

The first difficulty in GSD that the authors mentioned concerns resource management

and strategic issues. A decision should be taken on how to strategically divide the

development work between the different teams, and whether it is beneficial for the

software development project to be globally distributed or not. Furthermore, a risk

awareness and an analysis is needed to comprehend and understand the diversity of skills

and knowledge that the team possesses as well as other resources in terms of

infrastructures, technologies, tools, etc. (ibid.).

As stated above, communication as a key for successful virtual development and positive

e-communication, can lead to outcomes such as team collaboration. On one hand, it was

stressed by Qureshi et al. (2006) that effective collaboration has great impact on project

success. On the other hand, Shrivastava and Date pointed out two potential problems that

are closely associated with communication and collaboration namely cultural differences

and “inadequate communication”. It was suggested that cultural differences intensify

communication difficulties and that inadequate communication was a result of reduced

frequency and quality due to lack of ‘face to face’ meetings (Shrivastava & Date, 2010).

The fourth difficulty is knowledge management in terms of problems related to sharing

experiences in order to reduce rework, redundant or excessive work. In order to reap the

benefits of GSD and software development, information and knowledge sharing

mechanisms (e.g, through network and collaborative technologies) must be put in place.

(ibid.)

The fifth difficulty is associated with project management problems. The changing

requirements combined with challenges inherent to globally distributed software

development, such as lack of informal contacts, cultural diversity and time zone

differences, can lead to difficulties in scheduling, task assignment, cost estimates as well

as organizational management (ibid.).

27

The two last difficulties that Shrivastava and Date (2010) suggested are risk management

and technical issues. The authors considered risk management a “critical activity” in

DSD/GSD. With all the above mentioned potential problems and difficulties, it is

therefore highly essential to have structures and processes for quality assurance and

control to reduce defects [ibid]. Risk identification could be a factor that could impact to

the success or failure of the project. Technical issues in DSD are related to computer-

mediated or electronic collaboration, and are vulnerable to network or internet connection

problems.

Shrivastava and Date (2010) stated that the causes of the above difficulties are related to

physical distance, time and cultural differences. Ågerfalk and Fitzgerald (2006) also

made a similar categorization. Their work on Agile methods and GSD will be explored in

detail in the next section.

2.3.2 Challenges and Mitigation mechanisms in Agile DSD

As stated previously, Agile project methods are more and more adapted in software

development and is described as a “community writing an epic poem together”. To write

the epic poem collectively, some key elements are communication, coordination, control

which are also closely linked and not very different for collocated teams. To tackle and

define challenges with GSD and Agile project methods, Ågerfalk and Fitzgerald (2006)

stated three categories to list problems and opportunities: 1.) Temporal distance: time-

zones and working hour differences. 2.) Geographical distance: team distance on global

scale. 3.) Socio-cultural distance: cultural differences in the project teams. Comparing the

elements and the categories, they defined a matrix and listed opportunities (+) and

challenges (-) in each link:

Figure 5. Challenges and mitigation factors (Ågerfalk & Fitzgerald, 2006)p28

According to Hinds, P & Mortensen, M. (2005) one mitigation mechanism in distributed

teams is spontaneous communication. Hossain, Bannerman and Jeffery (2011) presented

28

a research framework based on 27 different papers on GSD and Scrum practices. They

have compiled and suggested the following mitigation mechanisms:

1. Synchronized work hours: increase overlapping, come in early or stay late to

adjust to the other members of the team

2. Information and communications technology: ICT-mediated synchronous

communication. Encourage and ensure that synchronous formal or informal

contact is done through amongst others: Telephone, Teleconference,

Videoconference, Web conference or other applications (google hang-out, Skype)

3. ICT, mediated asynchronous communications – For example e-mail, IM, or Wiki

4. Visits: Encourage face-to-face meetings so team members can meet and have

opportunities to build and sustain relationships.

5. Frequent (or improved) communication: Enable through technology and face-to-

face meetings

6. Iteration: Cyclical repetitions make it possible to monitor progress and resolve

issues

7. Review: Time for reflection, assessment of previous tasks performed, engage

stakeholders in giving feedback.

8. Planning: Activities that defines and clarifies requirements, scheduling tasks etc.

In the framework, each mitigation mechanism is mapped to the challenges that Ågerfalk

and Fitzgerald (2006) listed in their matrix in figure 5.

Hossain et al. (2011) presented the following framework, where the communication,

coordination and control challenges were mapped with the corresponding mitigation

mechanisms listed above.

A.Mapping for the communication challenges:

“Reduced opportunities for synchronous communication (due to temporal

distance)” (Ågerfalk & Fitzgerald, 2006) can be mapped to mitigation

mechanisms 1 and 3.

(i) One of the actors/teams or both actors/teams need to adjust their work hours.

(ii): Introduce or encourage more asynchronous communication in form of IM, e-mail, or

Wiki.

“Face-to-Face” meetings: difficult (due to geographical distance)” (Ågerfalk &

Fitzgerald, 2006) was mapped to:

(i) Hold meetings on-line through different tools such as Skype, Live Meeting,

teleconference, video conference.

(ii) It is critical to ensure that also informal contact is conducted. Sprint planning can be

communicated by (3) asynchronous ICT tools (IRC, wiki, e-mail, etc.) or by visits. For

a challenging sprint it could be even more important to plan a visit for a team or actor.

“Cultural misunderstandings (due to socio-cultural distance)” (Ågerfalk &

Fitzgerald, 2006) The proposed mitigation factors for cultural

misunderstandings are mechanisms 3,4 and 5.

(i) Introducing asynchronous communication as e-mail to put communication in writing

(ii) Implement visits to build trust and relations

29

(iii)Frequent and improved communication by having daily scrums and sprint planning

meetings with mandatory participation. This three factors can help break down

cultural barriers.

B.Mapping for the Coordination challenges:

“Increased coordination costs (due to temporal distance)” (Ågerfalk &

Fitzgerald, 2006) can be mitigated by:

(i)Adjusting work hours and asynchronous communication can be effective solutions.

Sprint planning can be held as an example late for one team and early for the other,

improves coordination by reviewing, planning and issues for the work packages.

“Reduced informal contact can lead to lack of critical task awareness (due to

geographical distance)” (Ågerfalk & Fitzgerald, 2006) can be mitigated by

mechanisms 2,3,5,6,7 and 8.

(i) Video conference calls enable the team to interact in more ways than just by voice or

text.

(ii) Using for example e-mails as support to increase task awareness.

(iii)Using Scrum: sprints are an iterative process where it is required to define done.

This also increases the task awareness, understanding of requirements and planning of the

next steps.

(iv) Lastly the iterative process, sprints, sprint planning, retrospectives and daily meetings

increase the need for daily and frequent contact. These practices should also lead to

increase informal contact.

“Inconsistent work practices can impinge on effective coordination (due to

sociocultural distance)” (Ågerfalk & Fitzgerald, 2006) was mapped to the

following mitigation mechanisms:

(i)Daily scrum meetings can underpin and increase consistency of work practices.

(ii)The iteration of sprints increases coordination and consistency of work practices. (5 &

6)

“Reduced cooperation arising from misunderstanding (due to socio-cultural

distance)” (Ågerfalk & Fitzgerald, 2006)

(i)Cooperation can suffer because of cultural and language barriers. Mitigation factors

for that is: building trust and common grounds by travelling to become a collocated team

for a couple of sprints (4).

(ii)Recording and replay of conference calls to increase understanding (3).

(iii)Scrum meetings and retrospectives is a forum for frequent communication that offers

reviewing and planning of work in and iterative way. This should lead to better

coordination and understanding between team members (5,6,7 and 8).

30

C.Mapping for the Control challenges:

“Management of project artefacts may be subject to delays (due to temporal

distance)” (Ågerfalk & Fitzgerald, 2006)

(i)According to Hinds, P & Mortensen, M. (2005) there is no mitigation factors listed in

the literature in the scope of their study.

“Difficult to convey vision and strategy (due to geographical distance)”

(Ågerfalk & Fitzgerald, 2006)

(i)Visits from stakeholders or project owners to off-shore teams can be beneficial to

ensure full understanding of the visions and strategy (kick-offs).

(ii)Having daily scrum meetings emphasizes a common ground and is a forum to

strengthen the vision and strategy.

(iii)For the reviews and retrospectives team members can get feedback that the vision and

strategy is met. If not the team can plan ahead to adopt the project, processes or methods

to be according to that.

“Perceived threat from training low cost “rivals” (due to geographical

distance)” (Ågerfalk & Fitzgerald, 2006)

(i)According to Hinds, P & Mortensen, M. (2005) there is no mitigation factors listed in

the literature in the scope of their study.

“Different perceptions of authority can undermine morale (due to socio-cultural

distance)” (Ågerfalk & Fitzgerald, 2006)

(i)To mitigate this, frequent meetings as in Agile methods can clarify the responsibilities

and authority for the individuals. Team members’ value-add is visible and team members

worth and contribution to the project is visualized and announced.

“Managers must adapt to local regulations (due to socio-cultural distance)”

(Ågerfalk & Fitzgerald, 2006)

(i)According to Hinds, P & Mortensen, M. (2005) there is no mitigation factor listed

in the literature in the scope of their study.

2.3.3 Benefits of implementing Agile methods to globally distributed teams

Shrivastava and Date (2010) discussed in their review how the practices in Agile methods

can be consciously aligned to directly address the challenges inherent to GSD. One of

the major challenges in teams that are geographically dispersed was “decreased

visibility of the project status” (ibid.). Furthermore, Hossain et al. also referred to

communication as one of the process categories to be included among GSD challenges.

The Agile methods’ iterative and incremental features can facilitate early problem

31

identification which is a way of addressing the challenge related to visibility of project

status. (Shrivastava & Date, 2010)

Agile practices such as sprint review and retrospectives are also team ceremonies, which,

if performed properly, could address some of the challenges in communication. In the

sprint review the project team will have an opportunity to gather feedback from the

customer and other stakeholders on a regular basis and at short intervals. Customer

requests for changes in requirements and priorities for the next iteration can also be

communicated to the team. The project team in turn will have a chance to communicate

their delivery and adaptation strategies. In the retrospectives, the team members discuss

and assess their latest iteration, identify positive practices as well as strategies for

improvement for the next iteration. Frequent and open communication among the team

members and the stakeholders can also address challenges associated with cultural issues

(Shrivastava & Date, 2010) . These above mentioned practices can be a way to

facilitate a shared project context for the team members, which according to Hinds, P &

Mortensen, M. (2005) is one moderating factor to the relationship between conflict and

distribution. Furthermore, McHugh, O., Conboy, K. and Lang, M. (2012) also confirmed

that the above Agile practices have a positive impact on trust among the team members.

2.4 Implementation

In connection to organizations adopting and implementing new methodologies and

innovations (e.g. agile methodologies), we find it relevant in this study to take a look at

some theories on the assimilation process, and in particular, its application to Agile

practices.

2.4.1 Assimilation theories

Assimilation is defined according to Meyer & Goes (1988) as an organizational process

that “(1) is set in motion when individual organization members first hear of an

innovation’s development; (2) sometimes comes to fruition in the innovation’s full

acceptance, utilization and institutionalization”. From that definition, Gallivan (2001)

continued to define six different stages of an assimilation process, namely:

i. Initiation: screening of innovations that are suitable for the organization.

ii. Adoption: the organization decides to implement the innovation

iii. Adaptation: teams and individuals are trained and the methods are developed

and maintained.

iv. Acceptance: Team and individual motivation is build and the team is committed

to use the methods

v. Routinisation: The methods and activities are considered as normal activities on

the day-to-day basis. Innovation is not considered as something “out of the

ordinary” (Gallivan, M.,2001).

vi. Infusion: For the latest stage three different levels of usage are defined:

a. Extensive use: The methods are more developed than existing innovation

32

b. Integrative use: Integration with normal routines and standards

c. Emergent use: Not used for core methods, routines and standards.

In 2012, Wang, X., Conboy, K., & Pikkarainen, M. conducted an exploratory study on

the three final stages for agile practices. Four different cases where studied and face-to-

face interviews were performed, the team was in the center for the analysis and the

exploratory investigation focused on implementation of agile projects methods (Scrum

and XP). Wang et al. (2012) found that the concepts of assimilation are largely applicable

to Agile practices.

i.) In the acceptance stage, they observed that the team likely would change or

customize the agile practices so that they are tailored for the task and team

composition. They also found out that it is a continual iterative process to

evolve or change the agile methods during projects or time.

ii.) The routinisation is in this case observed and defined according to Wang et

al. (2012 ) as “the extent to which an agile practice is frequent used, highly

embraced and adhered to, and no, longer considered as something out of the

ordinary” (ibid.). The agile methods observed in the study were Sprints,

Sprint planning, Daily meetings, Retrospective, 40-hour week, On-site

customers, Simple design, Pair programming, Testing first, Continuous

integration, Collective ownership, and Refactoring. A variation of

routinisation was observed between the four cases, differences in adherent,

embracement, and frequency of tool implementation occurred between the

cases.

iii.) For infusion Wang et al. (2012) extended the three levels with two new

indicators to better cover the agile principles: “Intensive use” and “deeply

customized”. Intensive use is defined as “practice is used with intensity

beyond that suggested by the textbook” (Wang et al. 2012). Deeply

customized means according to Wang et al. (2012) that “agile practice is

adapted at a deep level to suit the need of the adopting team” (ibid.). It is a

clear logical chain between infusion and routinisation. Routinisation needs

to be in place to have infusion. According to the empirical studies this chain

could also be seen when implementing Agile principles.

The conclusions from the research were that the later three stages could be used as

theoretical base for implementing agile principles. One more interesting observation is

that the duration of usage of a specific agile tool/method does not affect the progress of

reaching the infusion stage. Time is not a relevant factor. There are other factors to

consider to successfully adopt agile principles. One thing that Wang et al. (2012) found

out was that the need of the agile team was a key driver for adopting the tool. The

textbook set of tools should be looked at subjectively and tools should be chosen by

considering the needs of the team.

33

3 Method

In this chapter, we present the Grounded Theory Method (GTM) and the processes that

were utilized in the study together with a brief historical account on the origin of the

method. It provides an introduction to the basic concepts and operations of GTM. The

integrated processes of data collection, coding and analysis were discussed and illustrated

through concrete examples from the empirical study.

3.1 Introduction to Grounded Theory: ground and discovery

The last three decades of the 20th century has seen the evolution of the Grounded Theory

Method (GTM) as a qualitative research method. It has been applied in various fields of

study and disciplines. The method originated from Glaser, B. and Strauss, A. in

connection with their research work about death and dying in hospitals and health

institutions in the United States (Glaser & Strauss, 1967). ‘Death’ was a relevant issue for

both researchers since they had personal experiences of death around the beginning of the

1960s when Strauss started the research project and Glaser joined him six months later.

Together they developed this research methodology on how a ‘theory’ can be generated

from data and empirical study. GTM was Glaser’s and Strauss’s initiative to provide an

alternative to the qualitative research of theory verification. It was an alternative that

showed how qualitative research can shift its focus from verification to generation of

theory, from the “logic of validation” to the “context of discovery” (Bryant & Charmaz,

2007). GTM was considered by Glaser as an inductive method of developing theory or

constructing hypothesis. And by “theory”, Glaser and Strauss meant one that is well-

grounded and indicated in the data. It can be readily understood by professionals and

“significant” laymen because it “fits” the context in the sense that it could relevantly

describe and explain the phenomenon or behavior that was studied; it is “sufficiently

general” to provide applications into a wider range of situations within the ‘substantive’

area, as well as gives the practitioner a certain level of control over his/her decision to

apply the theory ‘in’ everyday situations (Glaser & Strauss, 1967).

“Generating a theory from data means that most hypotheses and concepts not

only come from the data, but are systematically worked out in relation to the data

during the course of the research. Generating a theory involves a process of

research.” (ibid.,p6)

The above four properties of the grounded ‘theory’/hypothesis namely: fitness,

understanding, generality and control were definitely relevant and interwoven in the

present context and in this particular study.

Furthermore, Glaser and Strauss stressed the use of “comparative analysis” as the central

strategy in GTM. As a method in generating theory, Glaser and Strauss pointed out that

comparative analysis can be applied to social units of any size, both large-scale and

small-scale social units, e.g. group of individuals, organizations, communities, nations.

The method of constant comparison suggested by Glaser and Strauss combined data

collection with the joint coding and data analysis process. In the present study, these three

fundamental operations were done by the researchers simultaneously until no additional

data were being found. The method of constant comparison, according to Glaser and

34

Strauss did not involve proof nor the need to consider all available data. The only

requirement was the saturation of data (Glaser & Strauss, 1967).

“As categories, hypotheses and so on emerged- as they did, quickly and

continually – they directed the further collection of data. They directed what kind

of comparative items would be sought and where.” (ibid., p157)

“/…/ categories are ‘saturated’ when gathering fresh data no longer sparks new

theoretical insights, nor reveals new properties of your core theoretical

categories.” (Charmaz 2006, p113)

The first quote above therefore gave the researchers the specific guideline that data

collection and analysis in GTM are processes that go hand in hand, while the second

quote answered the question regarding when to terminate data gathering and what criteria

dictated saturation. These were the main principles that were applied by the researchers

in the present study.

Since their collaboration and first application of GTM, Glaser and Strauss continued to

develop GTM and their efforts resulted in different approaches, which were further

studied and applied by their doctoral and postdoctoral students, the so-called “second-

generation” grounded theorists (Charmaz, K., 2006). In the present time, there are

different approaches and family of ideas that claim to be under the umbrella of grounded

theory methodologies. Some well-known contributions in connection with the

development and application of GTM included the works of Strauss and Corbin, J. Hood

and K. Charmaz. Strauss and Corbin proposed in their article “Grounded Theory

Research: Canons, Procedures and Evaluative Criteria” (Corbin & Strauss, 1990) a way

of redefining the scientific principles of Grounded Theory for qualitative research,

recommended validation criteria and systematic procedures to strengthen its relevance to

complex circumstances in social science. They explained further the generalizability and

applicability of the generated theory. It was suggested in the article that a way of

achieving generalizability of the theory was to raise the concepts’ level of abstraction,

and in particular the main categories.

“The more abstract the concepts, especially the core category, the wider the

theory’s applicability.” (Corbin & Strauss, 1990) p15

Applicability of the theory was closely related to the data from a defined specific

phenomenon or phenomena in which the theory was ‘discovered’. Strauss and Corbin

therefore stated that practitioners who intended to apply the theory in their everyday

practices and with the aim of improving social phenomenon should be prepared to exert

efforts in exploring the limits of the theory’s relevance in new situations and how to

extend it to the new social realities that emerge (ibid). Jane Hood’s field work and

research on the theme of “bargaining power in the context of marriage” showed how

theoretical sampling and coding methods could influence the study right from the start

(Charmaz 2006). In her award winning book: “Constructing Grounded Theory” (2006),

Katie Charmaz placed the objectivist grounded theory (e.g. Glaser and Strauss, 1967) side

by side with the constructivist grounded theory (e.g. Charmaz, 2000). Charmaz clarified

the differences between these two stances and challenged researchers to judge for

themselves if a specific study adhered to one or the other (Charmaz, K., 2006).

35

The researchers found that the main research question in this study was essentially very

open and was still not widely explored. This led to a conscious decision to start from a

‘blank’ canvas, and set the study’s focus on theory generation instead of verification. The

so-called Glaserian or classical grounded theory was therefore chosen as the research

method in this study. The key aspect of this study’s method was that the researchers

entered the field without a pre-conceived hypothesis to verify or validate, no pre-

formulated interview protocol and without in-depth knowledge gained from extensive

literature study or pre-established firm definition of the social phenomenon in question

(Glaser & Strauss, 1967).

3.2 The constant comparative method and the study’s research process

At present, Grounded Theory has been considered by many social scientists as a powerful

method for research. In its core lie the integrated processes of data collection and

analysis, which includes the act of deriving codes from the raw data.

In this study, the codes that we generated were short descriptive phrases that summarized

the issues that were highlighted during the interviews, focus group sessions and

observations of agile practices, as well as researcher’s notes from the “field work”, which

means being in the substantive area 6-8 hours a day, 5 days a week for 7 consecutive

weeks.

Respondent’s quotes Codes

You need to ask a question

and the person you need to

contact is still sleeping, that

is an issue…

Delay

We try to educate them in

the agile principles, the

practice, the method…

Aligning client’s mindset

and behavior

It is more biased to the

client because they are the

ones calling the shots…

Inequality between roles

Observations in the Field

Event: Retrospective

Codes

Notes: The Retrospective

event started 5.30 pm.

(Manila time)

Adjustment / entails effort

Notes: Tandberg video

conference system was

used

Audio – visual effect

Figure 6. Examples of the initial open coding

36

These initial codes were further analyzed and grouped into common themes which we

defined as first level concepts. The emerging concepts were grouped and regrouped

several times during the course of our research process in order to generate a higher level

of abstraction called categories.

Understanding/Interpreting customer requirements

Definition of Ready

Working towards shared goal

Definition of Done

“The big picture” of the Sprint

Figure 7. Example of grouping initial codes into a first level concept in the study

The above diagram illustrated how a more abstract thought or a concept was established

namely ‘working towards shared goal’, which was further grouped with ‘shared values’,

‘agreement of all stakeholders’ and ‘capacity building’. These four ‘first level concepts’

formed together a key category called ‘The concept of People-centric organization’

because they described the main properties of what the involved individuals meant by the

higher level concept of a people-centric organization. In this way, the generalizability of

the emerging grounded “theory” can be strengthened and its relevance to more complex

situations can be achieved (Corbin & Strauss, 1990).

Shared Values

Working towards shared goal

The Concept of People-centric organization

Capacity building

Agreement of all stakeholders

Figure 8. Example of grouping the 'first level concepts' to a key category

As we mentioned earlier in section 3.1, comparative analysis was the central strategy in

GTM. The constant comparison was the key operation in the research process whose

main focus was the generation of theory.

“Using the constant comparative method makes probable the achievement of a complex theory

that corresponds closely to the data since the constant comparisons force the analyst to consider

much diversity in the data.” (Glaser & Strauss, 1967) pp113-114

37

The researchers were therefore guided in the research process by the four stages in the

constant comparative method namely (i) comparing the situations/experiences that is

related to each category, (ii) incorporating characteristics to the categories, (iii)

establishing the limits of the theory and (iv) formulating the theory (Glaser & Strauss,

1967). The process entailed coding, examining and comparing the data acquired from the

interviews, the observations and the experiences in the field that apply to a concept or

category. The constant comparison of data, the joint analysis and data collection

supported the researchers in the process of filling in the gaps in the properties and

characteristics of the emerging key categories as well as in establishing the emerging

theory’s delimitations.

3.3 Credibility of GroundedTheory, Validity and Reliability

Before discussing the credibility of grounded theory, it is relevant to first take a look at

the different concepts of ‘theory’ in the social scientific context. Different grounded

theorists have different definitions of what ‘theory’ means. Some of them are rigid while

others can be very fluid notions of the concept. In connection with grounded theory,

Charmaz (2006) presented the positivist and the interpretive definitions of theory. She

asserted that from the positivist point of view, “the objectives of theory are explanation

and prediction” while the interpretive definition stresses “understanding” instead of

explanation, accepts subjectivity and various interpretations or “multiple realities”

(Charmaz, 2006). Glaser’s notion of theory in grounded theory (as described in section

3.1) is more biased towards the positivist definition. Glaser’s notion of the emergence of

theoretical categories from the data and the ‘discovery’ of grounded theory also points

towards the objectivist grounded theory which has roots in the positivist tradition. He

treated the emerging categories as variables and generate hypotheses about them. Strauss

and Corbin view theory with both positivist and interpretive notions. Similar to Glaser’s

stance, they consider theory as a set of concepts and their interrelations, which can be

used to explain and predict. However, they also lean towards the constructivist grounded

theory which is an element in the interpretive tradition (Charmaz, 2006). Glaser and

Strauss (1967) discussed the issue of “credibility of grounded theory” from their own

perspective as researchers and analysts. They stated that the researchers’ confidence and

trust in what they know about the specific area of study is the result of their own

experiences in systematically working and living with the data. They stated that

“a field worker knows that he knows, not only because he has been in the field and because he has

carefully generated and discovered hypotheses, but ‘also in his bones’ he knows the worth of his

final analysis. /…/ this conviction does not mean that his analysis is the only plausible one that

could be based on his data, but only that he has high confidence in its credibility. ” (Glaser&

Strauss 1967) p225

In the case where there are two researchers involved, the final theory was a result of the

researchers’ shared experiences of the data, the observations, the countless discussions,

the conceptual analysis and the final generation of hypotheses. Both are totally involved

in the world that was chosen as the field of study, and could maintain the balance

between being “immersed” to be able “to know it” and at the same time “detached” to be

able “to think theoretically” about it (Glaser & Strauss, 1967). The next important task for

the researchers to undertake is to communicate the confidence in what they collectively

know, and finally “convey” the credibility of the theory to the reader (ibid.). It is vital that

38

the readers be brought into the picture of how the research process evolved and how it

was carried out towards the final analysis (Corbin & Strauss, 1990).

The concept of validity is not an issue in the classical grounded theory method since the

main focus of research is not verification. Stenbacka (2001) argued too that the concept

of reliability is not relevant in judging the quality of qualitative research when

measurements are not involved. Validity and reliability are concepts that are meant to

provide evidence for the trustworthiness of the result in qualitative research (Stenbacka,

2001). In grounded theory, trustworthiness of the result is another way of stating the

credibility of the generated theory.

3.4 Integrated processes: the Data collection and Analysis.

Theoretical sampling was defined by Glaser and Strauss (Glaser & Strauss, 1967) as the

“process of data collection for generating theory whereby the analyst jointly

collects, codes, and analyzes his data and decides what data to collect next and

where to find them, in order to develop his theory as it emerges.” (Glaser &

Strauss 1967) , p45

Since the topic of the study is to ‘discover and learn’ the important factors to focus on

when implementing agile methods in globally distributed teams in software development

projects, the substantive area chosen for this study was four software engineering

companies that have implemented agile project methods in software development for at

least a year. The researchers were based in Sweden, although one of the researchers spent

a total of 8 consecutive weeks (Sept-Nov 2014) in the Philippines during the course of the

study. In response to the need for more case studies within the area of offshore software

development involving Southeast Asian nations, this thesis’s respondents were mainly

from the Philippine offices. The data collected for this thesis consisted of 18 individual

interviews in the Philippines and 4 individual interviews in Sweden as well as two focus

group sessions involving a total of 11 individuals, observations of formal agile practices

and “field work” conducted by one of the researchers in the Philippines.

(i) The individual interviews included in the study involved 22 respondents. 20

out of 22 individual interviews were conducted face to face at the

respondents’ workplace and in some cases at a café or restaurant. The

remaining two individual interviews were done in Sweden and in the

Philippines via Adobe connect and the Tandberg video system respectively.

Each interview lasted 50-60 minutes and involved 4 companies, three in the

Philippines (X, Z and Q) and one in Sweden (Y). The companies and

respondents will be presented in Chapter 4. All the interviews in the

Philippines were conducted from September 16 to November 7, 2014 and the

interviews in Sweden took place in December 2014.

(ii) The focus group sessions were events that took place at company X with 7

software developers and at company Q with 4 software developers. Each

session lasted approximately 60 minutes. The first focus group session was

39

conducted at company X in September 16, 2014 and the second session was

conducted at company Q in October 14, 2014.

(iii) The observations conducted were observations of specific agile practices,

mainly Scrum practices (e.g. daily stand-up meetings, sprint planning,

backlog grooming, demos, meta-scrum, retrospectives) that were performed

by different teams mainly at company Z. In these cases, the researcher was

merely an observer. These observations clarified the practical issues

regarding the agile method that was being implemented and the events that

the respondents referred to during the individual interviews and focus group

sessions. A complete list of the practices that were observed was presented

in figure 9 in section 4.1.

(iv) The so-called “field work” mentioned above (6-8 hours/day, 5 days/week)

took place at Company Z during the period Sept 22 – Nov 7, 2014. This was

made possible by the so-called Minor Field Study programme (MFS)

financed by Sida (Swedish International Development Cooperation Agency)

and administered by the Swedish Council for Higher Education. The field

work was considered by the researchers as a valuable component in the

research process. For 7 consecutive weeks, the researcher was strategically

positioned at the Development department of company Z in Makati city,

Philippines. The department had an open plan office designed to facilitate

spontaneous communication, interaction and transparency. The office also

had a staff pantry as well as group rooms and conference rooms. The “field

work” complemented and enhanced the data gained from interviews, focus

group sessions and observations of formal scrum practices. It gave the

researcher an opportunity to get a systematic first hand practical experience

of the organization and the everyday working situation of the Agile project

teams. Being in the field everyday, (normally from 10 am to 7 pm, Monday

to Friday), the researcher could amongst others shadow a team or different

team members during the day, see how the members of the team interact with

each other, be aware of the everyday challenges or impediments (e.g.

technical problem solving issues, issues when one of the members got sick)

that they experienced and how they resolve it, observe closely and

continuously the collaboration between the scrum master and the distributed

team, interactions between teams, and the visits conducted by team members

from USA and Europe. Moreover, the “field work” entailed interacting

socially with the teams during the day (e.g. lunches and breaks, informal

meetings), and experiencing their whole context of implementing agile

methods in globally distributed teams. During the “field work”, the

researcher also got involved in other activities aside from the observed

formal agile practices (e.g. celebrating a team member’s birthday, attending

an Agile community networking meeting, experiencing the role of a Scrum

master for a whole day during a Scrum boot camp, numerous informal

conversations with team members with different roles and experiences in

combining agile project methods and distributed environment). In other

words, the “field work” gave the researcher an opportunity to follow up and

compare the respondents’ narratives with own experiences in the field. The

“field work” therefore was another way for the researcher to be “immersed”

40

(Glaser & Strauss, 1967) in the substantive area to be able to know it well,

and at the same time, have the capability to withdraw, analyze it and make

sense of what is going on from a grounded theorist’s point of view and in

relation to the main research question. This required the researcher’s

conscious awareness and continuous discipline in maintaining focus on the

task at hand for approximately 40 hours a week in the field.

The data collection was directed from the beginning solely by the general research

question on learning what the important factors to focus on when implementing agile

project methods in globally distributed teams. It was not guided by any pre-conceived

hypothesis or theoretical framework. The researchers also lack in-depth theoretical and

practical knowledge of the substantive area at the beginning of the study. The researchers

entered the field of study in September 2014 suppressing pre-conceived understandings

and experiences of the chosen phenomena, thus there was no pre-formulated interview

protocol or questionnaire. However, the individual interviews and focus group sessions

were carried out according to the following structure :

Step 1: The objectives and main research question as well as the GT methodology were

briefly presented to the respondents/focus group, (took approximately 2-3 minutes).

Furthermore, the respondents were informed that they, as well as their companies would

remain anonymous in the study. The researcher also asked for their consent to record the

interview for the sole purpose of using it in this particular study.

Step 2: The respondents were given 1-1.5 minutes to write individually in a post-it/s

words, phrases or pictures that spontaneously came up to their minds during the

researcher’s introduction and brief presentation of the study’s objectives and main

research question.

Step 3: The respondents were asked to talk about what they wrote in their ‘post-its’,

elaborate on their thoughts and reflections on the topic, discuss issues and concerns that

they judged to be relevant to the study. The respondents were also asked to introduce

themselves briefly and share information regarding their educational and professional

background in software development (see Appendix 2: Respondent’s background

template).

Step 4: In the end, the respondents were asked to wrap-up and conclude the interview

with their personal ‘words of wisdom’ for future adopters of Agile project methods in

globally distributed teams.

From the beginning to the end of the interview, the researchers kept in mind the

importance of creating a conducive environment for sharing and openness, as well as a

positive dynamics between the researcher and respondent. The researchers took special

care to establish a relaxed, respectful and trustful atmosphere during the whole interview

mostly through ‘empathic listening’ and responding by asking open-ended questions and

conveying to the respondent how his/her words were understood.

Glaser (1967) stated that getting people to let you in and give you their permission “to

study them at will” often takes time (Glaser & Strauss, 1967). In this case, it went

relatively fast to connect with the respondents and establish a trustful relationship with

the people at the actual field study at company X and Z. The positive connection and

“rapport” (Glaser & Strauss, 1967) between the researcher and the people in the field at

41

companies X and Z was developed almost the same week the researcher started the study

in the field. At company X, the researcher started with a conversation with the people

from the HR-department followed by a focus group session that was scheduled after

working hours. The discussion during the focus group session gave the researcher an

excellent introduction in the substantive area. The fact that the participants voluntarily

stayed after working hours was a very positive sign of motivation and commitment from

their side. An informal, relaxed atmosphere could be observed right from the start. The

participants had some snacks during the session and the session began by the researcher

and participants introducing themselves briefly to each other. The actual 7 weeks “field

work” at company Z started with participatory observations at the three whole day Scrum

boot camp for new project team members. The boot camp provided the researcher with a

practical knowledge of Scrum and an experience on how new team members were

introduced to the company’s way of implementing Scrum in globally distributed teams.

In order to strengthen the learning experience, and to further prepare the researcher for

the field work, the researcher was appointed to take on the role of Scrum master for a

whole day during the last day of the boot camp. The boot camp facilitated a personal

connection between the researcher and a group of 10 software developers/engineers as

well as two certified scrum masters. These individuals in turn, introduced the researcher

to other members of their project teams and other scrum masters in the company. Thus, a

period of introduction, getting people to ‘let you in’ and establishing connections in the

workplace for more than a whole week preceded the individual interviews and

observations of the formal scrum events at company Z.

During the course of the individual interviews, the researcher stepped back and listened

most of the time. In order to ensure that the message was understood correctly, the

respondents were asked at regular intervals to confirm a paraphrased and summarized

version of what has been said. The individual interviews and focus group sessions lasted

approximately 50-60 minutes each, giving the respondents ample time to talk, reflect and

discuss the issues that they deemed valuable to raise. The focus group sessions were

performed as an open discussion on the topic, with each participant’s ‘post-its’ as points

of departure. The interviewer was mostly the ‘listener’ who once in a while asked open-

ended questions to follow-up a thought or to ask the interviewees to explore or clarify a

certain issue that was brought out. The questions that were used to follow up issues were

often generic, starting with “can you tell me more about…”, or “how did you

experience…” or “what do you mean by …”. The individual interviews and focus group

discussions were taped and subsequently transcribed by the researchers. The transcripts

were coded and analyzed. The analyses were in turn used to provide guidance for the

‘design’ of the next interviews and field observations. The integrated process of data

collection and analysis can be seen as an iterative activity according to the scheme below:

Coding and Analysis: The first codes were generated through the process of open coding

wherein the underlying meanings of the respondents’ words were noted, coded and

Interview/

Focus group

ocus

F

Coding

Comparative

Analysis +

Integration

Next interview

/ focus group

42

subsequently grouped into what we called here as first level concepts. The respondents’

words, expressions or reported events could vary whilst pointing towards the same

underlying meanings and concepts. These concepts were our basis for comparison. Many

‘concepts’ were brought into the study by the respondents’ themselves when they did the

‘post-it’ exercise, although we looked beyond them for variations in the meanings and to

identify alternative concepts behind the same phenomenon or event that were reported in

the interview. Reported activities and incidents were also observed and compared against

each other to further explore similarities and differences in order to challenge and verify

the evolving concepts with new data (Corbin & Strauss, 1990). The first level concepts

were judged to be relevant or of value in the emerging ‘theory’ if they recurred in a

significant number of interviews, reported incidents and observations. The ‘relevant’ first

level concepts were studied further and compared against each other to identify more

abstract concepts which we called ‘key categories’.

Data Initial codes First level concepts Key categories (see figures 6-8)

During the third week in the field, the researchers decided to limit the focus of the study

to the individuals’ perspective, the concerns of the individuals and not the organization’s.

Thus, the respondents that were identified for further exploration were different members

of the project teams in company X and Z, as well as software developers and/or scrum

masters in a third company (company Q) in the Philippines and a large company

(company Y) in Sweden. The choice of respondents in the course of the study was mainly

influenced by their availability and their relevance in filling in emerging theoretical gaps.

New respondents in the later part of the field work were identified through

recommendations from other respondents as well as through informal conversations at the

cafeteria or staff pantry. Furthermore, specific ‘agile ceremonies’ mentioned in the focus

group sessions and in the interviews were observed in different project teams for

comparison. Incidents were labeled, patterns were noted and the identified concepts and

their relationships were tested against “fresh data” (Corbin & Strauss, 1990). After 8

consecutive weeks of interviews, observations and “field work” in the Philippines, the

‘key categories’ were identified and tested further against data collected from a fourth

company (Y) in Sweden. In companies Q and Y, the interviewer was able to ask more

directed questions wherein the established concepts from the previous interviews were

integrated into the current interview. Five key categories were finally identified and

reached saturation, namely (i) working communication, (ii) self-organizing teams, (iii) a

people-centric organization, (iv) continuous learning and (v) sustaining infrastructure for

implementation.

Collaborative efforts of two researchers: The study involved two researchers wherein

one of the them did the interviews, focus groups and actual “field work” in the

Philippines and the other did the interviews at company Y in Sweden. The interviews

and focus group sessions in the Philippines were all taped and then transcribed by both

researchers as soon as it was possible. All the recorded materials from the Philippines

were sent to the researcher in Sweden the same day they were done. Notes and comments

were exchanged through emails, dropbox entry and Adobe connect. The transcripts (22

individual interviews + 2 focus groups) were initially coded by each researcher. The

researchers ‘met’ afterwards electronically via Adobe-connect to discuss the initial

coding and together analyze the interviews with regards to the emerging first level

concepts, categories and the way forward. The ‘meetings’ normally took place every

43

other day or at least 3 times a week. The researchers worked very closely to each other

involving emails and constant communication in spite of the 6 hours (7 in Nov.) time

difference. Before the interviews in company Y took place, the researchers went through

all the collected data and materials from the Philippine companies including experiences,

observations, codes and conceptualizations, and established the emerging five key

categories and their underlying concepts, which were to be integrated into the last four

interviews at a large company in Sweden. Finally, the interviews at company Y were

performed, and an evolving theory was generated.

The ‘grounded theory’: It is important to take note that the result of this study, the

generated ‘grounded theory’ is a ‘hypothesis’ that is open for modification and could be

completed with further study and application in a wider domain than where it was

generated.

44

4 Empirical Study

The empirical chapter contains the respondents and the company details.

As we stated earlier, Southeast Asia has been a popular offshore destination for software

development. The Philippines is currently one of the Southeast Asian countries that has a

growing software development industry and is “seen as a leading provider of software

development services to the global market, being ranked as the Top 2 Global Outsourcing

Destination by Tholons 2014” (Philippine Software Industry Association 2014). Agile

software development is however still in its youth in the Philippine software industry,

making Agile one of the three main “learning tracks” in the country’s first software

engineering conference of its kind last June 2014 (ibid.).

The empirical study involved 33 individuals in four companies, three in the Philippines

and one in Sweden. The companies were engaged in software development using Agile

project methods in globally distributed teams. The companies vary in size from the

smallest with 78 employees at one location to the largest with approximately 7000

employees worldwide. The second largest had 450 employees, headquartered in Europe

and had also offices in Asia, the UK and the USA, with the biggest office located in

Makati, Philippines. The fourth company had 82 employees and one of the first adopters

of Agile methods in the Philippines.

Description of respondents and companies

Company X, Z and Q are software development companies that are implementing Agile

methodologies at offices in the Philippines for at least 4 years. They are engaged in

offshore software development with clients in the USA, Europe, and Australia.

Respondents from these companies are software engineers/developers, team leaders,

quality assurance engineers, business analysts and scrum masters from the Philippine

offices as well as software development managers/meta-scrum master/agile coach

working mainly at the office in Europe and with regular working visits in the Philippines.

The respondents’ educational background is mainly Bachelor of Science degrees in

Computer Science, Software engineering, and Information systems technology. Several

respondents also have extended education such as Master in Business/Business

Administration and Scrum Master’s certification from the Scrum Alliance. All the

respondents except one have at least one year of experience in globally distributed Agile

software development. Company Y is a Swedish engineering and consulting company

with experiences in applying Agile project methods for more than 4 years. Clients are

spread globally but mostly located in Scandinavia. The education level of the respondents

is Bachelor of Science in computer science or higher.

45

Figure 9. Respondent and company description

The empirical study involved 33 individuals (22 individual interviews and 2 focus

groups with 11 participants) as shown in Figure 9. In company X, all the individuals who

have worked with Agile methods in globally distributed teams were involved in the study

(4 individual interviews and 7 individuals in the focus group). Since the researcher was

positioned for the so-called “field work” in company Z, most of the observations of

formal agile practices therefore took place at company Z.

Company AgilemethodsimplementedTimesinceGlobally-Distributed

Agileimplementa-tionInterviewsconducted Practicesobserved

X (Phils) 2 Developers Sprint Planning

11 have worked with Agile + GSD 1 Quality Assurance engineer -1

Size: 82 employees 1 Quality Assurance Eng. / Business Analyst

Focus group 7 developers

Z (Phils) 5 Developers/Software Eng. Sprint Planning (2)

200 have worked with Agile + GSD 2 Scrummasters/Developers Daily Stand-ups (10)

Size: 450 employees 2 Quality Assurance engineers Retrospectives (2)

1 Business Analyst/Scrummaster/Developer Backlog- grooming (1)

1 Solutions architect Demo (2)

1 Development Director Meta scrum- meeting (1)

1 Release manager/Meta-scrum Refactoring (1)

Scrum Boot Camp (3 days)

Q (Phils) Focus group 4 developers/software eng. Daily Stand-up (1)

58 have worked with Agile + GSD 1 Developer/Software Eng.

Size: 78 employees

Y (Scandinavia) 2 Developers /Software Eng.

Size: 7000 employees 1 Developer /Hardware

1 Scrum master/coach

Scrum + TDD 7 years

Scrum, Kanban More than 4 years

Scrum, Kanban 4 years

Scrum More than 4 years

46

5 Analysis

In this chapter, the empirical data was analyzed and applied to explain the emerging key

categories. References were made to the matrix in Appendix 1, which presented in detail

the underlying concepts that emerged from each individual interview.

The objective of the empirical study was to generate a ‘theory’ on the important factors to

focus on when implementing agile project methods in globally distributed teams. Using

the grounded theory method, five key categories emerged from the so-called theoretical

sampling, which entails the joint collection of data, coding and analysis. These emerging

five key categories were identified as the main concerns of the individuals involved in

implementing agile project methods in globally distributed teams in software

development. The respondents meant that these concerns should be addressed and

resolved in such a way that the implementation of Agile project methods would resemble

the case of a collocated Agile project team. In this section, these categories, their

fundamental characteristics and the subconcepts behind them will be presented and

explained through analysis of the empirical data. The focus is on explaining the key

categories based mainly on the respondents’ input during the individual interviews, with

some references and comparisons to the observed agile practices and the researcher’s

experiences during the “field work”.

5.1 Working communication

In the Agile manifesto, communication is described as a key element for Agile

methodologies. Furthermore it is prescribed that the most ”efficient and effective method”

of communication is through face-to-face conversation (Agile Alliance, 2014). This

means that implementing Agile methods in globally distributed teams entails finding

ways to resolve this challenge. During our research, all the respondents have reflected and

discussed the different aspects of communication from their experiences of Agile

implementations in globally distributed projects. From that we have identified “working

communication” in globally distributed agile teams as a key category. The category has

been generated from the key concepts presented in Figure 10.

47

Figure 10. Working communication

All of the respondents stated that communication is a key for Agile project methods to

function accordingly, the communication needs to be open and honest. Respondents

reflect on the advantages of the synchronous communication. The direct communication

generates a conversation, and takes into account the different views of the different

parties in the communication. E-mail communication is seen as cold and one-sided. Some

of the respondents have pointed out that one advantage with e-mail is to clarify or

determine technical aspects or refer to previous discussions due to language barriers.

“The mental state of sending an e-mail is that you give an order” [Y3SM]

Video-conference is therefore a preferred method of communication, since it adds more

dimensions for the participants. Hearing the voices, seeing the faces and interpreting

body-language create possibilities to understand and read underlying messages as well as

the emotional state of the person they are communicating with.

“Social cues, body posture, tone of voice, facial expressions” [Y4D]

Communication tools (i) (see figure 10) therefore have emerged in the open coding as key

concept. The tools that the Agile teams use are vital to have transparent and open

communication. 17 out of 22 respondents mentioned the importance of this concept (see

Appendix 1). The organization needs to provide the necessary communication channels

and equipment. The speakers, microphones, video-links, internet connection should be of

good quality. Video-conference and telephone meeting rooms are mentioned as good

features. WebEx, Lync and Google hang-out can provide screen sharing features to share

testing and coding in real time. Tracking tools e.g. Jira is used as a tracking tool to

communicate task progress and back-log. Chat and/or Instant messaging is used for low

complexity question and direct answers. The above methods were highlighted as possible

communication methods with advantages and disadvantages. The essential part that the

respondents have highlighted for communication tools is that they are adapted to what the

team needs. That all team members are aware of the tools, the function and are able to

operate them is crucial. The up-time and quality is sufficient so that the communication is

not disrupted or delayed.

“It’s important that you use the right tools and you have the available resources to help you do

your job because it is hard when you just rely on emails or just talking on the phone.“ [X9A]

48

Interaction, customer collaboration and responding to change are key words in the Agile

Manifesto (Agile Alliance 2014). During the analysis, the concept Constant

Communication (ii) evolved. 15 out of 22 of the respondents mentioned this as an

important factor for distributed teams and agile projects methods.

“Thru constant communication, thru constant awareness of what is happening around them… I

think that is the concept of agile where you embrace change” [X10B]

The customers are updated every day on the progress; this generates a feeling of

involvement from the customer side, creates a joint venture and a common goal to work

against. It also ensures an acceptance of understanding and achieving the requirements

that the customers want. Since the customer acceptance is achieved, this clarifies Done

for a task or a feature. In the iterative process of agile and distributed team the constant

communication is a necessity to ensure that Scrum teams are aware of progress and of

new features, if not sufficient there is a risk of re-work, non-value added work, creating

already existing lines of code, or staggering/delaying the progress of a sprint. The

respondents also link this to team or individual motivation, as seen in the citation below.

“They would be very frustrated/…./, they would feel extra left out, because you did not update

them” [X9A]

In relation to constant communication, respondents have also pointed out the importance

of spontaneous or informal communication. Words used in relation to this are building

rapport, team bonding, trust, getting to know him, building relationships. A majority

consider this as a success factor to achieve an effective and well-functioning team. This

will be covered in detail in the category self-organizing teams.

Constant communication in globally distributed teams entails certain difficulties that need

to be considered. From the open coding, three key concepts are defined namely: (iii)

Time Zone difference, (iv) Physical Distance, and (v) Cultural difference (see figure 10).

Time zone differences will affect the possibility to have synchronous communication.

The respondent’s experience is that it is a major obstacle (19 out of 22 respondents

brought this up), not having the same working hours. Time zone difference negatively

influences direct feedback or the possibility to address problems instantaneously. The

working hours that is common for the complete team was defined as “core” time. This is

the time when the working hours are overlapping. To hold an efficient and good

communication, some of the respondents stated that the minimum core time should be 4-5

hours. In the case of less core time it is recommended that an adjustment of working

hours is implemented. Effects of the time difference could impact task dependency and

the acceptable turnaround time.

“But I would not recommend Agile the way we are running today, with a bigger time difference. If

we do not have 4-5 hours overlap time, it is very difficult.” [Z1DM]

Physical distance is a factor that impacts communication. One respondent mentioned that

only few meters or a floor up or down of separation of a team will start to influence the

interaction. Instead of face to face communication team members would start to choose

more indirect communication as e-mail or chat influencing the transparency and the

openness in the information flow. 19 out of 22 respondents have in different ways stated

the effects of the physical distance. Not being able to sit beside your teammate affects the

opportunity to communicate on a daily basis. Face to face explanations of the code or the

49

requirements are not possible. The informal communication to build rapport is limited, in

this case some respondents mentioned after work activities. To mitigate the physical

distance, proposals were: if possible try to choose similar meeting rooms during video

conference to create an illusion of being in the same room, when having birthdays sing

birthday songs, try to play games over the internet or even have lunch together over

video-conference.

Cultural difference is a factor in communication when interpreting different behaviors or

reactions to communication. The respondents said that there are different ways of

communicating if one considers different regions globally e.g. Americans can be very

direct and blunt, Chinese doesn’t want to lose face (they rather say yes than no), Filipinos

acts shy and uncertain. Informal communication or jokes can be considered funny for one

nationality but offensive for another. How one delivers or communicates a message has

an impact on the state of mind of the counter-part. The respondents said that it is

important with inter-cultural training or to have cultural sensitivity in communication in

order to reduce miss-communication. Another approach was the difference in

constructing codes, create ideas, how to do problem-solving and the expectations of how

and when you should communicate. Some of the respondents mentioned that the

communication needs to be assertive, you can’t be afraid of asking if you don’t

understand or not bring your ideas to the table.

“What angry looks like in their area”

“Since I have been working a lot with other nationalities I started understanding that this is the

way they work, this is how they constructed their e-mails. So in time I understand….

communication is the key and you should understand the cultural differences.”

The next key concept is Language barriers (vi). 12 out of 22 respondents considered this

as something that can influence the communication. Language barriers could also depend

on what tools were used. Some communication tools can easily lead to misunderstanding

or even misinterpretations of requirements and features. Respondents mentioned that they

had to adjust from telephone-conferences to e-mails due to language barriers, and that it

took time to learn to interpret the English accent of team members.

“It was really difficult to understand because they have a different way of constructing the

sentence in English….. So you really have to listen carefully to understand… and use a lot of

diagrams and drawings!”

The concept of ineffective communication (ix): Respondents have experienced that the

communication was limited due to team members feeling threatened by GSD, e.g. to

lose work or tasks to low cost countries. This then generated a lack of trust within the

team. Information was believed to be hidden, delaying the progress for the other

teammates. The other recommendation from the interviews was to set a structure or rules

for effective communication. This set of rules on meetings could include: when, how,

which communication tools, and a code of conduct during meetings could increase

communication output of stand-up meetings, retrospective, planning and grooming.

Value driven (viii): This key concept is focusing on value driven customer collaboration

and communication over documentation. The respondents pointed out that the value is in

the working code not in the documentation. The team’s priority is to focus their

communication to the coding and on the requirements so that the code is according to the

customer specification. The documentation can be sent in at a later stage.

50

The concept of conflict (x) was mentioned by the respondents in relation to two factors

that concerns distributed agile teams. One is that a conflict arises due to ineffective

communication and the second is that the conflict resolution is harder due to concepts

(iii), (iv), and (v). Issues and conflicts have to be escalated and raised to the appropriate

level of importance. The conflict resolution should first be done in the teams but if still

unresolved, it should immediately be escalated. One radical way of conflict resolution

was to open up a video-conference link forcing the conflict parties to talk the issues out.

Even if not a consensus was reached, at least a communication flow was initiated.

The key category called ‘working communication’ is clearly a subject that all respondents

see as a crucial factor for implementing agile project methods in globally distributed

teams. Out of the 10 underlying concepts for ‘working communication’, the interview

respondents discussed and pointed out in average 7 of the concepts. The lowest rating for

a single interview had 5 out of the 10 concepts (see Appendix 1).

5.2 Self-organizing Teams

In line with Alistair Cockburn’s words regarding software development as a collaborative

game, the concept of Team is one of the core concepts in Agile project methods,

especially in Scrum.

All of the respondents referred to the concept of Team as a basic concept in agile projects

and agile methodology. The respondents used and expressed self-organizing and self-

managing as interchangeable terms in describing the team’s most important characteristic.

Since all of the respondents in the study were practicing or have practiced Scrum, their

notion of Team was grounded in the notion of a Scrum team. Aside from the

development team, the respondents also identified the client or ‘product owner’, the

quality assurance officers (QAs) and the business analysts (BAs) as members of the core

project team. To be an effective self-organizing team was one of the respondents’ main

concerns in working with globally distributed agile projects. They highlighted being self-

organizing and effective in the sense that the team members agree on how to approach

their work, that they are together responsible and capable of delivering a working

software, that they highly value people and interaction which includes customer

collaboration and they could autonomously adapt to changing customer needs. All of the

above definitely spelled out the values and principles in the Agile manifesto. This was

clearly pointed out by one of the respondents in the following quote:

“I think that’s what separates Agile from other methodologies because it becomes really like a

team effort, to really find solutions to your problems. You create an amazing product together /…/

the sense of team is important because it is there where all the things, and the magic happens. So

if you don’t have that team, it is difficult to work… ” [X10B]

The respondent above continued to talk about the concept of team and self-organizing in

connection with the challenges inherent to global distribution namely time zone

differences and the cultural differences. Several respondents meant that ‘getting to know’

one another outside the working domain and building trustful relationships were

imperative in this regard. However, building relationships and establishing trust takes

time. The respondents expressed in different ways that building and maintaining trustful

relationships needs common time, so called ‘core time’ for all the members of the team to

51

‘meet’ and ‘interact’ which is a challenge in a globally distributed team. The respondent

above raised the need of initiating specific activities to facilitate social interaction and

‘bonding’ between the distributed team members. It was stressed that these activities

have to go beyond the ordinary ‘structured’ teambuilding activities. There has to be

continuous efforts on ‘both’ sides (when the team members are located in two different

continents) to get interested in each other’s lives outside work. This contributes in getting

to know one another as individuals, learn about each other’s goals and motivation in life.

As another respondent put it: “trust in this context is trusting in one’s skills and

capabilities, and desire to accomplish the goal… which is delivering the working

software” [X12D]. All of the respondents stressed that a way of resolving this is to bring

the team members together for a short period of time (e.g. three months) to meet each

other face to face and work collocated as a start-up period in order for new teams to

establish the relationship and the trust. Working visits at regular intervals were also

recommended to maintain the relationship and the trust. Another idea that was tested and

appreciated by one of the respondents was the use of a video conference facility during

the team’s core time at several occasions. The team members that were distributed in two

different locations could see and hear each other in the screen all the time, and thus

experienced the ‘illusion’ that they were collocated. The video conference technology

facilitated the spontaneous social interaction. The fact that they had to rely on technology

for ‘face to face’ meetings was also confirmed by respondents in the focus groups.

Moreover, all of the respondents stated that they had to rely on technology to be able to

perform the Agile practices that were instrumental in building trustful relationships

between the team members. The Agile practices that were mentioned to be essential in

building trust included the constant communication during the team’s core time,

visualizing test results, demonstrating progress in real time, and the team retrospectives.

The importance of the daily meetings, the sprint reviews, demos and the retrospectives in

promoting and establishing trust between the project team members was highlighted by

the majority of the respondents. It was suggested that it would be a great advantage if the

whole development team were collocated and only the clients or the product owners were

in another continent. This would definitely make it easier for the development team to

self-organize their work and perform the sprint activities mentioned above. A couple of

the teams with short sprints (e.g. one week) have decided to adjust the activities

according to their needs, e.g. having stand-up meetings once a week and ‘skipped’ the

formal retrospective session wherein one respondents stated that the reflection and action

plan for improvement could be integrated in the sprint planning sessions. Otherwise, the

majority of the teams have their daily stand-up meetings with members in another

continent using technology (e.g. skype, WebEx, Cisco phones) and their retrospectives

via e.g. video conference facilities and WebEx. The majority of the respondents and

focus group participants understood and embraced the value of the retrospective for the

evolving self-organizing team. In company Z, it was encouraged that the retrospective

should take place outside the office, often in connection with lunch or snack time, which

was very much appreciated by the respondents. This was not possible though for those

who have development team members abroad. The researcher observed that the different

scrum ceremonies were adjusted to the team’s needs, e.g. integrating some aspects that

could enhance the team’s effectivity and self-organizing characteristic. One of the teams

with the product owner in another continent, but all the development team members in

the Makati office, had a special ceremony at the end of the daily meetings wherein four

members of the development team drew specific instructions from a deck of cards. Some

52

of the instructions that were observed by the researcher were: tell a funny or interesting

story, say thank you to anyone that had done something you appreciated lately, ask

someone to tell the group exactly what someone had said during the meeting or accept the

challenge to close an item called ‘hot fix’ within 4 days. The activity was observed to

enhance certain skills (e.g. communication skills, technical skills) amongst the

participants and contribute to a relaxed and playful attitude as well as encouraged

creativity in performing the act spontaneously on the spot. Another team had their daily

stand up via Skype and was observed that one of the participants was in Europe and

attended the meeting from his home. There was a distinct familiarity in the tone and a

sense of belonging when the distant member was sharing as well his personal habitat and

surroundings with the rest of the team.

Cultural differences within the globally distributed team could also entail differences in

e.g. traditions and bank holidays. The respondents, in particular the focus group XF

raised this particular example since this type of differences has a tangible impact on

management of the project activities and timelines. Furthermore, the respondents stated

unanimously that a self-organizing team was expected to manage the requirements, tasks,

testing, meetings etc. everything that one needs to manage in a project, and with no or

minimal intervention from the upper management. And to do this the team needs a ‘core

time’ as well as a shared frame of reference. The concept of shared frame of reference

emerged from the statements of 21 out of 22 respondents. It was referred to as their

shared understanding of the agile values and principles as well as the observed common

team culture which includes professional, social and personal contexts. This team culture

could take the form of lunch or coffee break traditions, different ways of celebrating a

teammate’s birthday, or a unique ceremony for the retrospectives or the daily meetings.

Understanding the Agile values and principles was not enough though. The respondents

bear witness to embracing the agile values which was expressed by the majority of the

respondents in different ways, e.g. “you become flexible, an agile person”, “you always

expect change and adapt to change”, “you look for possibilities and open yourself up to

what else to be done instead of waiting”. It was also highlighted that one does not follow

the ‘book’ blindly, but instead ask oneself ‘”what have I overlooked and what is the most

agile thing to do in this situation?”.

A common ‘culture’ among the team members was acknowledged to be a way of

resolving the cultural differences and at the same time also create a shared team identity

with shared values based on the agile manifesto. The concept of shared identity emerged

from 21 out of 22 respondents’ (see Appendix 1) testimony with statements such as

“If I fail, the whole team fails” or “the team moves as one, we jive together”.

53

Figure 11. Self-organizing teams

Figure 11 above showed the four underlying first level concepts behind the key category

“self-organizing team”. As was discussed above: shared identity and shared frame of

reference were two underlying concepts that characterize the self-organizing team.

Another first level concept behind the key category self-organizing team is Team

composition which was referred to by all the respondents. This concept include two main

subconcepts namely: cross-functional and the ‘scrum master’ role. The concept Team

composition emerged from the respondents’ reflection and discussion of the important

roles in the self-organizing team. To be able to be effective, it was recommended that the

Team should be cross-functional in the sense that the team should have the capabilities

needed to cater for the project needs and to deliver the working software that matches the

client’s requirements. The core project team thus include even the Quality assurance

officers (QAs) and the Business analysts (BAs). The QAs and BAs of the team were

responsible for communicating the clients’ requirements and clarifying questions in order

to ensure that the team understands and could deliver the specified product. One of the

respondents commented on the importance of the collaboration between the development

team and the BA:

“we have to have a constant communication between the development Team and the Product

owner or BAs to make sure that the right level of understanding is there in the elaboration of the

specification during the delivery of the story…” [Z1RM]

Another issue that was raised was the importance of the knowledge and capability of the

team’s BAs to support the team in clearing all the “grey areas” with the client or Product

owner, which entails bridging the time differences and cultural gaps. In many cases in

company Z, the BAs and Product owner themselves were located in another continent. It

was also mentioned by several respondents that the QAs are the quality leaders of the

team. However, it was suggested that everyone in the team has to take responsibility for

the quality of the software and is therefore considered to be a quality officer in general.

“everyone is a QA engineer here including the software engineers…” [Z007]

54

Moreover, it was observed a couple of times during the field work at company Z, that

BAs or POs came to the Makati office to meet the local project team face to face, so that

they can experience working together collocated for a couple of weeks.

Reshuffling of team members was sometimes necessary in order to make sure that the

project needs will be met.

“we should be able to be open to change and be able to adapt to change, and the changing

practices /…/ like every time we have reshuffling of teams.” [Z1MT]

However, a balance between ‘juniors’ and ‘seniors’(e.g. more experienced) was strongly

recommended to enable the team to function with an acceptable team velocity, (a measure

used to assess the effort that a team requires to complete all the features needed within a

given sprint, e.g. two weeks sprint) as well as to facilitate mutual learning opportunities

between experienced and less experienced members of the development team. It was

however pointed out and observed in practice by the researcher that in the agile project

team, members are seen as equals in rank and in their capabilities to influence the project

outcome. In other words, there were no junior and senior members in the development

team, as two of the respondents underlined below:

“/…/ in scrum, the team is self-managing, the team is expected to make decisions.” [Z1SM]

“/…/when I made mistakes which was often, the others also would remind me that it is the team’s

problem not just mine. It’s a sharing of the burden and it is also the sharing of the efforts on how

to finish the development. “ [Z01D]

The self-organizing teams were making decisions and were empowered by their upper

management to make decisions. It has been observed and confirmed by the respondents

that members of the team took responsibility and participated actively in the collective

decision-making process even though they were not collocated, e.g. in doing estimates

for the items in the backlog, formulating user stories, action plan for things that needs

improvement in the next sprint. The physical distance and the time zone differences were

resolved through overlapping working hours and through the use of technology e.g. video

conference facilities, Cisco phones or WebEx. The majority of the respondents admitted

that the overlapping working hours meant extra efforts on both sides. An important issue

that was raised was the willingness of both sides to ‘walk the extra mile’ and secure at

least 4 hours core time for the team.

Furthermore, it was pointed out that although the members of the team had different areas

of expertise, team effort means here that the members of the team are capable of

supporting each other in different ways. The members of a self-organizing agile team

were able to organize themselves, take on different roles and deliver different tasks in

order for the team to be effective during the sprint. This was stressed by the respondents

as an important aspect of agile methods and should be practiced even if the team is

globally distributed. During a backlog grooming and a meta-scrum session, it was

observed that one of the developers automatically took over the role of Scrum Master

when the team’s Scrum Master was on sick leave. Later, one of the team’s QAs led the

retrospective ceremony. The team members then informed the researcher that they took

turns in being a back-up Scrum Master in the absence of the usual Scrum Master. They

55

acknowledged that it is part of the learning process on how to be an efficient self-

organizing team.

“ /…/ the tasks that we do should be cross functional… you can do coding, you can do testing,

you can do requirements gathering as well, you can even lead the team…” [X11C]

One of the difficulties when it comes to the above statement in globally distributed team

was again the different working hours, which poses an impediment with regards to

organizing daily meetings and tasks. The team has to organize the different meetings and

tasks with great care and consideration to the time difference in working hours between

the members of the team. One of the respondents in company Z described a way of

resolving the difficulty when some members were in the Philippines and others were in

Europe:

“/…/If we needed to do critical items, we (in the Philippines) leave that to the latter part of the

day. So we take easier items at the first part of the day and the bigger chunks in the latter part

when we are a whole team…” [Z01D]

It was important for the team to identify in the daily meetings the critical items that need

support from the whole team and see to it that they were handled during the team’s ‘core’

time, which normally was set to at least 4 hours per working day in cases where the time

zone difference was 6-7 hours. It was therefore crucial for the team to have the ‘daily

meeting’ in order to update each other in the progress and to ensure a smooth transition of

work on the items from one part of the day to the other.

Although all the respondents claimed to work with scrum, the roles in the team varied

from one company to another. One of the differences was the presence of a formal

certified ‘scrum master’ in the team. The scrum teams in two of the companies in our

empirical study have specific scrum masters while the other teams organized themselves,

e.g. put the role of team leader/coordinator as one of the items in the sprint backlog so

that one of the team members can pick up the item and take on the role. In one of the

focus group sessions, one of the respondents firmly acknowledged the need for a specific

person to coordinate the team’s efforts. Furthermore, it was acknowledged by the

majority of the respondents that the scrum master / team coordinator role entails

monitoring and visualizing progress, motivating the team members, acting as ‘firewall’

and the team’s champion to the upper management, as well as reenacting the scrum

principles and values during the sprints. It was clearly pointed out by one of the

respondents that the scrum master is not the traditional project manager, but merely a

facilitator.

“The role of the scrum master is to make sure that the backlog is being worked on by the team,

efficiently and less waste”... [Z007]

It was also stressed that the scrum master role was vital specifically for globally

distributed teams in the sense that the scrum master has the task to facilitate building

relationships and establishing trust between geographically scattered team members.

One of the respondents clarified and confirmed the value of a “good” scrum master in a

globally distributed team:

56

“…good scrum masters are really necessary for distributed teams /…/ A good scrum master is

someone who can understand both cultures, and is able to talk to each culture personally.”

[Z01D]

It was also suggested that aside from the technical skills, the scrum master / coordinator

in the team has to have good interpersonal and intercultural skills in order to support the

team’s efforts in building relationships, establishing trust and in properly executing the

different agile ‘ceremonies’, e.g. daily meetings, sprint planning and team retrospectives.

5.3 A People-centric Organization

Agile methods are considered as a “people-oriented” approach to project management

and implementation. One of the respondents concluded that Agile is about people

working together and another respondent added that the focus of agile methods is on the

people and their interaction. The word ‘people’ was mentioned over and over again by the

majority of the respondents, and in particular, the respondents from company Z. In the

context of this thesis, it is about people in different continents working together towards a

common goal. From the statements of the majority of the respondents, it is therefore

important to have the support of a people-centric organization when one is implementing

Agile project methods in globally distributed teams. A people-centric organization invests

in people and in time.

“The value of Agile methods is not what it delivers upfront but what the people delivers over time

and has made better.” [Z1DM]

The key category people-centric organization emerged from four concepts: the agreement

of all stakeholders, capacity building, shared values and working towards shared goal.

Appendix 1 showed that 20 out of 22 respondents have raised the importance of at least

three of these four concepts during the interview.

Figure 12. People-centric Organization

57

By the agreement of all stakeholders, the respondents meant that the global

implementation of Agile project methods was a corporate decision; that it came from the

top and that the people responsible for implementation have the trust and confidence of

the executive level. There has to be an element of an Agile corporate culture. In other

words, there is a shared understanding of the Agile method being implemented, the Agile

values and principles within the whole organization (e.g. development department,

product management, marketing, finance, HR, top-level management) as well as

acceptance from all stakeholders. At company X, it was observed that the 12 Agile

principles were posted on the inside of all the doors of the company restrooms. This was

about opening up and establishing the agile mindset in the whole organization and all

stakeholders. To be able to do this in a global perspective, it was stressed that the

acceptance and support had to come from the top.

“If the top management is not fully aware or fully supportive of agile principles then the people

that are trying to implement it are creating a disconnection between the expectations of the top

level and the behavior and attitude of their staff …” [Z1DM]

Aside from understanding and accepting the Agile values and principles, it is also about

making people learn how to transform values into practice when working towards the

shared goal which is their common definition of a working software. Another important

aspect of Agile project methods is the continuous participation of the stakeholders, in

particular the client, which usually was given the role of the ‘product owner’ in scrum.

According to the respondents, they were often the ones who introduced scrum to the

client. They normally assigned to them the role of the product owner and educate them in

the scrum principles, the practices and the method. Again, it was making all the people

involved in the project, including the client, understand that

“it is having the same goals, making the whole system works rather than clients just answering

questions from the team... it’s more about working together for the success of the project, rather

than they just hire you to do the work.” [QF2]

One of the respondents said that reactions varied depending on the client. Some clients

would say that they are okay with the role but maybe too busy and could not attend the

meetings while others would see the benefits and embrace their roles. The involvement of

the whole organization, in particular the Human Resources / HR-department was

therefore an immediate concern for the individuals in the project teams especially when

the team was not collocated. They stated that the HR-department has the strategic

position to engage in recruitment and capacity building. In other words, they could

support the project teams in recruiting and hiring individuals that possess the capabilities

and potential needed, as well as developing their essential communication skills (e.g.

listening with understanding, assertive communication, questioning skills, giving and

receiving feedback) and educating the organization and stakeholders in the Agile

methods, values and principles. In a global organization, the HR department should think

globally and also work as an Agile team globally to support the globally distributed

project team. It was firmly assessed by one of the respondents that it was difficult to

expand the organization’s operations globally if the issue of capacity building and

competency development is not properly addressed. A people-centric organization thus

has a local and global structure that supports the growth and development of its people

and stakeholders.

58

The respondents’ idea of shared values pointed directly to the Agile values, and most

importantly the mutual understanding that the priority was given to delivering the

working software. Their notion of working towards a shared goal is all about their shared

understanding of the definition of Ready and the definition of Done in Scrum, as well as

the Agile practices which were grounded on the sprints and the sprint goals. It was about

interacting and collaborating closely with the customer who were normally based in

another continent, having a shared understanding of the requirements and delivering the

end product according to the agreed criteria in the definition of Done.

As was mentioned in the beginning of this section, a people-centric organization invests

in people and time. Developing people’s capabilities and maximizing their potentials

were issues that were raised. Aside from learning the Agile methods and practices, the

Agile project team members needed support in developing their innovative problem-

solving abilities, technical skills and other professional skills. In the case of globally

distributed teams, essential transferable skills include intercultural communication skills

and also knowledge about the different cultures within the project team. The people-

centric organization in this context promotes, motivates and supports collaboration and

understanding across different organizational and ethnic cultures, stimulates creativity,

creates a sense of accomplishment amongst the members of the project team, promotes a

team culture by giving recognition and appraisal to teams as well as empowers them to be

self-managing.

5.4 Continuous Learning

The category Continuous learning evolved due to the nature of Agile practice being

responsive to change. The respondents clearly mentioned that learning is a continuous

process in the teams to improve and adapt. All of the interviewees have mentioned one or

several out of the three key concepts (see Appendix 1). Learning and knowledge sharing

are the mechanisms to improve communication, team efficiency, team member skills and

interaction, processes, tools, practices and inter-cultural skills. The three key concepts are

covered in detail below.

59

Figure 13. Continuous learning

(i)Learning cycle

The learning challenge is considered to be a competitive business advantage. Businesses

that have the ability to learn from previous mistakes could adapt, create change and

improve. The feedback loops from the teams require an organization with a management

that is actively listening and considers the suggestions. One of the respondents visualized

the learning process: ‘inspect – adapt – improve’ as an iterative wheel, (see Figure 13).

Several of the respondents pointed out the advantage of the iterative process of Agile

methods, e.g. the estimates for different tasks did get more accurate because of the

repetitive process. The teams learned the process and calibrated themselves with each

other and “reality”.

(ii) Learning process, resolve by just talking,

Retrospective is considered by the majority of the respondents as an absolute must. This

tool is essential to Agility and something that the teams must perform and perform

properly. It is a natural forum for the team’s learning process, to consider what went well,

what went wrong, what can be done differently, and how the team can improve.

“we are constantly evolving and we are learning from our experience and we constantly improve

/…/ Retrospective is very important for the team because that is the way they improve themselves”

[Z007]

Some of the respondents considered the actual projects as a learning experience, where

teams learned to work together and with the client. Since the team is self-organizing and

new teams constellations are common, it is a learning process to set the new culture,

structure, standards in the new teams. In some cases the customer wasn’t familiar with

60

Agile project methods. Then this knowledge was taught to them if the clients were

willing.

“So it’s the team’s way of working” [Z007]

(iii) Knowledge sharing

Company Z had a forum in the global level for Scrum masters to share experiences,

challenges or problems that they have encountered in the team. The retrospective was in

focus and details were shared about how they were carried out and what the outcome was.

They also discussed how to motivate the teams and track motivation. This meeting

occurred every two weeks and was 1.5 hour long. An input for this meeting was a chat

room that was set up where Scrum Masters could openly ask questions. According to the

respondents this was a good environment for continuous learning. It provided

opportunities to cover knowledge sharing of code structure and different features which

are typically complex challenges. Company Z also had set up a Wiki, where people

shared parts of the code and features. When developing new code it was possible to

search the database for equivalent or parts of code to use. This was considered to be an

excellent way of knowledge sharing, though a little time consuming, the return of

invested time had good pay-back.

5.5 Sustaining Infrastructure

The concept of infrastructure emerges from the data as a key category and as a hygiene

factor in the implementation of agile methods. By hygiene factors we mean that

infrastructure creates the necessary conditions for the other above mentioned factors to

work efficiently. In line with Herzberg theory on motivation (Ljung & Jansson, 2011),

hygiene factors are factors that do not contribute to increased motivation for the team if

they are present but if absent they lead to demotivation. The concept of infrastructure

that emerged from the data and analysis embraces three aspects namely: (i) a set-up of

tracking tools for visualization and coordination between team members, (ii) supporting

structures for agile practices (engineering and agile ceremonies), and (iii) standards that is

a set of guidelines, procedures or demands on testing, meeting structure, defined

communication, coding tools, and documentation.

Figure 14. Sustaining infrastructure

61

Summarizing the above mentioned three underlying first level concepts in the empirical

study, the concept of infrastructure in this context can be denoted as sustaining

infrastructure. The structures, once properly employed in practice should contribute to

support and maintain the implementation of agile project methods in globally distributed

teams. To explain the role of a sustaining infrastructure in this study, the characteristics

of the three subconcepts will be further discussed below:

(i) Tracking tools: Implementing Agile project methods in globally distributed teams will

not work without setting up the tools that are needed to manage requirements and

organize the sprint backlog.

“When we talked of globally distributed agile teams, we talked basically about a virtual

workplace /…/ we have to invest in tools and try to find a certain balance between the tool itself

and the agile principle of not relying too much on tools.” [Z1DM]

A virtual task board (e.g. Jira) was identified by the respondents as an essential tool for

Agile methods in order to be able to track issues and “paint a picture” of the team’s

progress for the globally distributed teams. It could also be seen as a virtual place where

the teams see the board of every team and share boards. The globally distributed teams

can then have a daily picture of every other team. A tracking tool is therefore a tool that

enables the teams to visualize the status of every team and what is going on, similar to the

Kanban board concept mentioned in section 2.1.2. This supports transparency,

accountability and provides visibility of progress for the whole team.

“/…/so when the team members in Europe has the need to interact with the team members in

Manila and they want to know where they are, they just need to open the Jira board…” [Z1DM]

(ii) Agile practices: For globally distributed agile teams, all the respondents confirmed

that it is important to have an infrastructure that sustains the core process and the Agile

practices involved. In the empirical study, almost all of the respondents mentioned the

Scrum practices, (e.g. daily stand-up meetings, sprint planning, sprint review,

retrospectives) as well as the engineering practices (e.g. continuous integration, code

review). These practices need to be properly sustained by an infrastructure.

“if a country has infrastructure problems related to the internet, then software developers in that

country would find it hard to work with other countries /…/ we had some problems with that

during [heavy] typhoons when we did not have electricity, and even the internet provider did not

have electricity. “[XF]

With regards to the Scrum practices, the organization has to provide the scrum teams with

knowledgeable and trained scrum masters with good interpersonal and intercultural skills

to facilitate properly the scrum activities and enact the Scrum principles. In company Z, a

meta-scrum structure was further established wherein the scrum masters of the different

globally distributed agile teams form another globally distributed team under the

leadership of the so-called release manager or deployment manager. The meta-scrum

team (with members in 4 different countries and in 2 continents) meets for half an hour

twice a week, as well as performs a release retrospective every six weeks. Examples of

typical themes that are recurring in the release retrospectives are the quality of the

product, and the challenges with the requirements at the global level. All these practices

must also be sustained by a proper networking infrastructure, such as internet with ‘big

chunks’ of bandwidth and effective video conference facilities (e.g. Tandberg system).

62

(iii) Standards. All of the respondents (see Appendix 1) pointed out the need for

standards which dictate a common structure for the teams when they carry out and

manage certain tasks. By standards, the respondents meant a set of guidelines, procedures

or demands on certain tasks and Agile practices. Standards ensure that the teams have a

common ground in performing tasks and practices. There is a common language and

platform in the process level. This could include a set of artifacts that can be used to

communicate with the business people, rules for testing, chosen channels for

communication, schedules for conference calls or establishing codes for certain ‘bugs’.

One of the respondents clarified his notion of standards by saying:

“you have to be able to follow certain guidelines in order to carry out certain tasks /…/ standards

give you a structure towards how you work and manage a project…” [X12D]

One of the issues raised in terms of engineering practices in the globally distributed agile

set-up was “a good level of automation and a good level of toolset accompanying that

automation” [Z1RM]. The respondent pointed out that with the speed of delivery and the

number of people working with the codes at different locations, everything could end up

in ‘chaos’ if there is no acceptable level of automation and the tools that support it, e.g.

automated builds, automated tests. Another example for standards or structure that

supports the globally distributed agile teams is the adjustment of their working hours, e.g.

teams in Manila can start their working day at the latest at 12 noon which would allow

them a ‘core time’ of at least 4 hours when they have team members in Europe. Aside

from standards for mitigating the effects of the time zone differences, the respondents

also raised issues on structures and guidelines for managing the cultural diversity of the

teams, (e.g. vacations, traditions, national holidays) which could have impacts on project

timelines and collaboration. It was stressed that respect for cultural diversity within the

team should be the guiding principle for standards in this regard.

According to the release manager or the leader of the meta-scrum team, his big challenge

today is reminding people of the Agile principles and method, that they should be

working iteratively and should not fall into the Waterfall trap. Standards could provide a

common language for communication, coordination and documentation. In this case, the

respondent talked about a certain level of minimum information / artifacts that he

expected from the scrum masters.

“for each release, each scrum master has to provide me with a sprint planning sheet- that says

that this is a list of resources for the sprint, the specification that is planned for the sprint… in the

same way, that the scrum master at the end of every sprint is updating a global velocity chart, so I

can get a high level view of the how my teams are performing.” [Z1RM]

The sprint planning sheet provides the respondent with the necessary information so he

can review and coordinate the teams’ sprint planning with his specific release planning. It

was stressed that although there are standards in the process level, the teams are still self-

organizing and when implementing have their unique way of working and managing their

tasks. In company Z, the 40-hour week was the standard and baseline for the project

teams. An important principle for the organization is the principle of ‘work-life balance’

which the management associates with the team’s estimates and the team’s sizing of

tasks. In other words, proper sizing of the tasks and correct estimates on the complexity

of the tasks provide the team with the time plan that they needed to deliver the result

without the need to work overtime.

63

6 Discussion

In this chapter, the empirical data is analyzed and discussed in relation to the theories

presented in chapter 2.

It was clear through the respondent’s narratives and responses that they were well-versed

in the Agile manifesto’s values and principles. They always motivate their practices and

behaviors by going back to the Agile values and principles. They refer to agility in terms

of being flexible and adaptable to change, responding to change and being open to change

while delivering value to their clients. Their thoughts and practices showed to be very

much aligned with Conboy’s definition of agility in section 2.1.1. The implementation of

Agile methods in the four companies was mostly the implementation of Scrum with some

adjustments or modifications to provide for the team’s and the project needs. Gallivan’s

six stages of an assimilation process (Gallivan, 2011) could be traced in the respondents’

testimonials and the observations during the field study. The initiation, adoption and

adaptation stages mentioned in the theory could be compared with the process at

company Z, wherein the significant decision of hiring an Agile practitioner and Agile

coach to lead the development department, paved the way for the introduction of Agile

methods and the Agile way of doing things in the organization. The top management

found a ‘fit’ between the Agile methodology and the organizational needs. So the

implementation of Agile methods to GSD was from top to bottom in this case. One could

say that the same applies for company X and Q, a CEO decision was taken. The

difference was however in the adaptation stage, wherein company Z formally identified

individuals and teams in the organization (mostly in the development side), educate them

in Scrum, trained them and equipped them for the task of developing and maintaining the

method. The implementation was defined by one of the respondents as a “big bang”

approach, but small in terms of team size. It was about implementing Scrum all the way

and correctly right from the start. As Wang et al. (2012) predicted, the last three stages of

the assimilation process, namely acceptance, routinisation and infusion can also be

applied to the case of Agile methods and practices. The project teams in the study

accepted and embraced the method, the Agile principles and practices, as well as

modified and customized them into the needs of a globally distributed team, paying

attention to the associated tools and resources to mitigate the negative effects of physical

distance, time zone differences and cultural differences. From the observations and

respondents’ narratives, the teams in the different companies showed different levels of

customization according to the needs of the team, e.g. length of the sprints, daily stand-

up meetings twice a day when the time difference between locations was 8 hours or more,

doing literature studies to explore different and creative ways of doing the retrospectives.

In 2.1.3, a result on the critical success factors (CSF) for agile software development

projects (Tsun & Cao, 2007) showed that these factors were predominantly technical and

people factors. Furthermore, the result pointed out that as long as these critical factors

were fulfilled, the organizational factors have no or little effect on the project success. It

was however highlighted by almost all of the respondents (Appendix 1) that the concept

of people-centric organization was an important factor when implementing agile project

methods in globally distributed software development project. This key category has

64

agreement of all stakeholders, capacity building, shared values and working towards

shared goals as underlying concepts. These concepts assume management commitment

and conducive environment for the team, which are definitely classified as organizational

factors. The respondents believed that the organizational factors have an impact on the

team’s performance and motivation.

Another key category that emerged in the empirical study was the concept of self-

organizing teams. In the above survey on CSF, the ‘high caliber’ Agile team was one of

the critical success factors for agile software projects. Hoda et al. (2012) published a

paper on the team roles that facilitates self-organization (Hoda et al. 2012). Hoda et al.

identified six roles (presented in section 2.1.3). In section 5.2, the respondents stressed

the importance of the scrum master for the self-organizing team. Comparing with the

result presented by Hoda et al., the scrum master role that was described in section 5.2

covers four of Hoda’s six team roles, namely the Champion, the Coordinator, the Mentor,

and the Promoter.

In section 2.3.2, a mapping of communication challenges in Agile DSD with mitigation

mechanisms (Ågerfalk & Fitzgerald, 2006) proved to be very much in line with how the

respondents in section 5.1 resolved their communication challenges. One of the control

challenges mentioned in the article was the perceived threat from low cost ‘rivals’, to

which Hinds & Mortensen (2005) found no mitigating factor in their studied list of

literature. A similar challenge was mentioned by one of the respondents in this study.

The respondent did not suggest any strategy to resolve the issue except her insights on

exerting more efforts on ‘getting to know one another better as a start’, ‘showing interest

in each other as individuals and finding common grounds’. The majority of the

respondents highlighted though the advantages of working with Agile methods in a

globally distributed environment over the challenges. It was mentioned that the tasks and

the working environment contribute very much to their own personal development as

well as professional development, a rewarding and enriching experience since Agile

methods encouraged communication and interaction. One of the respondents stated that

they do not only build software but they also build relationships across continents and

across time. Getting to know other cultures, how others work and approach problems

were amongst the advantages mentioned.

In section 2.3.3, we have the results from Shrivastava and Date on the benefits of

implementing Agile project methods in globally distributed teams (Shrivastava & Date

2010). The Scrum practices and method that the researcher observed in the field were the

sprints, the sprint planning, the daily stand-up meetings, the backlog grooming, the

retrospectives, demos and the meta-scrum meeting. These practices were observed not

only as activities that facilitated frequent and open communication among the team

members and stakeholders, but also activities that together created a holistic structure for

learning and development within the entire organization. The Scrum Guide (Sutherland

& Schwaber, 2013) prescribed four formal events namely: the Sprint planning, the Daily

stand-up, the Sprint Review and the Retrospective to ensure the quality of the inspect-

adapt-improve approach. In section 2.1.4, one of the new challenges that emerged with

the introduction of Agile practices was that “the team does not fully understand the value

of retrospective and practices it as pure routine” (McHugh, O. et al.,2012). The majority

of the respondents in this study however stressed that the retrospective was the most

important event that the team should not compromise with. The respondents expressed a

65

deep awareness of the value of the retrospective for the team to evolve as an efficient

self-organizing team. Amongst others, Scrum masters in company Z reflected and

discussed different innovative ways of performing the retrospective.

Qureshi et al. (2006) investigated the effectiveness of distributed project teams in terms

of what happened when they have to rely on computer-aided technology and electronic

collaboration. (The study’s results were presented briefly in section 2.2.2) The three key

categories that emerged from their study were communication, coordination and

adaptation (Qureshi et al. 2006). In other words, these three aspects could be strongly

influenced by the interplay between the characteristics of the virtual team, the task and

the technology for collaboration. In this study on agile project methods in globally

distributed teams, the agile project teams relied to a great extent on communication tools

and sustaining computer-aided infrastructure for coordination and task management.

However, with our specific focus on Agile project methods, the empirical study

highlighted that the Agile practices, the Agile method’s people-oriented approach and

iterative learning process played a vital role in the effective use of technology. The self-

organizing agile team’s awareness and attitude towards adopting the right tools and

resources in order to ensure that the principles and values in the Agile manifesto were

being transformed into practice were also significant aspects in electronic collaboration in

this study.

7 Conclusions

The main research question in this study is:

What are the important factors to focus on in implementing agile project methods in

globally distributed teams?

Using the grounded theory method, five key categories emerged as the main concerns of

the individuals engaged in globally distributed Agile project teams in 4 software

engineering companies with at least 4 years of experience in Agile software development.

All the respondents, including the focus groups and the field observations uncovered,

supported and explained the individuals’ concerns regarding these five factors that are

important to focus on in the study’s context. Based on the data collected, joint coding and

constant comparison, an analysis of the key categories were presented in chapter 5,

followed by the discussion on the results in relation to existing literature in the domains

of Agile methodologies, Distributed software projects and Implementation theories. The

analysis also included reported incidents and direct citations from the respondents, focus

groups and from observations during the field work, in order to shed light on the process

used to arrive to the categories, as well as explain the characteristics of the concepts in the

emerging ‘grounded hypothesis’. Some of the results in existing literature presented in

chapter 2 were strengthened by the empirical study through further insights on some

specific issues as well as extending and fine-tuning general results on distributed teams to

apply to Agile teams in particular.

In section 1.4, the following objectives of the study were stated:

66

i. to explore and analyze the implementation of agile project methods to globally

distributed teams

ii. to provide a practical understanding of the concept of globally distributed agile

teams.

iii. to contribute in generating a “theory”/ hypothesis on important factors to focus

on when implementing agile project methods in globally distributed teams

iv. to suggest constructive guidelines/framework to future adopters of agile project

methods in globally distributed teams

We conclude that objectives (i) and (ii) were directly and indirectly fulfilled in chapters

4-6, with the presentation of the empirical study, the analysis and discussion that

followed. Objective (iii) is closely connected to the main research question. Taking into

consideration the specific delimitations presented in section 1.4, the study therefore

generated the following grounded “theory” / hypothesis:

The important factors to focus on and the main concerns of the individuals when

implementing Agile methods in globally distributed teams are: the working

communication, the self-organizing teams, the people-centric organization, the

continuous learning, and the sustaining infrastructure for implementation.

The above factors and concerns have specific meanings and explanations in this context,

based on the underlying concepts that were presented and discussed in chapter 5.

Furthermore, the empirical study and analysis in chapters 4-5 also addressed some

general questions that were associated with combining global distribution and the value

statements in the Agile manifesto.

All the respondents except one have at least one year of experience in globally distributed

Agile software development, with the majority having at least 4 years of experience in the

substantive area. They were therefore deemed to be in a position to provide insights, and

guidelines based on their experiences and knowledge of the substantive area. In the end of

every interview, the respondents were asked to finally reflect for a moment and formulate

their ‘words of wisdom’ to amongst others, future adopters of Agile project methods in

GSD. The following set of guidelines or framework represents the core of the

respondents’ response to objective (iv) (a complete list can be seen in Appendix 3):

Working Communication:

o Invest in communication tools (reducing the physical distance, focus on

video-conferencing)

o Find the applicable core time (mitigating time zone difference).

o Set a standard and structure for communication (encourage constant

communication)

o Promote the importance of communication and transparency.

o Involve and communicate with customers/clients about Agile values and

principles.

People Centric Organization:

o Educate people in intercultural skills and communication skills.

67

o Identify and educate skilled Scrum masters

o Explain and educate people to prepare for the change to Agile.

o Ensure acceptance from the majority of the organization.

o Expose involved individuals to the Agile community (conferences,

networks, magazines and so on).

Continuous Learning:

o Ensure that the feedback loop is working and adaptations are done for

best-fit to the organization (teams and personal involvement in

implementation).

Self-Organizing Teams:

o Managers are stepping back from micro management

o Inspire the self-organizing team and provide opportunities for the team to

develop their problem solving capabilities.

o As much as possible, group the development teams in one location.

Sustaining Infrastructure:

o Start small, identify the core tools and processes, and build upon that

after successful implementation.

o All locations should have the same conditions and possibilities.

Other general guidelines that emerged from the respondents’ specific words of wisdom

for future adopters were:

o Implementation will take time, do not expect upfront results.

o Use the agile values and principles as the guide and vision.

o Find a group of ‘local evangelists’ (the scrum masters) in the different

locations. These are the people that will start implementing, develop and

maintain the Agile project methods within the organization, as well as

support the management in addressing issues.

o Create opportunities for visits so the team can work collocated for a short

period of time.

Recommendations for further research: The researchers in this study suggest that the

current study be completed by the organization’s perspective and response to the main

research question in the same substantive area. Another research track is to address the

same research question or explore further one of the key categories above, focusing on

extremely large globally distributed Agile teams.

The five key categories could also provide a research framework for the implementation

of Agile methods to distributed teams in general.

68

69

9 References

Abrahamsson, P., Salo, O. & Ronkainen, J. & Warsta, J. (2002). Agile software

development methods: review and analysis. VTT Publications 478. (2002) Espoo,

Finland.

Allan, G (2003). A critique of using of using grounded theory as a research method.

2003. MCIL. England, UK.

Bird, C., Nagappan, N., Devanbu, P., Gall, H., & Murphy, B. (2009). Does distributed

development affect software quality?: An empirical case study of WindowsVista.

in Communication of the ACM. August 2009. Vol 52.No. 8 pp 85-93

Bryant, A. & Charmaz, K. eds. (2007). The Sage handbook of Grounded theory. 2007.

Sage Publications Ltd. London. Great Britain.

Casumano, M. (2008). Managing software development in globally distributed teams. in

Communications of the ACM. Feb.22008. Vol 51. No. 2 pp 15-17.

Charmaz, K. (2006). Constructing Grounded Theory: A Practical Guide through

qualitative analysis (Introducing qualitative methods series). 2006 Sage

Publications Ltd. London. Great Britain.

Cockburn, A. (2007). Agile Software Development: the cooperative game. Second

edition. Pearson Education, Inc. Boston, MA. USA.

Conboy, K. (2009). Agility from first principles: Reconstructing the concept of agility in

information systems development. in Information Systems Research. Vol.20, No.

3. Sept 2009, pp 329-354.

Corbin, J. & Strauss, A. (1990). Grounded Theory Research: Procedures, Canons and

Evaluative Criteria. in Qualitative Sociology. Vol. 13. No.1. 1990. pp 3-21.

Dingsøyr, T. Nerur, S. Balijepally, V. Moe D. (2012). A decade of agile methodologies:

Towards explaining agile software development. The Journal of Systems and

Software 85 (2012) 1213– 1221. Elsevier inc.

Dybå, Dingsöjr (2008): Empirical studies of agile software development: A Systematic

review in Information and software technology 50 (2008) pp 833-859.

Eriksson, J., Lyytinen, K. & Siau, K. (2005). Agile Modeling, Agile software

development, and extreme programming: the state of research. in Journal of

Database Management 16 (4). 2005. pp 88-100.

Gallivan, M (2001) Organizational adoption and assimilation of complex technological

innovations: development and application of a new framework. Data Base for

Advances in information Systems, 32, 51-85

Gallos, J. (ed) 2006. Organization development. San Francisco USA. Jossey-Bass. A

wiley imprint. John wiley & sons, inc.

Gareis, R. 1990. Management by projects: The management strategy of the ”new”

project-oriented company . in Gareis (ed.). Handbook of management by projects.

Vienna. Manz

Glaser, B & Strauss, A. (1967). Discovery of Grounded Theory: Strategies for

Qualitative Research. 1999 Aldine transaction. Chicago, USA.

Hass, K. (2007). The Blending of Traditional and Agile Project Management. in Project

Management World Today. Vol. IX, Issue V.

70

Hinds, P. & Mortensen, M. (2005). Understanding Conflict in Geographically Distributed

Teams: The moderating effects of shared identity, shared context, and spontaneous

communication. in Organization Science. Vol. 16, No. 3, May-June 2005, pp 290-

307

Hoda, R., Noble, J. & Marshall, S. (2012). Self-Organizing Roles on Agile Software

Development Teams. in IEEE Transactions on Software Engineering, Vol.39.

No.3, March 2013. pp 422-444

Hossain, E., Bannerman, P. & Jeffery, R. (2011). Scrum Practices in Global Software

Development: A Research Framework. PROFES, pp. 88-102, 2011

Jalili, S. and Wohlin, C. (2010). Global software engineering and agile practices: a

systematic review. in Journal of software engineering: Evolution and process

2012; 24:643–659

Jalali, S. Gencel, C. Smite, D.(2010), Trust Dynamics in Global Software Engineering, in

Proceedings of the International Conference on Empirical Software Engineering

and Measurement (ESEM), Bolzano-Bozen, Italy, 16-17 September 2010, pp. 23:1-

23:9.

Ljung, L. & Jansson, T. (2011). Individer, grupper och ledarskap i projekt.

Studentlitteratur AB. Lund. Sweden

Martin, P. & Turner, B. (1986). Grounded Theory and Organizational Research. in The

Journal of Applied Behavioural Science. Vol. 22. No.2.1986. pp 141-157

Mayer, R.C., Davis, J. & Schoorman, F.D. (1995). An Integrative Model of

Organizational Trust. in Academy of Management Review., vol.20, no.3, 1995, pp

709-734.

McHugh, O., Conboy, K. and Lang, M. (2012). Agile Practices: The impact on Trust in

Software Project Teams. in IEEE Software. May/June 2012. pp 71-76.

Meyer, A.D & Goes, J.B (1988). Organizational assimilation of innovation: A multilevel

contextual analysis. Acedemy of management Journal, 31,897-923

Pressman, R.S. (2001). Software Engineering: a practitioner’s approach. Fifth Edition,

2001.

Qureshi, S., Liu, M. & Vogel, D. (2006). The Effects of Electronic Collaboration in

distributed Project Management. in Group Decision and Negotiation 15: pp 55-

75, 2006. Copyright: Springer

Ramesh, B., Cao, L.,Mohan, K. & Xu, P. (2006). Can distributed software development

be agile?. In Communication of the ACM. October 2006/Vol. 49, No. 10

Sharp, H. & Robinson, H. (2006). A cognition account of mature XP teams. In

Abrahamsson, P., Mararchesi, M., Succi, G. (eds). Extreme Programming and

Agile Processes in Software Engineering.Springer. Berlin/Heidelberg.

Sharp, H. & Robinson, H. (2008). Collaboration and co-ordination of mature eXtreme

programming teams. in International Journal of Human-Computer Studies 66.

Sharp, H. & Robinson, H. Petre, M. (2009). The role of physical artifacts in agile

software development: two complimentary perspectives.in Interacting with

computers 21.

Shrivastava, S V & Date, H.(2010). Distributed agile software development: a review. in

Journal of computer science and engineering.Vol.1. Issue 1. May 2010.

71

Sison, R., Jarzabek, S. Hock O.S.,Rivepiboon, W. & Hai, N.N. (2006). Software

practices in 5 ASEAN countries: an explorative study. ICSE’06, May 20-28,

2006, Shanghai, China. ACM 1-59593-085-X/06/0005

Stenbacka, C. (2001). Qualitative research requires quality concepts of its own. in

Management Decision, 39(7), 551-555

Sutherland, J. et al. (2007). Distributed Scrum. Agile project management with

outsourced development team. In Proceedings of the 40th Hawaii International

conference on system sciences 2007.

Sutherland, J (2012): The Scrum papers: Nut, Bolts and Origins of an Agile Framework.

Scrum, Inc. Cambridge, MA. 2012.

Sutherland, J. & Schwaber, K. (2013). The Scrum Guide: The definitive guide to scrum:

the rules of the game. Copyright 1991-2014. Sutherland and Schwaber.

Takeuchi, H. & Nonaka, I. (1986). The New New Product Development Game. Harvard

Business Review, 1986.

Thomas, G. & David, J. (2005). Reinventing grounded theory: some questions about

theory, ground and discovery. in British Educational Research Journal. Vol. 32.

No. 6. Dec.2006.pp 767-795.

Tsun, C. & Cao, D-B. (2007). A survey of critical success factors in agile software

projects. in The Journal of Systems and Software 81 (2008). pp 961-971.

Wang, X. and Conboy, K. Pikkarainen, M. Assimilation of Agile Practices in use.

Information System Journal: 2012; 22: 435–455

Yu, B.L. et al. (2012). Software development life cycle Agile vs Traditional approaches.

In IPCSIT vol. 37 (2012) © (2012) IACSIT Press, Singapore.

Ågerfalk, P.J., Fitzgerald, B. (2006). Flexible and distributed software processes: old

perunias in new bowls?. In Communication of the ACM49(10), pp. 27-34, 2006

Agile alliance. www.agilealliance.org. (accessed 2014-09-15)

Agile Alliance http://guide.agilealliance.org/guide/kanban.html (accessed 2015-01-07)

Agile Alliance http://www.pmp-projects.org/Agile-Manifesto.pdf (accessed 2014-03-

08).

IEEE. IEEE Standard 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary

of Measures to Produce Reliable Software

Merriam Webster, An encyclopedia Britannica company. http://www.merriam-

webster.com/dictionary/agile, (accessed 2014-09-05)

Prikladnicki, R., Audy, J & Evaristo, JR. (2003).

http://www.inf.pucrs.br/~munddos/docs/ICEIS2003_prikladnicki.pdf

Prikladnicki, R, Audy, J. and Evaristo, R. (2003). Distributed Software Development:

Toward an Understanding of the Relationship between Project Team, Users and

Customers http://www.inf.pucrs.br/~munddos/docs/ICEIS2003_prikladnicki.pdf

(accessed 2014-10-29)

Philippine Software Industry Association, http://psia.org.ph/ (accessed 2014-12-28)

Toyota web site,

http://www.toyotaglobal.com/company/toyota_traditions/quality/mar_apr_2004.ht

ml (accessed 2015-01-07)

73

Appendix 1

Figure 15. Matrix of category and concepts linked to open coding of individual interviews.

74

Appendix 2 – Respondent template

Implementing Agile project methods to globally distributed teams

1.) Company:____________________ (x,y,z)

2.) Respondent:_________________ (1,2,3)

2.a) Type of position:_____________________________________

2.b) Agile project experience (number of years):____________________________

2.c) What agile project methods have you used?:____________________________

2.d) What education level do you have?:____________________________

2.e) Previous positions in Agile project methods:_______________________________

3.) Interview:____________________(a,b,c)

4.) Type of interview (focus group, one on one):_____________________________

75

Appendix 3 – Respondent, Word of Wisdom

Words of Wisdom

Q12D Share information and communicate

Inspect that the information is correct and accurate before sharing

Z04D Be open-minded and flexible when implementing Agile methods

Involve the customers and explain what Agile methods are

Z02D & Z03D Set the right mindset in the entire organization, Training/education could be necessary.

It will require time and investments in people, it took at least 1 year for us It will help if the Teams can be together for a period of time.

Z1RM Start small and build your way up

Identify and train up a good set of people

Ensure that all the locations have the same conditions and the people have the “same views all over the world”.

Identifying the core processes and controls that you start with, after achieving that first level, you can put in more “features” and increase with more tools if necessary

Z1MT Be open to change, be able to adapt and welcome change.

Understand cultural differences.

X11C Constant communication and transparency

X10B Open communication with a high level of trust to your team members

Constant feedback, Sense of team is important.

X9A Implementing Agile methods will make "you become a more globally adaptable person"

XF Create a common ground

Always expect change

Same goals

Stick to the Agile practices and principles

Participation of all team members

Learn and accept people’s cultural differences

QF Communication is everything

Sufficient Infrastructure Employ a competent team coordinator to monitor progress and requirements.

Constant communication and planning

DV1 & DV2 Skilled Scrum master. "Role model". Scrum Masters with good soft and technical skills

Be open minded.

76

A team focused organization, no heroes. Prioritize collaboration and teamwork.

Z007 Agree on core time

Cultural sensitivity

As much as possible, group the development team in one location

Z2SM Tools for communication and set up of Core Time

Z1SM Prepare and get acceptance for the change in the organization

Z1DM Value of Agile is not what it delivers upfront but during time and improve it

Focus on feedback. It is not about the planning aspect, it is about the ability to re-plan.

Do not promote practices by the book, step back if it doesn't work

Management must accept and step back, increasing the teams responsibility

Communication tools

Z1AP Exposure to the Agile community, to learn about Agile methods.

Learn about cultural differences. Focus on communication and teamwork.

Z01D Communication Tools - Increase possibilities to have video-conference rooms

Managers encouraging team’s self-managing capabilities

Y3SM Setting up communication flows

Good structures/standards in place

Active listening (also during implementation) so that feedback is handled and implemented

Y2D Organized Scrum Master

Constant communication and customer involvement