Knowledge Management in Distributed Agile Software Development Projects

Knowledge management (KM) is essential for success in global software development. Software organizations are now managing knowledge in innovative ways to increase productivity. In agile software development, collaboration and coordination depend on the communication, which is the key to success. To maintain eﬀective collaboration and coordination in distributed agile projects, practitioners need to adopt diﬀerent types of knowledge sharing techniques and strategies. There are also few studies that focus on knowledge sharing in distributed agile projects. This research investigates the knowledge sharing techniques and strategies applied by the practitioners in distributed agile projects. In addition to that, challenges faced by the practitioners during knowledge sharing in distributed agile projects are also identiﬁed and discussed.

Global software development can be described as "software work which is attempted in different geographical locations across the national boundaries in a coordinated fashion, to involve synchronous and asynchronous interaction" [Sahay et al., 2003]. Software developers work with knowledge and are dependent on each other's work. In global software development this synchronization is dependent on KM. Some studies have identified that knowledge sharing is difficult in distributed agile project due to the lack of face-to-face communication between team members Avram, 2009, Holz andMaurer, 2003]. In the agile software development collaboration and coordination depends on communication, which is crucial to successful software development [Šmite et al., 2010]. One of the major objectives of KM is to improve productivity through effective knowledge sharing and transfer [Kavitha and Ahmed, 2011]. So, the success of agile projects relies on effective knowledge sharing among teams.
This research focuses on exploring knowledge sharing in distributed agile projects. More specifically, this research attempts to identify knowledge sharing techniques, strategies and practices that take place between locally and globally distributed agile teams, and the challenges faced by the practitioners in a distributed agile environment. We are driven by the following research questions: RQ1: How do team members contribute to knowledge creation in a distributed agile project? RQ2: How do team members share knowledge in a distributed agile project? RQ3: What are the challenges faced by the practitioners when sharing knowledge in a distributed agile project?

Related Work
Software development is considered to be a complex, knowledge intensive and rapidly changing activity, where a number of individuals, teams and organizations are involved infulfilling common goals, interests and responsibilities [Curtis et al., 1988, Nicholson andSahay, 2004]. Technological and strategic knowledge helps developers to communicate; so it is essential to keep the knowledge stored in the organization for the future reuse. Davenport and Prusak [Davenport and Prusak, 2000] define it as "a method that simplifies the process of sharing, distributing, creating, capturing and understanding the company's knowledge". As the size of the organization grows rapidly, it becomes harder to find out where the knowledge resides. Research shows that if the companies manage their knowledge in a better way, they can increase quality, and decrease the time and development costs [Rus et al., 2002]. To improve the organizational performance, it is important to manage knowledge in a structured way which will help to convey the right knowledge to the right people at the right time. O'Dell and Grayson [O'Dell and Grayson, 1998] discussed that, knowledge management is not a vital methodology; it is a framework, a management mind-set which is based on past experiences and the creation of new wheels for exchanging knowledge.
To foster dynamic knowledge sharing, improve productivity and coordination in software development teams, agile approaches were introduced. Agile teams share knowledge through several practices [Chau and Maurer, 2004]: pair programming, release and sprint planning, customer collaboration, cross-functional teams, daily scrum meetings and project retrospectives. But, the authors [Chau and Maurer, 2004] argue that, these practices are team-oriented and rely on face-to-face interaction between team members. These practices do not facilitate knowledge sharing in distributed agile teams but are effective for collocated and small teams. In one study Dorairaj et al. [Dorairaj et al., 2012] reported that in distributed agile project, team members practice sprint planning, daily scrums, sprint reviews and project retrospective meetings. Distributed agile team members share knowledge through effective use of knowledge management tools like Wiki, pairprogramming and video-conferencing.
Michael Earl [Earl, 2001] has classified knowledge management into three categories: technocratic, economic and behavioral. Earl also divided these three categories into seven schools, Technocratic: Systems, Cartographic and Engineering, Economic: Commercial and Behavioral: Organizational, Spatial and Strategic. Both codification [Hansen et al., 2005] strategy and systems school practice depend on the technology which applies Nonaka's [Nonaka, 1994] externalization conversion technique to convert tacit knowledge into explicit knowledge. Research shows that the technocratic school is closely related with traditional software development and those who are developing software through traditional approaches they are probably benefiting from the technocratic schools ]. On the other hand, behavioral schools are more related with the agile approaches and agile teams are more benefit more from the behavioral school. A survey in traditional and agile companies shows that agile companies seem to be more satisfied with their knowledge management approaches compared to traditional companies ]. In agile software development, knowledge sharing happens through the interaction. Developers share knowledge by working together and through close interaction with customers; and more specifically, pair programming, extreme programming, daily scrum meetings, and sprint retrospectives in Scrum. In traditional software development, knowledge management relied primarily on explicit knowledge but in the agile software development KM relies on tacit knowledge [Nerur et al., 2005]. In agile software development, information radiators and collocating teams are related with the spatial school ].
In traditional software development, knowledge stored explicitly in the documentation, but in the agile development methodology the knowledge is tacit [Kavitha and Ahmed, 2011]. Extracting tacit knowledge to create explicit knowledge is one of the greatest challenges of knowledge organization [Nonaka and Konno, 1998]. Due to the absence of explicit knowledge in the agile software development, experts need to spend much of their time on repeatedly answering the same questions, knowledge is lost when experienced developers leave project, there is less support for re-usability and there is less contribution to organizational knowledge [Kavitha and Ahmed, 2011]. In the agile collocated development, informal communication is the key enabler for knowledge sharing but when an agile project is distributed, informal communication and knowledge sharing is a challenge due to low communication bandwidth as well as social and cultural distance [Maalej and Happel, 2008]. Due to spatial, temporal and cultural factors, communication also becomes aggravated in the distributed settings [Hildenbrand et al., 2008]. Several studies [Holz andMaurer, 2003, Boden et al., 2009] also point out that, knowledge sharing in the distributed agile projects is difficult due the challenges in communication, especially face-to-face interaction between team members in different geographical locations. To address these problems, we investigated how shared knowledge creation and transfer activities performed in the distributed agile projects. Along with that, we also investigated what challenges are faced by the practitioners when sharing knowledge among globally distributed agile team members.

