Distributed Agile Patterns-Using Agile Practices to Solve Offshore Development Issues

As offshoring is becoming mainstream, companies are moving towards using agile methods. Offshoring has many advantages such as reduced development cost, proximity to market and round the clock development, it has created new challenges for the application of agile practices as the teams are now distributed. Companies are adapting and modifying agile practices in order to overcome these challenges. However, little effort has been put into identifying common practices, which are being repeatedly, used to solve frequent problems in offshore development. In this research, we have studied from literature over 200 cases and have interviewed professionals participating in distributed offshore teams. Based on the observations, we have designed a solution known as Distributed Agile Patterns, which will address the common issues in offshoring scenario. Fifteen distributed agile patterns have been identified and classified into four categories based on the type of problem they solve. A reflection workshop was conducted where professionals were invited to review the pattern catalogue and help us verify and validate the catalogue. Based on their feedback, the catalogue was finalised. The purpose of the catalogue is to serve as a guideline for practitioners to use to aid them in adoption of agile practices in offshoring.


I. INTRODUCTION
Offshoring work is not a new concept; many companies from cleaning services to consultations have been using it [1]. However, offshoring work internationally has increased with the help of technology as it can cut down communication cost with the help of online tools, allowing companies to work with remote teams at cheaper rates efficiently [2].
In the past mostly manufacturing companies were using offshoring, however, with cheaper and faster communication many companies from other sectors started to move towards offshoring [3]. Similarly, offshoring is changing how companies develop software. Reduction in cost is the main reason why companies opt for offshoring, which is mainly because of lower salaries in comparison with counties such as Europe, the US and Japan [4]. For example, companies would be 80% more economical to offshore work from UK to India [5]. Apart from the cost there are some other advantages to offshoring as well i.e. access to a pool of skilled people in a country like India that profits 90% from IT revenue as it produces 2 million university graduates per year [6]. When The associate editor coordinating the review of this manuscript and approving it for publication was Porfirio Tramontana .
Kobayashi-Hillary went to Bangalore to start a company he states that the issue was now to separate an excellent resource from a good resource [6]. Another advantage is proximity to markets and customers [7], [8].
Due to the distribution of teams over different geographical locations arises the issue of trust, socio-cultural, communication and co-ordination, and knowledge transfer [8], [9]. These issues affect the working of distributed teams, which in turn affect the applicability of agile practices i.e. agile highly depends on face-to-face communication, which is not possible in distributed scenario.
Many teams have tried to experiment and adapt the agile practices to avoid the above-identified challenges however such efforts were individual and difficult to share with practitioners. This paper provides solutions to some of the challenges by identifying agile practices, which address these issues repeatedly in offshore scenario. We believe that by identifying and cataloguing such practices, practitioners can easily retrieve and apply them in similar situations. The solution is represented as the distributed agile patterns. We show that with the help of patterns, practitioners will be able to adopt agile easily for offshore development.
Agile offers disciplined yet lightweight processes and since the formation it has changed how software is developed [10], [11]. The agile manifesto emphasises on customer satisfaction. It focus on keeping the customer satisfied and nowadays many companies are selecting agile to develop software [10]. It is observed that around 84% of the organisations are still maturing their agile practices and creating opportunities for growth [12].When companies opt to offshore software development, it is considered as a risk to cut down on cost of software development [13]. Such companies use agile methods to attain better planning and execution of the project [14]- [16].
Ghani et al. [17] stated, that in order to apply agile in offshore development companies need to overcome the 5 challenges that are communication, coordination, cooperation, collaboration and control. Similarly, Taylor et al. [18] states that in order to use agile processes in offshore development, projects have to undergo many variations in development practice such as communication becomes more formal, teams have to self manage between different offshore teams and cross-functional teams can be difficult to control [19]. Many systematic literature reviews have been conducted to study the use of agile practices in global software development [20]- [22]. It is clear that due to differences in offshore development, the use of agile in offshoring is not an easy process and many companies that opt for offshoring, customise agile processes in order to avoid offshore challenges.
An empirical study on the challenges of agile offshore development in which 334 practitioners took part, agreed that in order for agile to be successful for offshore projects, managers have to focus on choosing a team that is technically competent, effective in communication and coordination with the customer and continuously engages with the customer throughout the project and needs to manage a low staff turnover in teams [23]. Similarly a comparative analysis done on in-house and offshore development using agile methods to code and design software showed that companies are more comfortable to migrating to agile if it is applied to only one phase [24]. Efforts have been made to overcome the offshore challenges such as cultural differences. Šmite et al. [25] believes that by solving the challenges caused by cultural differences collaboration among the onshore and offshore team can improve.
The article is organized as follows, section II discuss the offshore software development challenges and how these challenges affect the agile principles. Section III presents the current work done on patterns and gives the overview of distributed agile patterns while section IV explains the research methodology used for the identification of the distributed agile patterns. Section V lists the results of the study, while section VI mentions the threats to the validity of the results and section VII, concludes the study.

