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
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
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
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
5.5 Sustaining Infrastructure ... 60
6 Discussion ... 63
7 Conclusions... 65
8 References ... 69
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
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.
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.
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
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
(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.
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:
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.
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.
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
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
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)
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
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
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
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
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.).
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.).
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
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
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