Method & Data Analysis
Because this research addresses an issue "How can we retain the benefits that agile practices provide with respect to KM in distributed agile projects" which is rather under-investigated, this study takes an explorative approach. Exploratory research helps to find out what is happening, seeking new insights and gathering ideas [Marczyk et al., 2010, Runeson andHöst, 2009]. In some qualitative research, data collected through observation or interviews are exploratory in nature. So, extensive interviews are helpful to handle this type of situation [Sekaran, 2006]. This type of exploratory research was also helpful in achieving our goal through analysis of similarities and differences among the cases [Creswell, 2008]. The primary focus of this study was to discover the knowledge sharing activities in distributed agile projects in order to identify techniques, strategies and challenges.

Sampling
The selection criteria for these interviewees were based on the kind of company they work at, the experience of the company in distributed agile development (more than 2 years), interviewee role in the distributed team as well as in the company, project duration and project distribution. The participants of this research were project managers, team leaders, software architects, line managers, senior software developers, system developers and Scrum masters in different countries involved in distributed agile projects, located in different countries i.e. Sweden, Norway, Germany, Ukraine, China, India, Bangladesh, USA, and Latvia. To get the rounded perspective of this research phenomenon we included different roles from the agile team.

Data Collection
There are three types of interview techniques namely structured, semi-structured and unstructured [Flick, 2009]. Due to the qualitative nature of this study we used semi-structured interviews for conducting a series of interviews in software industries involved in distributed agile projects. According to Robson [Robson, 2002], an in-depth semi-structured interview is helpful in finding out what is happening and seeking new insights. Seventeen semi-structured interviews were conducted from seven teams in order to identify how practitioners are creating, storing and sharing knowledge related to software development among geographically distributed agile teams. These semi-structured interviews were a combination of both open and focused questions. It helps both interviewer and interviewee to discuss a topic in more details. Before the interviews started, we discussed about overall goal of this research to interviewee. The interview questions were descriptive and with the base questions there were follow up questions asked based on the discussion. We were concern about some key terms: shared knowledge creation, knowledge transfer, strategies and challenges which later helped us for data analysis and those terms which also evolve with interview questions. We conducted seventeen semi-structured interviews from six different companies. The selected companies are involved with software product development, have different organizational settings and structure and are located in different countries. The duration of these interviews averaged 60 minutes and the interview sessions were tape recorded. Among the seventeen semi-structured interviews, nine were conducted through Skype and eight were face-to-face, depending on distance between interviewer and interviewee.