II. CHALLENGES IN AGILE OFFSHORE SOFTWARE DEVELOPMENT
In this section the inherent challenges of offshore development have been identified and how the challenges affect agile practices. While conducting an extensive literature review on offshoring, many challenges were identified which we classified into four categories which are trust, socio-culture, communication & coordination, and knowledge transfer as most of them overlapped these four areas. These challenges occur when the teams are distributed over different time zones. The challenges have also been observed to affect agile adoption in offshore scenario. By classifying the challenges we can map their effect on different agile practices, this will help in constructing patterns that will solve them.

A. INHERENT CHALLENGES OF OFFSHORING
The Table 1 elaborates the results of a study that was conducted in which the inherent challenges of offshoring were identified. It shows how frequent the challenges occur in literature. The first column categorised the offshore challenges and in the second column provides the evidences from where the challenges were identified. The studies, which were selected for evidence, have been presented as additional material to this paper and it is available online here: https://cutt.ly/YWLRyYQ As one of the main challenges in offshore development is trust [26]- [28] it is important to establish trust among firms for successful partnerships and alliances [29]. Trusted partnerships enable open exchange of information, which helps improve the response to any crises, which may occur during the executions of a project [30]. While realizing that trust is important in offshoring, it is difficult to establish, as it is difficult to trust unknown foreign partners, which are in different time zones [31]. Despite this difficulty, cooperating with foreign partners is very important and without trust, organisations tend to divert the responsibility rather than accepting ownership [32].
In offshore software development, socio-cultural issues arise due to differences in language, national traditions, values and norms, which adds another challenge to offshore development [19], [26], [33]. Socio-cultural distance is defined as the extent of how much each person understands one another [4]. In terms of offshore development, it becomes more complex as it consists of the culture of an organisation, the countries national traditions, local languages, government and political views and lastly even the work ethics of individuals [34]. A notable example of socio-cultural issue is the language, as English is not the first language in countries like India, Bangladesh, Pakistan and China, where a lot of work is offshored to; so extra effort is needed to communicate and coordinate between teams [35]. Any incorrect use of vocabulary can lead to miscommunication, which can result in adding hidden costs of correction [36].
At the earlier stages of software development a lot of communication is required but teams which are distributed geographically in different time zones face many communication and coordination issues as they get less real-time communication. It affects various aspects of the working partnership such as trust, relationships and efficiency of the team [19], [37]- [40]. A study done by Ebert [41] explained that approximately half of all the offshore projects fail due to the lack of sufficient communication, and trust between the team. A similar study done by Herbsleb et al. [42] showed that insufficient communication could drag the response of a problem, which causes projects to miss deadlines or fail.
Another issue is knowledge transfer, which introduces challenges in offshore software development [19], [43], [44]. It is difficult for managers to take advantage of offshoring if effective knowledge sharing processes are not set in place [8]. Knowledge is a key concept, and Davenport et al. [43] defines it as, any document or repository that an organization has, is considered as knowledge. In offshoring, knowledge transfer is a critical process as companies are moving their business culture and development processes to offshore locations and any mistake can cause a negative effect on the company. A study done by Radoff [45] states that the common problems between companies transferring knowledge are; problems in communication, different ways in which work is conducted and work attitudes, and how different is the decision making process. Based on the literature presented in Table 1 and the same has been summarised in Figure 1 it can be seen that communication and coordination issues along with trust, socio-cultural and knowledge transfer are the key factors for the success of offshore project.

B. THE EFFECT OF OFFSHORING ON AGILE ADOPTION
The four key challenges in offshore development were identified and how they affect the agile adoption process will be shown in this section. From the collection of systematic literature reviews conducted on agile offshore development [20]- [22], [46]- [48] and attempts to solve them [23]- [25]. Table 2 was designed. For example, if we consider the communication and coordination challenge, it affects agile practices such as sprint planning and continuous integration. It can be observed in Table 2 that how offshoring affects some agile practices: As shown in Table 2, agile practices do not match well with offshore development, which is why practitioners have been trying to modify and adapt agile practices for offshore development. This research believes that with the help of patterns, practitioners will be able to adopt agile practices easily for offshore development.

III. USE OF PATTERNS IN AGILE ADOPTION
This section first explains how patterns are being used to help companies adopting agile practices, and then presents the distributed agile patterns.

A. CURRENT PATTERNS FOR AGILE ADOPTION
The term ''pattern'' is commonly referred to as a reusable solution for a recurring problem within a given context [49]. A pattern usually consists of four parts, which are pattern name, problem, solution and consequence. The mostly used types of patterns which cover the whole software development life cycle: Requirement patterns [50], Analysis patterns [51], Design patterns [49], Architecture patterns [52], Idioms, and Anti-Patterns [53].
Based on the above definition of patterns, agile patterns are defined as ''focus on how an agile practice is being repeatedly modified and used in order to solve a recurring agile problem in a particular context'' [54]. To clarify the difference between what is considered as an agile practice and an agile pattern; an agile practice consists of any agile method and technique, which helps, in the application of agile methodology however agile patterns consist of recurring best agile practices, which are being used for the application of agile methodology.
As companies started to adopt offshoring, new patterns were being designed. Noll et al. [55] designed patterns for decision support systems that practitioners can use in offshore development. Lescher [56] in Siemens designed collaboration patterns for offshoring. His pattern catalogue consists of five patterns, which focused on the improvement of the communication and coordination among distributed teams. For example he identified one pattern Tailored Training, that focused on co-locating teams at the start of the project so that they can be trained and familiarised with the whole team and technologies that are needed in the project. Similarly, collaborative patterns were presented by van Heesch [57] which focused on how collaboration can be improved among distributed teams.
Similarly, researchers have worked on designing patterns for offshore agile development. Cordeiro et al. [58] designed a solution for offshore development by combining organisational patterns with Scrum. They identified 21 patterns and designed a language to structure patterns. Välimäki [59] focused on providing patterns for management techniques in offshore scrum projects.

B. DISTRIBUTED AGILE PATTERNS
So far the work done in this area is either generic or too focused on management and coordination of offshore projects. In contrast, this research identified a catalogue of distributed agile patterns, which will aid practitioners in adopting agile practices in offshoring context. While studying many cases from literature it was observed that many companies used common agile practices to overcome offshore challenges [60]- [63]. In other studies [56], [57], [64], [65], they designed communication and coordination patterns to overcome communication and coordination challenges that onshore and offshore team members face while working together. In [66], they designed patterns for project management.
From the observation it was established that recurring offshore problems where being solved by recurring agile practices. Based on the definition of agile patterns, distributed agile pattern is being defined as ''the adaptation of an agile practice that is being repeatedly applied in order to solve recurring challenges in a distributed project scenario'' [54]. In this research, systematic literature review and content analysis research methods were used to design the distributed agile patterns catalogue. In the Table 3 a summary of the existing techniques from the literature are presented which are being used for offshore development, we have compared them with our distributed agile patterns catalogue.