Analysis and Synthesis
In qualitative research, data analysis is the most difficult and crucial aspect due to raw data sets. According to Basit [Basit, 2003], raw data can not help the reader to understand the social world or the participants view unless such data is systematically analyzed. To organize collected data we adopted thematic analysis [Braun and Clarke, 2006] technique during analysis. Thematic analysis is used to identify, analyze and report patterns or themes within data. It minimally organizes and describes data set in detail. In thematic analysis a theme captures data with relation to research questions and represents them in a pattern within the data set [Braun and Clarke, 2006]. This analysis is performed through a process which maintain six phases to establish meaningful patterns of the data set. Braun and Clarke [Braun and Clarke, 2006] provides an outline through the six phases of analysis. These phases are: familiarization with data, generating initial codes, searching for themes among code, reviewing themes, defining and naming themes, and producing the final report. In the first stage, we transcribed all the collected interview data into written form in order to conduct a thematic analysis. It helped us to identify possible themes, patterns and to develop potential codes [Guest et al., 2011]. Second phase started with initial codes from the extracted data. There are different types of Coding techniques suggested in different studies such as; open, axial, selective, descriptive/topic and pattern or analytic [Miles and Huberman, 1994, Punch, 2009, Shull et al., 2007. In our case, we applied open coding technique and went through all transcribed textual data by highlighting sections of the selected codes. That also helped us to relate coded data with research theme and research questions. In third stage, we analyzed broader level of theme rather than codes that helps to sort different codes into potential themes [Braun and Clarke, 2006].As Braun and Clarke suggested coding as many potential themes/patterns as possible because initially some themes seems to be insignificant, but later they may be important in the analysis process. Later, mind mapping tools were used to represent them into themepiles. This stage gave us a sense of the significance of individual themes. Stage four is reviewing themes. In this stage we identified irrelevant (not enough or diverse) data with relate to different themes and broken down into separate themes. After refining all themes we identified "essence" of each theme and different aspects of the data each theme captures in stage five. At the end, in stage six, we provided extract data with relate to research questions and present some dialog that connected with different themes in support of results and discussion sections.

Validity Threats
To handle validity threats it is important to identify all possible factors that might affect the accuracy or dependability of the results.

Internal Validity
Internal validity for qualitative research mostly relates to the researchers biasness and interpretation of data [Bleijenbergh et al., 2011].For finding a similar knowledge level for our interviewees, we went on interviewee profiles on Linkedin and their years of experience. After finding out the basic information, the interviewer sent a formal email to the interviewee with an invitation letter about becoming involved with this research. To mitigate the threat of following our own bias, interview questions were designed to have a majority of open ended questions. Every interview started with a similar introduction and some clarification questions. Then the recorded interview was transcribed immediately afterward to reduce the risk of missing some information. Furthermore, researchers sent an interview report to the interviewee in order to check whether interview data was correctly transcribed and to confirm the content indicated participants thoughts, viewpoints, feelings and experiences. In qualitative research it is important to understand the interviewee's inner meaning words. To maintain reliability during data analysis we used a thematic, qualitative data analysis technique, that helped to identify, analyze and report themes within data. The extracted data from the transcribed data was checked twice for any discrepancy by two researchers.

External Validity
External validity threat is more applicable to research that are quantitative and which tries to generalize outcome of the research. However, our findings can be generalized only for the agile software development teams which are involved in the development of a shared project from distributed locations.

Results
In this section, we describe different findings (techniques, strategies and challenges) from the seven cases, that promote effective knowledge creation and sharing activities in distributed agile projects.

Knowledge Creation: Locally and Globally
We have found that distributed agile project teams practice different types of techniques for both local and global shared knowledge creation. Pair programming, customer collaboration, Scrum/Kanban boards and community of practice are explicit practices used by the teams to perform both local and global shared knowledge (see in Table 2).

Pair Programming
Pair programming is used for both local and global knowledge creation. From the series of semi-structured interviews we have found that both local and remote team members work together in one workstation to solve specific problems. They help each other to share their thoughts and create knowledge through discussion. In two cases, we have found that teams do not perform pair programming for shared knowledge creation among remote team members. In the Epsilon(ε) project, all development team members are in one site, and for that reason they do not need to perform pair programming for global shared knowledge creation. However, Zeta(ζ) project is a collaboration with a Chinese team on the same product, but the development team does not have any dependency. The development teams working on different modules and later core developers merge all modules together for specific release. But the local teams in Zeta (ζ) project perform pair programming.

Pre-planning game/customer collaboration
In the de-velopment cycle the customer has an important role. Customer collaboration helps teams to build up technical-business col-laboration on a project and also helps to set the direction of the project. In agile software development customers are always involved with the development teams by providing project requirements and performing acceptance testing. Through customer collaboration agile teams participate in creating local knowledge. Evidence was also found from different cases that customers are also involved with the remote development teams to create knowledge through continuous discussion and features feedback. We have also found that customers are involved in issue tracking systems, which helps both the project manager and the developers towards early iteration. In two cases (δandε), we found that customer collaboration performed only in the local sites for shared knowledge creation.

Scrum/Kanban boards
The are two types of boards used by the office to create knowledge and common understanding. A Scrum board is used for teams that plan their work in sprint. A Kanban board is used to manage and construct team work in progress. In table 2 it is shown that, teams use Scrum and Kanban boards for shared knowledge creation among both local and globally distributed team members. In two cases (γandη), we found that teams are using boards both locally and globally. In Gamma (γ) project, the remote team has a sub-Scrum board, which is replica of the main Scrum board. Along with that, the local team (in γproject) upload pictures of the main Scrum board into a repository every day. But in Eta (η) project, teams use a visual Scrum board to perform shared knowledge creation among distributed team members.

Innovation boards
Most innovative ideas are kept in the human mind as tacit knowledge. Due to continuous work loads, sometimes it is impossible to have a discussion with a team member, or other knowledgeable person. So, rather than talking with someone, people share their ideas through the innovation board in an explicit way. In one interview the researchers found that teams are using innovation boards to share their ideas with both collocated and remote team members.

Workshop/Seminars
Weekly or monthly workshops and seminars are arranged through collaboration between business teams, technical teams and customers, in order to share knowledge about projects and the latest technologies. This  Table 2, L indicates Locally, G-Globally and "-" not in practice Dispersed teams-α, β, δ; Distributed teams-γ, ε, ζ; Hybrid team-η kind of workshop facilitates common understanding and communication between different team members. Workshops also help to facilitate tacit knowledge sharing through socialization. In the studied cases, we only observed large-scale teams practicing these techniques locally, to create shared knowledge. Later, the theme of the workshops/seminars was shared among remote team members through repositories.

Community of practice
To succeed in agile projects, learning is an important asset for agile teams. Agile teams practice two modes of learning: peer learning and community learning. In peer learning, team members start learning through interacting and collaborating with team members. Community learning is accessing and conceiving information that is available in knowledge archives or in discussion forums. We found community of practice within different projects, where it performed to share knowledge creation among local and remote team members. We also found that to create shared knowledge, teams perform technical presentations. But these activities are only performed in the local site and later slides or documents are shared among remote team members. Technical forums are also in practice to perform shared knowledge creation between local and remote team members.

Knowledge Sharing: Locally and Globally
Knowledge exchange is always challenging in distributed agile teams due to a lack of face-to-face interaction among team members. Practitioners and researchers are trying to mitigate these challenges by initiating different kinds of techniques and tools. From the studied cases we observed that practitioners maintain different types of tools and techniques to share knowledge among globally distributed teams. Based on the findings, these knowledge sharing techniques are listed in Table 3.
All studied projects are concerned with using repositories to share knowledge between local and remote team members. Most of the task and product related knowledge is kept in the repositories, which are easy to access by the remote team members. Different teams also depend on daily scrum, weekly sprints status, discussion forums, online conferences and common chat rooms to share knowledge between local and remote team members. Electronic boards are helpful for sharing knowledge across remote teams. Only one case was found where knowledge is shared between both collocated and distributed teams through electronic boards.

Repositories
To share knowledge among distributed sites, local teams used different types of repositories like Wiki, JIRA, Redmine, Confluence and GitHub etc. These types of repos-itories provide efficient mechanisms to access codified knowledge. From the gathered data it is evident that (see in Table 3) practitioners are most dependent on repositories to share knowledge among both local and distributed team members.
Wiki, according to Ulrike Cress [Cress and Kimmerle, 2008], provides new opportu-nities to learn and use collaborative knowledge building and sharing, through social interaction and individual learning. In different cases we found that wikis are helpful for starting new threads and discussing issues with other team members. It is also helpful for new team members as it (the wiki ) provides detailed information about features, documents and so forth.
Project and Issue tracking: Nowadays, almost all medium and large distributed or dispersed agile teams are using JIRA/Redmine to track issues, bugs, tasks, deadlines, codes and hours. As collaboration and content sharing tools practitioners used Confluence to share docs, files, ideas, specifications, diagrams and mockups. During the interview one project leader said, ...Most of the time we share tacit knowledge between both local and global teams. After that, the in-   Table 3, L indicates Locally, G-Globally and "-" not in practice Dispersed teams-α, β, δ; Distributed teams-γ, ε, ζ; Hybrid team-η formation is converted through Redmine to make it explicit... Project Leader -Alpha project.
It is also evident that, in one case we found local teams up-load Scrum board pictures, slides and workshop information in the repositories, which is codified and easy to access by the remote team members.

Pair programming
Pair programming plays an impor-tant role in creating and sharing developers knowledge in both locally and globally distributed project. In pair programming, two developers work together at one computer with a common goal [Palmieri, 2002]. In the studied projects, we found teams are using pair programming techniques to share knowledge among remote team members. Team members use Skype to share screens among remote team members. Along with that we also found that teams use TeamViewer and VPN services to share the same computer screen with remote team members, in order to perform pair programming.

Daily Scrum/weekly sprints status/online conferences
Scrum meetings are a source for sharing project progress information among team members. Usually a Scrum standup meeting is held in collocation. From the gathered data we found that distributed teams practice Scrum standup meetings with Internet Relay Chat (IRC), Skype or other group chatting software. Through daily Scrum weekly sprints status/online conferences local teams share knowledge with distributed team members. In one case (ζ), we found that due to less dependency, the development team does not need to perform Scrum meetings/weekly sprint status. But team (ζ) maintain online conferences in order to share knowledge among remote team members (if needed). However, apart from Beta(β) project, other projects explicitly maintain online conferences globally for knowledge sharing among distributed team members.

Common chat room
Common chat rooms are useful for exchanging knowledge among distributed teams. From the empirical findings we observed that for faster and quicker communication among distributed team members, medium-and large-scale teams maintain common chat rooms.
In one case, a software architect said that ...the Sprint management system handles all task related knowledge but for the domain related knowledge sharing we maintain a common chat room, which helps us to resolve specific problems within a short time -Software Architect, Delta project But, in another case we found that, it is not an efficient way to communicate among distributed teams due to language barriers, common understanding, technological factors and so forth. Frequently misunderstandings occur and things go wrong. To mitigate these types of problem, practitioners also suggested different types of mitigation techniques.

Technical forum
The idea behind a technical forum is learning through sharing knowledge. Technical forums are like communities of practice which create a network between technical team members. They are self-organizing groups that consist of individuals who share information, experience and technical skill on a specialized discipline [McDermott, 1999]. Technical forums assist distributed teams in quick problem solving and reduce development time since team members do not get stuck on recurring issues. Building trust between team members in the distributed environment is challenging; so knowledge sharing through technical forums can build trust between developers. Technical forums help to create and share both local and distributed knowledge. We have found that large-scale team members practice technical forum techniques to share knowledge among remote team members.

Electronic board
The office boards hold a lot of knowledge which is difficult to share among distributed teams. The interviews revealed that practitioners are using electronic boards to share and access knowledge both locally and globally. Electronic boards hold the tasks list to perform , latest information and along with that necessary technical and business information are regularly updated in a wiki. Electronic boards help to decrease the communication overhead.
In one case an interviewee said ...I am not satisfied with the current tools; Its tough to describe designs to new team members. Visual aids are helpful during discussions -Project Manager, Beta project.

Rotation/Visits
The primary intention of team member rotation between different sites is knowledge sharing. Due to frequent face-to-face interaction with product owners, onsite team members get more business and domain related information than offshore team members [Sureshchandra and Shrinivasavadhani, 2008]. A lack of face-toface meetings and poor socialization also causes a lack of trust among distributed team members [Moe anď Smite, 2008]. Rotation between on-site and distributed team members promotes the sharing of business and domain related knowledge across the teams. From the data gathered we found that, both distributed and hybrid teams visit remote sites and rotate team members to increase the trust and communication bandwidth between team members. But the studied dispersed teams never visit and rotate with remote team members.
One of the distributed teams line managers said, Visits to remote sites are highly costly. So, we rotate team members and mostly, the duration of the rotation between team members is 3-6 months. -Line Manager, Zeta project We have also found that teams practice version control, screen sharing and discussion forums to maintain knowledge sharing among both local and remote team members.

Challenges faced by practitioners during knowledge sharing among distributed teams
In agile software development most of the knowledge is tacit, which resides in the human mind rather than documentation. This codified tacit knowledge is shared among between locally and globally distributed team members through tools. The knowledge sharing approach varies between team members due to experience levels. The types of problem this leads to are search availability and difficulty finding the right knowledge at the right time. We have also found that to share tacit knowledge between remote team members, teams maintain a common chat room and online conference (see in Table  3). In one project (β), we found that the team does not share tacit knowledge among dispersed team members. But, based on the situation, sometimes the team performs pair programming through screen sharing, to resolve problems. Challenges faced by the practitioners during knowledge sharing among distributed team members are shown in Figure1 Dispersed teams-α, β, δ; Distributed teams-γ, ε, ζ; Hybrid team-η

Fig. 1 Knowledge sharing challenges and mitigation techniques
In Figure 1, arrows indicate the mitigation techniques ap-plied by practitioners for a specific challenge. Based on the severity of communication, language and cultural challenges frequently faced by practitioners during knowledge sharing in distributed agile projects (see Figure 1). Distanced teams are also struggling with misunderstanding and visualization challenges.
Not satisfied (0-3), Satisfied (4-6) and Highly satisfied (7-10) Dispersed teams-α, β, δ; Distributed teams-γ, ε, ζ; Hybrid team-η Though teams face different types of challenges during knowledge sharing among distributed team members, we identified successful knowledge sharing in both locally and globally distributed agile teams from the seven cases studied. Based on the seven cases the above graph (see Figure 2) has been drawn. An ordinal scale is used to map the interviewee satisfaction with their KM activities in both local and global teams. Figure 2 depicts that in project (Alpha) interviewees think knowledge sharing activities are more successful among distributed team members than in the local team, due to language barriers (non-native English speaker ) between local team members. It is also evident from the gathered data that dispersed feature teams are more successful in their knowledge sharing among distributed team members than distributed and hybrid teams.
6 Lesson Learned

Codification of Knowledge
According to Polanyi [Polanyi, 2009], Individuals know more than they can say. Polanyi classified human knowledge into two categories. Tacit knowledge, which is very difficult to describe or express: this type of knowledge is transferred through demonstration. Tacit knowledge has an important cognitive dimension which consists of mental models, beliefs and perspectives [Nonaka, 1994, Bennet and Tomblin, 2006, Nonaka, 2007. So it cannot be easily characterized by clear expressive language. Explicit knowledge, is easily written down and codified. It is easily possible to characterize explicit knowledge in textual or symbolic forms. This kind of knowledge resides in textbooks, memos and technical documents. Codification of knowledge is the conversion of tacit knowledge into explicit knowledge in a written, verbal or visual format. The extraction process of tacit knowledge into explicit is called externalization. Tacit knowledge cannot be interpreted fully even by an expert [Ahmed et al., 2012]. This type of knowledge is more deeply placed in action and is hard to express in words [Hislop, 2002]. Nelson et al. [Nelson and Winter, 1982] conclude that it is impossible to describe all the necessary aspects of organizational tacit knowledge for successful performance. In organizations, most of the tacit knowledge is work related, which is learned informally as the team works [Wagner and Sternberg, 1987]. Codification extract tacit knowledge into explicit ; it is a challenging task, so an expert needs to understand the essence of the tacit knowledge in order to increase the degree of explicitness of knowledge. Surprisingly, we found from our results that all studied cases are concerned about knowledge codification. To codify tacit knowledge, teams are using Wiki, JIRA, Confluence etc. In local sites, technical presentations and discussion forums are also taken into account as knowledge codification strategies. Later, teams share codified knowledge among remote team members through repositories and that is helpful for the remote team members to reuse codified stored knowledge.

Knowledge Management Strategies in Practices
We found that knowledge management schools are in practice, according to the results in Table 2 and 3. We used Earls [Earl, 2001] framework to select types of strategies, "schools" or practices in the different projects that applied to managing knowledge locally and globally.
Based on the evidence from the different cases, we found that knowledge management schools were in use to manage knowledge both locally and globally. It is also evident that systems, cartographic, engineering, organizational and spatial schools are practiced in distributed agile projects to manage knowledge both locally and globally. Both commercial and strategic schools are focused on a business perspective (patent, copyright, trademark, know-how and intellectual assets [Earl, 2001]) and there is also no evidence found within gathered data sets that indicates those schools (commercial and strategic) are in practice. For that reason those schools are not taken into account in this research.

Systems school
This schools philosophy is to codifying knowledge with the help of technology. Organizations use repositories for storing and sharing knowledge. These knowledge repositories usually store domain specific information. The codification of knowledge can be compared with  . It is easy to realize the benefits of knowledge bases and the systems school is the most researched school [Bjørnson and Dingsøyr, 2008]. These knowledge bases become richer and more useful over time. As shown in the Figure 2, the systems school is in practice in all cases to manage knowledge locally and globally. Though search functions are a difficult issue in the systems school, practitioners depend on it because across distances this school effectively perform knowledge sharing activities using repositories.

Cartographic school
This school focuses on the mapping of organizational knowledge and aims to build knowledge directories by disclosing who knows what [Earl, 2001]. This is some-times achieved by yellow-pages, which ensure the accessibility to others of a knowledgeable person within the organization for knowledge exchange. Though knowledge maps and directories on company intranets might be helpful for distributed team members to have an idea of who knows what, in distributed projects it seems challenging to put into practice. This is because it needs joint effort and commitment from both local and remote team members. In collocation, it seems easier to find a knowledgeable or experienced person because they knew each other well. In globally distributed projects who knows what and what is where are important issues for effective knowledge exchange. We have found that the cartographic school is practiced by different projects (δ,ζ,η) to exchange knowledge both locally and globally. This strategy is also practiced in different companies by introducing the idea of knowledge brokers: this helps other developers to consult with knowledgeable and experienced software engineers [Schneider, 2009]. Knowledge brokers are knowledgeable and experienced software engineers who will communicate with other developers, provide them with information or listen to them.

Engineering school
This school of knowledge management focuses on business process re-engineering [Bjørnson and Dingsøyr, 2008] and knowledge flows in organizations. This school has a more empirical attention than other schools, which focuses on managing knowledge about software development processes and improvement of software development processes. More specifically, this school focuses on formal routines, mapping of knowledge flows, project reviews, and social interactions. Software process improvements like CMMI can be regarded as a stimulus for knowledge flow throughout the organization. This school supports explicit knowledge sharing and in distributed projects, temporal distance does not affect this school. In globally distributed projects coordination is one the major challenges and the engineering school focuses on the coordination process and aims to ensure knowledge flows within the organization though shared databases. The processes of using tools (i.e the installation manual for GitHub or SVN with eclipse), quality code writing techniques, testing and reviews are all documented in repositories to share among distributed teams. Practice of this school is found in the studied projects.

Organizational school
The philosophy of the organizational school is to create a network by collaborating between communities to share or pool knowledge. This school of knowledge management focuses on organizational structure. These structures are often referred as "knowledge communities" [Bjørnson and Dingsøyr, 2008]. This is a networking approach for people to communicate and share knowledge. Based on the seven cases, this school is in practice for knowledge sharing both locally and globally.

Spatial school
The intention of the spatial school is to encourage socialization (tacit to tacit knowledge) as a means of knowledge exchange [Lloria, 2008]. The spatial school is more concerned with the development and utilization of the social capital which develops from people interactions, formal or informal, repeatedly over time [Earl, 2001]. The spatial school focuses on designing office space to promote knowledge sharing ]. Organizations use different office settings to promote communication between people. For example, in the case of software organizations agile methodologies may use boards, charts or other tools to create spatial knowledge. Sometimes, even common spaces like conference rooms, dining rooms or places for refreshment and activities are also places where knowledge can be shared. Five cases were found that practice the spatial school to manage knowledge locally and only one case (hybrid team,η) was found that to practice the spatial school to manage knowledge both locally and globally. The hybrid team uses visual boards to communicate among collocated and distributed team members.

The Process of Organizational Knowledge Creation
Knowledge creation is continuous and dynamic process; and people are benefited from that through sharing and interacting with each other [Ernst and Kim, 2002]. Based on explicit and tacit knowledge, Nonaka et al. proposed dynamic knowledge creation model [Nonaka, 1994]. In this model, the authors discussed about four types of knowledge conversion modes. The conversion mode between tacit to tacit called socialization, between tacit to explicit it is called externalization, between explicit to explicit it is called combination and between explicit to tacit it is called internalization. Each modes can independently create knowledge.

Socialization-tacit to tacit
Socialization facilitate to share tacit knowledge through shared experience. In this context, the learning process start through observation, interaction and practice. So, as a result of this process technical skills and mental  aka, 1994] models are created and shared. Trust is the main ingredient in order to foster socialization (social interaction) in the organization [Nonaka and Takeuchi, 1995]. The main intension of the tacit knowledge is to learn and gain experience from others; so knowledge is created by learning during the discussion in front of coffee machine, meeting, training and team work [Nonaka, 1994] [Bolisani andScarso, 1999][Haldin-Herrgard, 2000] [Marwick, 2001]. In this research, we have found, team members share theirs knowledge infront of coffee machine. All studied projects share tacit knowledge among both collocated and distributed teambers.