IV. RESEARCH METHOD
The research has been conducted by carrying out Systematic Literature Review following the guidelines of Kitchenham [72]. SLR was used to select primary studies from the existing literature. Krippendorff [73] was also used for content analysis on the semi-structure interviews that were conducted to verify the results. After the identification of the distributed agile patterns, for verification and validation reflection workshop proposed by Kerth [74] was conducted. The objective of this study is to provide the answers to the following questions: Research Question: What are the recurring adaptions of agile practices used in Offshore software development companies?
To be more specific, the study focused on the following two sub-questions: Research Question 1: What agile practices are commonly used to handle offshore software development challenges?
Research Question 2: Are those practices being used to solve a recurring offshore software development problem that can be considered patterns?
A. DATA SOURCE AND SEARCH STRATEGIES All the papers searched were written in English and were available online. The search strategy consisted of searching electronic databases as well as manually searching of conference proceedings. The electronic databases used are: IEEEXplore, ACM Digital Library, Google Scholar, Elsevier Science, AIS eLibrary, SpringerLink and Taylor Francis Online. The Figure 2 shows the paper review process and how many papers were identified at each stage.
In the first stage, the search items mentioned in Table 4 were used to select the databases. Category 1 has variations of the term ''Global Software Development'' and Category 2 has variations of the terms used for ''agile practices''. The combination of all the search items using a Boolean ''AND'' operator was used, which meant that an articles will only be considered as part of this research if it has both keywords or variations of the keywords, Agile VOLUME 10, 2022  and Global Software Development. As a result every combination was searched from Category 1 AND Category 2. Excluded articles consisted of editorials, article reviews, prefaces, news, discussion comments and tutorials summary, workshops, poster sessions and panels. The search resulted in finding 6614 articles. The following screening criteria was used to ensure that the papers selected addressed the research problem. ''Lesson learnt'' reports were also considered in the studies that were based on the opinions of experts to focus on how in offshore projects agile practices are used.
In the second stage studies were excluded based on the relevancy of titles and keywords based on the search items mentioned in Table 4. All the titles were read and 4407 articles were selected. In some cases, the titles failed to clearly identify whether the study was within the scope of this review. In such cases, the articles were included in the next review stage. In the third stage, all the articles that did not focus on offshore development were excluded. Some abstracts were misleading, that they gave little information about the content of the paper or did not state if the study was relevant. Therefore, at this stage, we only included studies that showed relevance to offshore experience, 2000 articles were shortlisted. Based on these points shortlisted papers helped in understanding the current agile practices and if those practices are being repeatedly used to solve offshore problems. Further each criterion was graded on dichotomous scale that is either ''yes'' or ''no''. In the final stage, the following criteria was selected in order to obtain primary articles: 1) Is the paper based on research? 2) Are the research aims clear? 3) Is there a satisfactory context to the research? The selected papers satisfied all three criteria, were graded ''yes'' in all three. That is, papers that did not show agile practices used to solve recurring problems were excluded, for example if only one paper mentioned that they used split pair programming to improve their coding. For a paper to be considered in this research an agile practice needs to solve an agile challenges and should be repeated in at least two papers to be classified as a distributed agile pattern. Figure 4, shows occurrence of an agile practice in literature such as asynchronous information practices occurred in nearly 200 papers whereas project charter occurred in 11 papers. Based on how many times a practice occurred in the literature, an overall 15 patterns were identified.
In order to verify the identified 15 patterns, 20 semistructured interviews were conducted, which consisted of nine open-ended questions, which covered different aspects of offshoring. The questionnaire is mentioned in the appendix, which is available at https://bit.ly/3DknJC2. This helped in obtaining experts points of view regarding how agile practices are being used in the industry. The selection of companies was done based on their experience in offshore software development. The companies were categorised into 3 classes, which are startup, break-even and profitable. Companies were categorised as startups that are still in early stages of earning revenue, likewise break-even, are those companies that have reached break-even status in their finances and the companies that are generating profit are categorised as profitable. The description of the companies interviewed is mentioned in Table 5. Based on the search criteria, 15 distributed agile patterns, were identified which were verified using a reflection workshop. Feedback was collected from the companies that were invited during the workshop in order to gather their views on the patterns catalogue. Based on their view the following aspects were assessed: • How complete the distributed pattern catalogue is? • How useful this catalogue may be to the practitioners that want to overcome distributed development challenges?

V. RESULTS
This section presents the initial distributed agile patterns identified from the literature and interviews, and the revised patterns based on the results of the reflection workshop.

A. DISTRIBUTED AGILE PATTERNS IDENTIFIED FROM LITERATURE AND INTERVIEWS
By conducting literature review and interviews the pattern catalogue was developed. In order to document the distributed agile pattern catalogue Gamma's design pattern template was used, as it is perceived as the first pattern catalogue and to preserve familiarity for the practitioners [49]. However, the template was customised to capture the findings. The template contained sections such as pattern name, intent, also known as, category, applicability, participants, collaboration, consequences, known uses, and related patterns. Sections such as structure, implementation and sample code were removed, as they were not relevant to the findings. Based on the findings, 15 distributed agile patterns were identified and are placed into four categories based on the type of problem they solved. The four categories are management, communication, collaboration and verification. Figure 5 shows the mapping of distributed agile patterns onto the Scrum development lifecycle. Asynchronous Information Transfer, Synchronous Communication and Visit Onshore-Offshore are not mapped specifically onto the figure as the offshore company can decide when and how to use them throughout the whole lifecycle. Due to the limited space available for this article, one example of patterns is presented here, whereas the full catalogue is available at the following URL: https://bit.ly/3lqcNwP

1) DISTRIBUTED SCRUM OF SCRUMS PATTERN
In agile methodology, Scrum is an iterative and incremental project management approach that provides a simple framework that '' inspect and adapt'' [75]. We observed that in offshore projects the onshore and offshore team practices separate scrums in order to develop the project. Based on the observed practice we have designed the following pattern details: 2) PATTERN NAME

3) INTENT
To apply scrum, sub-teams are formed based on location. Each team has its own scrum. Scrum of scrums meetings are arranged to discuss the progress of the project, which is attended by key people.

4) ALSO KNOWN AS
Scrum meeting or Meta Scrum

5) CATEGORY
Management category, as this pattern helps the onshore and offshore team manage their separate scrums and keep each other updated of the project progress.

6) MOTIVATION
The motivation of this pattern is to address the communication and coordination, and knowledge transfer challenges. For example consider a team that is divided into sub-teams based on location and they are working on different tasks of a project. It is difficult to have both onshore and offshore team work on the same scrum as they both work on different time zones so in order to work on the same project, both teams work on separate scrums. To coordinate work both teams arrange a scrum of scrums meeting, which is attended by key people from both teams to update each other of the progress of the project.

Use Distributed Scrum of Scrums when:
• Team is distributed over different time zones. • There is less overlap over working hours between the onshore and offshore teams.

8) PARTICIPANTS
• Distributed onshore and offshore agile team.
• Scrum Masters of agile sub-teams and Product owner.

9) COLLABORATION
• Key members from onshore and offshore teams decide time for Scrum of Scrums meeting.

10) CONSEQUENCES
The Distributed Scrum of Scrums pattern has the following benefits and liabilities: 1) It prevents the onshore and offshore team from wasting time on collaborating tasks with each other through  online tools as both the teams are working on their own scrums so they don't have to wait for each other to complete tasks. This helps overcome the communication and coordination challenges.
2) It provides control to both onshore and offshore team to work on their scrum, which avoids the offshore team from having to adjust working hours based on onshore teams availability. This helps overcome the communication and coordination challenges. 3) It allows key people such as Scrum Masters and Product owners to discuss the progress of the project without having the whole team present which keeps the meeting time boxed and helps in knowledge transfer among the teams.
4) Its limitation is that due to minimum collaboration between the onshore and offshore team, both sub-teams don't feel they are one team. 5) Since only key people attend the Scrum of Scrums meeting, it limits face-to-face interaction of both onshore and offshore team, which affects trust building between both teams.

11) KNOWN USES
CheckFree, used Scrum of Scrums for their work in an Indian offshore firm [76]. Similarly, for their USA, Europe and India offshore teams, Siemens also used Scrum of Scrums [77].