Externalization-tacit to explicit
The extraction process of tacit knowledge into explicit is called externalization. In this book [Ahmed et al., 2012] the authors claimed that, tacit knowledge cannot be interpret fully even by an expert. This type of knowledge is more deeply placed in action and stiff to express in word [Hislop, 2002]. Nelson et al. [Nelson and Winter, 1982] conclude, it is impossible to describe all necessary aspects of organizational tacit knowledge for successful performance. In another research Wanger et al. [Wagner and Sternberg, 1987] mentioned, in the organization most of the tacit knowledge is work related that is learned informally during the team works. Codification is challenging to extract tacit knowledge into explicit; so an expert needs to understand essence of the tacit knowledge to increase degree of explicitness of knowledge. Through this study we have found, nowadays, almost all small, medium and large scale soft-ware development firms start using tools 3 to facilitate explicit knowledge sharing throughout the both collocated and distributed teams. Experience team members helping each others indirectly 4 with their experience is the distributed environment using those tools, by the problem solving, manual creation and individuals internalize what they experience.

Combination-explicit to explicit
The conversion strategy of existing explicit knowledge into new explicit knowledge is called combination. In the organization it is happen through meeting and conversation. The main intension of combination process is to manage all unstructured knowledge into one place by sorting, adding, categorizing and defining context. This process will help the team members to get right information at the right time. In the distributed environment team members might benefited from this process.

Internalization-explicit to tacit
Express explicit knowledge and convert it into tacit knowledge is called internalization. People read documents previously stored knowledge from the repositories and try to learn from that to enhance their existing knowledge. By applying this process explicit knowledge become tacit and it helps if knowledge is verbalized in documents and expressed through oral stories.
6.4 A Relation with the concept of "Ba" [Nonaka and Konno, 1998] Japanese philosopher Kitro Nishida originally proposed this "ba" concept, "Ba" means place [Nonaka and Konno, 1998]. This space can be physical (i.e. office, dispersed or distributed team), virtual(i.e. email, teleconference), mental (i.e., shared experiences, idea), or any combination of them. Ba consider as a shared space that servers as a foundation for knowledge creation. In this research, we have found that, practitioners also apply ba through spatial school. The intention of the spatial school is to encourage socialization (tacit to tacit knowledge) as a means of knowledge exchange.
3 wiki's, redmine, JIRA etc. 4 Reading and listening to success stories make people feel the truth and root of the story [Nonaka and Takeuchi, 1995] [Nonaka and Konno, 1998] 6.5 Shared Understanding between team members Sucessful development and deployment depends on the shared understanding between stackholders and software engineers. According to Martin et al. [Glinz and Fricker, 2014], there are two types of facts among group of people during shared understanding: explicit shared understanding(ESU) which denotes requirements, design documents, and manuals. Implicit shared understanding denotes the common understanding of nonspecified knowledge, such as assumotions, opinions, and values. Organization that facilitate values, structures, and practices that helps to coordinate and communicate with team members effectively. During this study, we have found, studied projects apply "Pair programming, customer collaboration, technical presentation and so forth to establish shared understanding among distributed team members. In addition to that, we have also observed that, team also apply both tacit and explicit knowledge sharing strategies to build shared understanding among distributed team membres as in software engineering both strategies implies shared understanding.
Martin et al. [Glinz and Fricker, 2013] identified the enablers and obstacles for shared understanding. Domain knowledge, Previous joint work or collaboration, Existence of reference systems, Culture and Values, Geographic distance, and Trust are enable and foster shared understanding. Contractual situation, Outsourcing, Regulatory constraints, Normal vs. radical design, Team size and diversity, and Fluctuation are an obstacle to both implicit and explicit shared understanding. Achivinging shared understanding among distributed team members is not easy though. To achive shared understanding among distributed team members its required to overcome obstracles and enable the knowledge shareing and creation techniques to establish shared understanding.