12) RELATED PATTERNS
Distributed Scrum of Scrums pattern is often used with Local Sprint Planning Pattern and Asynchronous Retrospective meeting Pattern as teams on different locations are working on separate story cards resulting in conducting separate retrospective meetings. Table 6 represents the summary of the ''known uses'' of the patterns by practitioners. This shows how practitioners have used these patterns in real project scenarios such as Check-Free has used Scrum of Scrums and Local Sprint Planning for their offshore projects. Similarly, Yahoo! used Followthe-sun approach for their offshore teams in which each team worked according to their time zones and synced work using synchronous and asynchronous tools.

B. REVISED DISTRIBUTED AGILE PATTERNS
In literature there are many approaches through which you can assess results such as using fuzzy approach [99], structural modeling approach [100]. In this research to verify and validate the pattern catalogue, Kerth's [74] reflection workshop method ''The keep/try reflection workshop'' was used. This method was selected to get opinions from experts regarding the correctness of the patterns and if the catalogue is useful to practitioners who want to apply agile to their offshore projects. Lastly we conducted a questionnaire survey as suggested by Sikandar [100] to summarise the patterns from the practitioner's perspective.
For the workshop four companies were invited. Based on our earlier definition of the startup, break-even and profitable we invited 1 startup, 2 break-even and 1 profitable companies. All the companies had at least 2 years experience with agile offshore development. Details of the companies are provided in Table 7.
In order to get both a managerial and development view two participants from each company were invited. All of the participants had experience in distributed agile development. Details of participants are shown in Table 8. The workshop was held in the boardroom of C1 and lasted for seven hours that included presenting the pattern catalogue and collecting feedback from the participants on the flip chart. Table 9 shows the agenda of the workshop. Table 10 shows the format of the flip chart on which feedback was collected. It was based on the reflection workshop of Kerth. The 'Keep these' section refers to all the patterns the participants do not want to change, 'Problems' refers to the patterns they want some changes in and 'Try these' are recommendations that they want us to consider.
The catalogue as in Table 6 was presented in a printed hard form and given to each participant so that they may read it and make notes on it. As the participants were not familiar with the catalogue, one pattern was presented at a time and participants discussed it with each other before moving onto the next pattern. Similarly flip charts were given to the participants so that they can document their opinions. The figure 6 shows the table of contents of the document given to the participants. Each pattern was numbered so that the participants can use them to refer patterns.  Table 11 shows an example of how we documented the reflection workshop on a flip chart of Company 3 Participant 5 (C3P5).
In the flip chart, C3P5 wants the section 1.2-1.5 to stay the same as presented so they wrote them in the Keep these section. In the Problems section they want us to change the Central Code Repository pattern as according to them it is currently too generic. In the Try these section they have made some suggestions such as to rename the pattern Scrum of Scrums as it causes confusion with the general term used for scrum of scrums practice so they suggested to use the name of Distributed Scrum of Scrums. A summary of all the flip charts is presented in Table 12. From the summary, it can be seen that most of the companies agreed to keep sections 1.2-1.5 the same way as they were presented and similarly, for sections 2.1,2.3-2.4, 3.3-3.4 and 4.1-4.2. However problems were identified in patterns 2.2, 3.1 and 3.2 which were modified based on the suggestions given by the companies. Lastly, there were a few things they wanted to try with patterns 1.1 and 4.2 which were considered in the revised version of the catalogue.
After discussing the pattern catalogue the discussion moved towards how useful the catalogue is in answering the offshore challenges. Table 13 shows, which pattern helps solve the offshore challenges such as Distributed Scrum of Scrums solves socio-cultural and communication and coordination challenges, below we have explained all the patterns and the challenges they solve.
• Follow the sun pattern: was agreed by 50% of the participants that it will help improve the communication VOLUME 10, 2022      and coordination among the distributed team members. However the remaining 50% questioned the practice as by following the sun pattern the overlapping working hours reduces which may result in less real time communication among the distributed teams.
• Asynchronous retrospective meetings: was agreed by 65% participants that it will help improve communication and coordination gap as well as aid in knowledge transfer as teams can conduct their retrospective and share meeting minutes with offshore teams. • Project charter pattern: 75% of the participants agreed that this pattern could help resolve trust issues as well as aid in bridging the communication and coordination gaps and solve issues of knowledge transfer. However 25% still believed that a single document could not help establish trust let alone solve issues of communication and coordination.
• Distributed scrum of scrums: 80% participants agreed that it will improve communication and coordination and will also solve knowledge transfer issues in distributed teams. As in this pattern, teams are allowed to conduct their own separate scrums and just have to share updates synchronously.
• Local stand-up meeting: 80% participants agreed that local stand-up meeting aids in solving communication and coordination issues, it also solves knowledge transfer issues. Teams can independently conduct their stand-up meeting and share key points with relevant stakeholders. VOLUME 10, 2022 • Local sprint planning meeting: It was agreed by 80% of the participants that local sprint planning meetings issues in communication and coordination as each sub team can plan their independent sprints and share knowledge using tools with the whole team to track progress of the project.
• Local pair programming: 80% of the participants agreed that pairs should be formed based on location as it eases in communication and coordination among the team members.
• Onshore review meeting: Since the team members are distributed, 75% of the participants agreed that onshore review meetings help solve communication and coordination issue as the onshore team can directly present the work to client and the feedback can be shared with the offshore team which facilitates knowledge sharing • Asynchronous information transfer: As the teams are distributed they highly depend on asynchronous tools for information sharing and communication and coordination. 80% of the participants agreed to its applicability.
• Collective project planning: 100% of the participants agree on collective project planning to solve all four challenges as when the team is co-located they can work together as one team and avoid all the challenges due to offshoring.
• Collaborative planning poker: When the team members will be co-located and working on estimation together, 100% participants agree that this pattern will solve all four challenges.
• Central code repository: 100% of the participants agreed that having a central code repository will solve communication and coordination issues and will streamline knowledge transfer of code among teams.
• Synchronous Communication: When the team members are distributed they need to rely heavily on synchronous tools to share knowledge, hence 100% of the participants agree on synchronous communication.
• Global scrum board: All participants agree that global scrum board is a key to solving all the challenges as having a centralised board showing all the information solves communication and coordination issues as well as knowledge transfer. Since everyone can view and edit the board, it creates trust and encourages socio-cultural interactions.
• Visit onshore-offshore team pattern: 100% participants agreed that this is a very useful pattern as it helps in establishing trust among the distributed teams. This pattern in turn also aids communication, coordination and knowledge sharing among the members.
After discussing the effectiveness of each pattern in the application of agile in offshore projects feedback was collected based on how useful the catalogue is for practitioners. Based on the Distributed Agile Patterns catalogue we designed a questionnaire to determine the usefulness of the patterns, which is available at https://bit.ly/3CYSFs1.The questionnaire was distributed online using Google Forms. The link was shared through email and LinkedIn. A total of 45 practitioners participated. An overview of their distributed agile experience is mentioned in Figure 7. Usefulness of the Distributed Agile Pattern catalogue was identified through empirical study shown in Table 14. In this table, the EA (Extremely Agree), MA (Moderately Agree), SA (Slightly Agree), SDA (Slightly Disagree), MDA (Moderately Disagree) and EDA (Extremely Disagree) show 7 levels of the participant's agreement to the questions. It has been divided into two main columns, pattern name and expert observation. The ''pattern name'' lists the names of all the patterns in the catalogue and expert column records experts experience about the usefulness of each pattern which is further divided into three columns i.e. ''Positive'', '' Negative'' and ''Neutral''. For the purpose of analysis we grouped the responses into three groups X, Y, and Z. The X group counts the frequency of all the positive responses such as (slightly agree, moderately agree, and extremely agree), group Y consists of neutral responses and group Z consists of negative responses such as (extremely disagree, moderately disagree, and slightly disagree). By negative impact we mean that the practitioner did not agree that the pattern was useful for solving distributed agile challenges. We suggest that organisations that want to use agile for their offshore software projects should use our pattern catalogue. Analysing the percentage values of the ''Negative'' column in the Table, we can see that most of the values are below 18%. This shows that majority of the experts agree that the patterns are useful for agile offshore development.
To find the usefulness of a pattern the criteria used was that if a pattern is answered as agree in the questionnaire with a percentage of more than or equal to 50% then we consider that the pattern is useful to solve a distributed agile challenge. This research criteria have been used for similar research [100], [101].