Summary
The aim of this research was to discover the knowledge sharing techniques, strategies applied and challenges faced by the practitioners in distributed agile projects. To perform knowledge management activities in a distributed agile project, different teams practice different types of approaches. But, in general, we found that different types of knowledge creation and sharing techniques are applied by practitioners to perform knowledge management activities in distributed agile projects. Along with that, we also found different types of strategies practiced by the team members to manage knowledge both locally and globally.

Contributions
For the first research question, we found that: -To perform shared knowledge creation in a distributed agile project, team members practice: pair programming, customer collaboration, Scrum/Kanban boards, innova-tion boards, workshops/seminars, learning, technical pre-sentation and technical discussion techniques. -In globally distributed agile projects, teams practice dif-ferent types of strategies to perform shared knowledge creation such as: systems, engineering, organizational and cartographic schools. We observed that the spatial school is in practice for local knowledge creation but when the project is distributed, this school is used less due to expensive tools.
For the second research question, we found that: -To share knowledge among distributed sites, team mem-bers practice different type of techniques: repositories, pair programming, version control, screen sharing, daily scrums, weekly sprint status, common chat rooms, technical forums, discussion forums, electronic boards, online conferences, rotations/visits etc. -Systems, engineering and organizational school strategies are explicitly in practice to share knowledge among distributed team members. These strategies foster effective knowledge sharing activities for team members in distributed agile projects. In distributed development, who knows what and what is where need to be known by employees, for effective knowledge sharing: this is associated with the cartographic school. But, in distributed agile projects, this school has is used less due to social-cultural distances. The spatial school facilitates knowledge sharing by using office space but in distributed agile projects this strategy is not explicitly in practice to share knowledge among remote team members.
For the third research question, we found that: -During knowledge sharing among distributed team mem-bers, practitioners faced different types of challenges, such as: language, communication, misunderstanding, vi-sualization, cultural, technological, time zone difference and lack of information. -To mitigate those challenges, practitioners also apply different types of mitigation techniques, such as: informal communication, cultural exchange, common platform, tools, visual prototyping, common chat rooms, rotation, and overlapping hours.

Future Work
Through a series of semi-structured interviews from agile practitioners, we investigated knowledge sharing activities in distributed agile projects. Communication, coordination and collaboration are the keys to fostering knowledge sharing between team members in agile software development. However, we have seen knowledge sharing in distributed agile projects is challenging, due to factors such as communication difficulties, language barriers and cultural barriers. To mitigate those challenges and succeed in knowledge sharing within and across borders, practitioners adopt different types of techniques to manage knowledge both locally and globally. Along with these techniques, we have also noticed that, practitioners adopt different types of strategies to manage knowledge both locally and globally. Though systems, engineering and organizational schools are explicitly in practice, the spatial school has less concern with managing knowledge in distributed agile projects. With closer observation between software engineering and schools Bjørnson and Dingsøyr found that there is a heavy focus on the systems and engineering schools [Bjørnson and Dingsøyr, 2008]. There are also limited number of studies focusing on the organizational school, but no studies in software engineering were found, that focus on the spatial aspect [Bjørnson and Dingsøyr, 2008]. Agile software development is more related to socialization, which includes the spatial schools concepts of knowledge sharing strategies. There is a lot of knowledge residing in the office space and office space fosters knowledge sharing through spatial knowledge management strategy. In the future, it will be interesting to find the spatial school being practiced in distributed agile projects.

Acknowledgement
We are thankful to our dear supervisor Dr. DarjaŠmite, Associate Professor and this paper also published as a Blekinge Institute of Technology's Master thesis of 1st and 3rd authors in 2013.