C. ANSWERING RESEARCH QUESTIONS
As in this research the main focus was to answer the following research questions.

1) COMMONLY USED AGILE PRACTICES TO HANDLE OFFSHORE SOFTWARE DEVELOPMENT (RQ1)
Based on the selected 212 papers from literature 15 commonly used agile practices from literature were identified.  These identified practices were observed to have been modified for the adoption of distributed agile development. This helped in answering the first research question in which commonly used agile practices in offshore are adapted to deal with offshore software development. With the help of literature review 15 practices that are being used to solve issues in offshore development were identified.

2) RECURRING AGILE PRACTICES USED FOR OFFSHORE SOFTWARE DEVELOPMENT PROBLEM (RQ2)
As we answered the RQ1 by identifying commonly used agile practices in solving offshore development issues, the next step was to determine if those practices recurred in solving agile problems. The Figure 4 shows how many times in literature the 15 agile practices recurred in solving an offshore problem. Since these modified practices recurred to solve agile problems we classified them as distributed agile patterns. Based on these recurring practices the distributed agile patterns catalogue was designed. Table 15 shows the categories of the distributed agile patterns catalogue.

VI. THREAT TO VALIDITY
There are four main types of threats to validity, which are internal validity, external validity, construct validity and conclusion validity. We conducted threat to validity for our results.
While identifying the key inherent challenges of offshoring the research focused only on the broad categories of the challenges such as Trust, Communication & Coordination, Socio-Cultural and Information Transfer. We did not focus on challenges that did not lie in these categories as their occurrence in literature was not significant. This can pose a threat to validity as their maybe new challenges that does not fall into these categories.
For the systematic literature review the selection of the studies were chosen based on a set of specific keywords, which can pose as a threat to validity as some studies could have been, eliminated as the keywords did not cover them. The screening process was done manually by reading the 544 papers and selecting 212 based on the papers fulfilling the three question screening criteria, since this was done manually it can pose a threat to validity as the understanding of researchers about papers can vary and they could have made an error and also there is a chance of bias.
For interviews and workshop conducted in this study limited number of participants were selected for the sample set. This can pose as a threat to validity as the selection of research participants was limited by the willingness of experts to participate and the availability of experts in the domain of agile. As with any empirical software engineering project, a very high number of variables can affect the project. Similarly, for the distributed agile patterns catalogue it is difficult to identify any one factor that can lead to the success and failure of the catalogue. However, the usefulness of the catalogue was clearly evident from the feedback of the participants.
Patterns generally refer to generalised solutions within a given context. We do not claim the catalogue is comprehensive. We want to encourage researchers to identify more recurring agile practices that are being used in order to overcome offshore challenges.

VII. CONCLUSION AND FUTURE WORK
The adoption of agile practices in offshoring is not a straightforward process. The 15 distributed agile patterns catalogue based on the literature and semi-structured interviews was designed to help the practitioners who want to adopt agile for their offshore projects. The catalogue was validated using Kerth's reflection workshop method and the usefulness of the catalogue was determined through questionnaire that was filled by 45 industrial participants. Based on the observation it can be seen that the negative responses were only less than 18%. Practitioners can use this catalogue to understand how agile practices are affected in a distributed scenario and can apply these patterns for when they want to adopt agile practices. The generalisation of the patterns helps practitioners in adapting them for their own projects.
Future work is planned which includes to conduct a case study on the application of the pattern catalogue adoption and to design a tool to help aid users in deciding which pattern suits their requirements and to replicate this study in distributed teams of the most varied types of companies. For upcoming work, we suggest to study how agile methodologies have evolved and the reason why they have evolved to measure whether these adaptations have delivered better results.