ng="en"> Distributed Agile Patterns

Distributed Agile Patterns

Presented by Maryam Kausar and Adil Al-Yasiri

Traditionally, software was always developed at one location where the whole team worked from the same office but in order to cut down on software development cost companies started to offshore work (Pilatti, Audy, 2006). As companies continued to switch to offshore development it became clear that achieving reduced cost is not as straightforward as it seemed (Damian, Moitra, 2006) as they had to face some challenges, which are caused due to temporal, geographical and socio-cultural differences (Holmstrom, Conchúir, Agerfalk and Fitzgerald, 2006).

Companies that choose to use agile methodology for offshore projects faced problem such as face-to-face meetings and no overlapping work hours with offshore team to discuss issues(Šmite, Moe, and Ågerfalk, 2010). However we studied many cases in literature and observed some common practices that the companies choose in order to overcome those challenges and apply agile for distributed project. From our observation we found recurring solutions for recurring problems that the teams faced. Based on our findings we developed a catalog of distributed agile patterns.

Based on our definition of agile patterns “Agile patterns focus on how an agile practice is being repeatedly used in order to solve a recurring problem in a particular context”. We define distributed agile patterns as how an agile practice is being repeatedly used in order to solve the recurring problems in a distributed project scenario.

Distributed Agile Patterns Template

Patterns are described using a standard format in order to provide structured information that makes them easier to understand and compare. Below we have provided a comparison between the existing different templates that are used for patterns (Robertson, 1996; Fowler, 1997; Gamma et al., 1997; Buschmann et al. 1996; Brown et al. 1998)

Below is the template we have designed for distributed agile patterns:

Pattern Name

As patterns represent generic knowledge it is vital to give a good name that would make it recognizable and reusable. A good name also helps in facilitating communications about the pattern.

Intent

A short statement that highlights the issues and problems that are required to be solved by applying the pattern.

Also Known As

The pattern’s other well-known names, if any are mentioned in this section.

Category

Based on the similarities of the patterns we can group them into different categories to be able to provide an abstract view of all the patterns.

Motivation

It consists of the description of the problem and why we should use the pattern in order to avoid the problem from recurring. It provides scenarios that help understand the abstract description of the pattern.

Applicability

Under what conditions the pattern can be applied.

Participants

The participants are those people that are required in applying the pattern.

Collaboration

How participants will coordinate with each other in order to fulfill their responsibilities that are required to complete the projects.

Solution

Provide a generic solution for a recurring problem that is covered by the pattern. They solution is justified using concrete decisions that occur while solving in the problem. It can consist of graphical representation as well as detail discussion on how the pattern can be implemented in order to avoid the problem. Based on the nature of the pattern we can provide application examples of where it can be used as well as we can provide code segments where it seems possible.

Consequences

Discuss the trade-offs of applying the patterns such as advantages and disadvantages achieved from applying it.

Known uses

Examples of real systems found that follow the pattern in order to provide clarity of how the pattern can be used.

Related Pattern

List of similar patterns in order to identify which patterns can be used together to improve a system.

Distributed Agile Pattern Catalog

In this section we have mentioned the pattern name and intent of the pattern that we identified from literature and multiple case studies. Following are the list of patterns:

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

  2. Local Standup meetings Pattern: To discuss daily updates on work done, each local team will conduct their own standup meetings.

  3. Follow the sun Pattern: Onshore and offshore teams will work 9a.m -5p.m according to their own time zones.

  4. Onshore Review Meeting: The onshore team will present the demo as they are located where the client is.

  5. Collective Project Planning: Both the onshore team and the offshore team will collectively work in the project planning phase.

  6. Project Charter Pattern: Before starting the project planning activity, agile teams use project charter in order to have a central document between the onshore and offshore team that defines the project.

  7. Collaborative Planning Poker: OnlyKey people will hold this activity from onshore and offshore team.

  8. Global Scrum Board: ere will be an online-shared Scrum board, which, both onshore and offshore team can use to view product backlog, storyboard, task board, burn down charts and other agile artifacts using online tools such as wikis

  9. Local Sprint Planning: Each team will have their own sprint planning meetings.

  10. Local Pair Programming: Make pair programming teams from the same location.

  11. Central Code Repository: The whole team will maintain a central code repository so that both team can see each other’s code and see the progress of the work done.

  12. Asynchronous Retrospective meetings: Teams conduct separate retrospective meetings based on location and share the key information via email. The Scrum Masters discuss possible improvements with the team based on the feedback from the client.

  13. Asynchronous Information Transfer: Due to the time difference between the onshore and offshore team use online tools to exchange information with each other. Each team should response to queries within 12hours.

  14. Synchronous communication: In order to discuss issues the teams used synchronous tools for voice, video conferencing, document sharing, application sharing etc.

  15. Visit onshore-offshore teams: Both onshore and offshore teams should quarterly / annual visit each other in order to build trust, exchange cultural values and improve team coordination.

Organizing the Catalog

Distributed agile patterns vary in their granularity and level of abstraction. Because there are many distributed agile patterns, we have organised them in 4 categories, which are management, communication, collaboration and verification patterns. This classification helps in learning and identifying which pattern is to be used in a specific scenario.We have classified distributed patterns based on the problem they solve. Following are the definition of the 4 categories:

  • Management patterns: As in GSD the team is distributed over different time zones it is difficult to manage all the distributed team members and as theyare working on different modules of the project it is difficult to determine the overall progress of the project. In order to handle this problem we use management patters as they consist of practices that help in managing the onshore and offshore team members and their activities to effectively apply agile in a distributed environment.

  • Communication patterns: Since the team is distributed geographically over different time zones they have minimum overlapping working hours, which makes it difficult to maintain real time communication between the onshore and offshore team members. Communication patterns focus on providing solutions to how distributed team members can maintain an effective communication channel in an agile setting using different online tools which provide both synchronous and asynchronous method for communication.

  • Collaboration patterns: Even if the nature of the project is GSD, there is still a need to conduct some collective team activities in order to improve the coordination among the onshore and offshore team members. Because if the onshore and offshore team members don’t meet each other it creates mistrust and misunderstanding among the team members, which affects the overall team’s productivity. In order to solve this issue collaboration patters provide solutions regarding which activities the onshore and offshore team members should conduct together to improve team coordination and project progress.

  • Verification patterns: As in agile we focus on building the right product according to the satisfaction of the client. But as the team is distributed on different locations it is difficult to set a standard guideline for all the distributed development sites and how to show project progress to the client. In order to solve this problem verification pattern focuses on how efficiently the clients can get a distributed project developed according to their requirements and monitor the progress of what has been developed.

Management Patterns

In this section we have described the detail of each management pattern.

  1. Distributed Scrum of Scrum Pattern
    In agile methodology, Scrum is an iterative and incremental project management approach that provides a simple framework that “ inspect and adapt” (Hossain, Babar, and Paik, 2009). We observed that in offshore projects the onshore and offshore team practices separate scrums in order to develop the project.Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Distributed Scrum of Scrum Pattern

    Intent

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

    Also Known As

    Scrum meeting or Meta Scrum

    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.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, 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 scrum meeting, which is attended by key people from both teams to update each other of the progress of the project.

    Applicability

    Use Distributed Scrum of Scrum when:

    • Team is distributed over different time zones.

    • The overlapping working hours between the onshore and offshore team is less.

    Participants

    • Distributed onshore and offshore agile team.

    • Scrum Masters of agile sub-teams and Product owner.

    Collaboration

    Key members from onshore and offshore teams decide time for Scrum of Scrum meeting.

    Consequences

    The Distributed Scrum of Scrum 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 scrum 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 helpsovercome 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 Scrum meeting, it limits face-to-face interaction of both onshore and offshore team, which affects trust building between both teams.

    Known uses

    When CheckFree decided to move their work to an Indian offshore consulting firm used Scrum of Scrum to gather and review the over all team statistics and progress of the project (Cottmeyer, 2008). Similarly, multiple case studies done on organisations using Scrum for distributed teams also used Scrum of Scrum to coordinate work with offshore team (Hossain, Babar, and Paik, 2009; Paasivaara, Durasiewicz, and Lassenius, 2009). Siemens also used Scrum of Scrum for two large distributed projects in which the development teams were located in USA, Europe and India. In their Scrum of Scrum meetings they covered technical and managerial issues that occurred in multiple teams (Avritzer et al., 2010)

    Related Pattern

    Scrum of Scrum pattern is often used with Local Sprint Planning Pattern and Asynchronous Retrospective meeting Pattern as the onshore and offshore team members are working on different story cards and at the end have their separate retrospective meetings to discuss the sprint

  2. Local Standup Meeting
    Agile methodology focuses on conducting a daily standup meeting. We observed that in offshore projects the onshore and offshore team conduct their own separate daily standup meetings and use online tools such as Wiki’s to share meeting minutes with each other. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Local Standup Meeting Pattern

    Intent

    To discuss daily updates on work done, each local team will conduct their own standup meetings.

    Also Known As

    Daily Scrum meeting or daily meeting

    Category

    Managementcategory as this pattern helps the team members of both onshore and offshore team manage their daily activities and update each other with the work done.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges. For example consider a team that is divided into sub-teams that are located on different time zones. To have a collaborative daily standup meeting is difficult and time consuming as the offshore team either has to come early to work or stay late to attend the meeting. To avoid this, the onshore and offshore team conducts separate local standup meetings in which they answer the following questions:

    • What did you do yesterday?

    • What are you doing to do today?

    • What is getting in your way?

    After conducting local standup meetings both onshore and offshore team share, meeting minutes via online tools such as Wiki’s to keep both the teams up to with the progress of the project.

    Applicability

    Use local standup meeting when:

    • Team is distributed over different time zones.

    • The overlapping working hours between the onshore and offshore team is less.

    Participants

    Distributed onshore and offshore agile team.

    Collaboration

    Both onshore and offshore team share meeting minutes with each other using online tools.

    Consequences

    The local standup meetings pattern has the following benefits and liabilities:

    1. It prevents the offshore team from waiting for the onshore team’s availability to conduct the daily standup meeting. This helps overcome the communication and coordination challenges.

    2. It allows both onshore and offshore team flexibility to conduct their own standup meeting at whichever time they want. This helps overcome the communication and coordination challenges.

    3. It allows the onshore and offshore to transfer knowledge by sharing meeting minutes with each other.

    4. It limits the onshore and offshore team from real-time communication and both team heavily rely on the meeting minutes so any mistake can lead to misunderstanding the progress of the project.

    Known uses

    Organisations such as PulpCo (Paasivaara, Durasiewicz, and Lassenius, 2009) and Wipro Technologies (Sureshchandra et al., 2008) use local standup meetings for communicating the progress of the project with team members.

    Related Pattern

    Daily Standup meeting pattern is often used with Global Scrum Board Pattern as once the onshore and offshore team members have conducted their meetings they share the meeting minutes on a shared tool so that both can see the project progress.

  3. Local Sprint Planning Meeting Pattern
    In agile, a scrum consists of many sprints. The duration of a sprint varies from 2 weeks to 4 weeks depending on the size of the project. At the start of every sprint the team has a sprint planning meeting in which the team defines the goal of the sprint and prepare the sprint backlog. When the team is divided and is working on different modules of the project it has been observed that the onshore team members and offshore team members conduct their own separate sprint planning meetings.Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Local Sprint Planning Meeting Pattern

    Intent

    Each team will have their own sprint planning meetings

    Also Known As

    Sprint Planning Meeting or Iteration Meeting

    Category

    Management category as this pattern helps the onshore and offshore team work on their separate module and conduct independent scrum and sprint planning meetings.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges. For example When a project is distributed to a team that is divided over different time zones, and are working on different modules of the project and are conducting their own Scrum. As the onshore and offshore team conducts their separate Scrum, they also conduct separate sprint planning meetings to decide what they will develop during a sprint. Both teams prepare their sprint backlogs, which are shared using online tools.

    Applicability

    Use Local Sprint Planning Meeting pattern when:

    • Team is distributed over different time zones and is working on different modules/subsystem of the project.

    Participants

    Distributed onshore and offshore agile team.

    Collaboration

    The onshore team and offshore team share sprint backlog with each other to show the work they will be doing over the next sprint.

    Consequences

    The Local Sprint Planning Meeting pattern has the following benefits:

    1. It allows both teams to work independently without having to wait for the onshore team to be available to conduct the meeting, which helps overcome the communication and coordination challenges.

    2. It provides control to both onshore and offshore team to work on their scrum and conduct their own sprint planning meeting, 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. Both teams can share their sprint backlog with each other, which provides visibility of the project progress and helps overcome the knowledge sharing challenges.

    4. As both the teams are working independently it can cause the teams to feel as they are not part of one team rather create an effect that they are two separate teams.

    Known uses

    When CheckFree decided to move their work to an Indian offshore consulting firm they used local sprint planning meetings to plan their sprint activities (Cottmeyer, 2008).

    Related Pattern

    Local Sprint Planning Patterns in often used with Scrum of Scrum Pattern and Global Scrum board Pattern as the meetings minutes of the planning meeting are shared with both onshore and offshore team members.

  4. Local Pair Programming Pattern
    In agile, pair programming consists of two programmers that share a single workstation that is they share one screen, keyboard and mouse. The programmer using the keyboard is usually called the "driver", the other, is called “navigator” as he is activity giving his remarks on the code and helping the driver to write the code. The programmers are expected to switch roles after every few minutes. It has been observed that when the team is divided on different locations, the team members that are co-located form pairs as it is difficult to form pairs with other locations team members due to the time difference. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Local Pair Programming

    Intent

    Make pair programming teams from the same location.

    Also Known As

    Pair Programming or Paired Programming

    Category

    Management category as this pattern helps the local team members to form pairs and work on their story card.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination challenges. For example When a team is distributed over different locations based on time zones, it is difficult to form pairs between them due to the time difference in working hours. So each team forms pairs based on their location as they are co-located and can work together. Pair Programming helps improve the quality of code as instead of one person writing the code the other person is checking the code.

    Applicability

    Use Local Pair Programming pattern when:

    • Team is distributed over different time zones and is working on different modules/subsystem of the project

    Participants

    Distributed onshore and offshore agile team and working on different story cards.

    Collaboration

    The onshore team and offshore team members share a keyboard with a fellow team member from their respective location.

    Consequences

    The Local Pair Programming pattern has the following benefits:

    1. The offshore team members don’t have to wait for the availability of onshore team members to start work, which helps overcome the communication and coordination challenges.

    2. Some organizations feel it’s a waste of having two resourcing working on the same thing.

    Known uses

    In a case study conducted by Maruping (2010) on an organization that had its development centers in India, U.S West Coast, U.S Mid-West and U.S East Coast showed that pairs where made on the bases of physical locations.

    Related Pattern

    Since in Local Pair programming we are selecting team members from the same location, we often use it with Local Sprint Planning Meeting.

  5. Asynchronous Retrospective meetings Pattern
    In agile, when a team is using Scrum at the end of every sprint after the sprint review meeting, a retrospective meeting is conducted which is attended by only the team members and the scrum master. In this meeting the team discusses all the good and bad things that happened during the sprint and how they can improve their work. They also discuss the feedback given by the client. It has been observed that when the team is divided on different time zones, teams conduct their own retrospective meeting, as due to the time difference it is difficult to have a collective retrospective at the end of each sprint (Kamaruddin, 2012). Once both the onshore and offshore teams have conducted their retrospective meeting they share the meetings minutes with each other using online tools. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Asynchronous Retrospective meetings

    Intent

    Teams conduct separate retrospective meetings based on location and share the key information via email. The Scrum Masters discuss possible improvements with the team based on the feedback from the client.

    Also Known As

    Retrospective meetings or Iteration Retrospective

    Category

    Management category as this pattern helps the onshore and offshore team members to review their sprint and discuss their performance. The Scrum Master advises the team on how they can improve their performance and discusses the feedback of the client.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges. For example when a team is divided on different time zones and are working on different modules/subsystems of a project and conducting their own independent Scrum and sprints it is difficult to have a collective retrospective meeting. The onshore and offshore team members conduct their separate retrospective meetings to discuss what went good and bad in the sprint and how they can improve their work in the next sprint. The Scrum master attends these meetings and gives feedback on the performance on the team and discusses the remarks given in the sprint review meeting by the client. Once both teams have conducted their retrospective meetings they share the meeting minutes with each other using an online tool.

    Applicability

    Use Asynchronous Retrospective meetings when:

    • Team is distributed over different time zones and is working on different modules/subsystem of the project.

    Participants

    • Distributed onshore and offshore agile team members.

    • Scrum Master.

    Collaboration

    The onshore team and offshore team members share meeting minutes at the end of their retrospective meetings.

    Consequences

    The Asynchronous Retrospective meetings pattern has the following benefits:

    1. It allows onshore and offshore team members to conduct retrospective meeting independently of each others availability, which helps overcome the communication and coordination challenges.

    2. It helps team members discuss their independent problems and doesn’t make both onshore and offshore team to be present for the meeting and can share meeting minutes using online-sharing tools. This helps overcome the knowledge transfer challenges.

    3. Since onshore and offshore team members conduct separate retrospective meetings they don’t understand each other’s problems.

    Known uses

    Elastic Path, a Vancouver, British Columbia-based company decided to offshore their work to Luxsoft, an outsourcing partner used asynchronous retrospective sessions to discuss the sprint progress and well as what improvements they can make. Once all locations had conducted their retrospective meetings, they posted comments and results on SharePoint, which were then viewed by Scrum Master and technical lead for their remarks (Vax, 2008).

    Related Pattern

    We often used Scrum of Scrum Pattern with Asynchronous Retrospective meeting Pattern. It is also often used with Local Sprint Planning Pattern as in order to review the progress of a sprint and the team we use retrospective meeting. After all the distributed teams have conducted their retrospective meetings they share the meeting minutes with each for which they use Global Scrum Board Pattern.

Communication Patterns

In this section we have described the detail of each communication pattern.

  1. Global Scrum Board Pattern
    Agile has many artifacts such as product backlog, sprint backlog, storyboard, task board, team velocity and burndown charts which help the team in managing the project. It has been observed that when the team is divided to different locations they maintain a online record of all these artifacts so that they can share them with each other using online tools such as Wiki’s, Rally and Jira (Danait, 2005; Beruzuk, 2007; Cottmeyer, 2008). Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Global Scrum Board Pattern

    Intent

    An online-shared Scrum board, will be used by, both onshore and offshore team to view the product backlog, storyboard, task board, burn down charts and other agile artifacts using online tools.

    Also Known As

    Scrum Board or Agile Story Board

    Category

    Communication category as this pattern helps the onshore and offshore team communicate with each other using an online tool to view each other’s work and understand the progress of the overall project.

    Motivation

    The motivation of this pattern is to address the trust, socio-cultural communication and co-ordination, and knowledge transfer challenges. For example when a project is distributed to a team that is divided over different time zones, and are working on different modules of the project, to share their work they use an online tool to display agile artifacts. Based on the work done by both teams it is easier to see the progress of the project and it helps understand if there is a problem with a team or not.

    Applicability

    Use Global Scrum Board pattern when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team.

    Collaboration

    The onshore team and offshore team share agile artifacts with each other to show their progress.

    Consequences

    The Global Scrum board pattern has the following benefits:

    1. It allows the whole team to see the requirements, which creates visibility of the project and helps in overcoming trust challenges.The scrum board is designed keeping the socio-cultural differences in mind.

    2. It allows the onshore and offshore teams to understand the progress of the project which helps overcome the communication and coordination challenges.

    3. It increases the visualization of the work done by each team, which helps overcome the communication and coordination challenges.

    Known uses

    FAST, a search company with headquarters in Norway while building a search application on top of their core search platform experimented with couple of online tools to keep both teams updated with the progress of the project. They tired XPlanner and Jira and settled for Jira, which is a web-based tool that allowed the remote team members to view the backlog and update tasks whenever they wanted (Berzuk, 2007). Similarly in a study done by Cristal et al. (2008) on an organisation that has development centers across North America, South America and Asia concluded with that the use of a global scrum board can help improve the productivity of global agile teams. Similarly companies like Valtech (Danait, 2005), Telco (Ramesh et al., 2006), BNP Paribas (Massol, 2004), Aginity LLC (Armour, 2007) and SirsiDynix (Sutherland et al. 2007) used online tools to share agile artifacts with their offshore team members.

    Related Pattern

    Global Scrum board pattern is often used with Central Code Repository Pattern as the team shares all the agile artifacts and code using an online tool.

  2. Central Code Repository Pattern
    In agile, when a team is using Scrum and XP, the team members are divided in pairs of two and are working on different tasks during a sprint. When a task is completed the team members commit their code to a share repository for continuous integration of the code. It is observed that even when the team members are geographically apart they still use a share code repository where they commit their code so that all the team members can see the code as well as determine the progress of the project. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Central Code Repository

    Intent

    The whole team will maintain a central code repository so that both teams can see each other’s code and see the progress of the work done.

    Also Known As

    Source Code Repository or Global Build Repository

    Category

    Communication category as this pattern helps the onshore and offshore team members to write code and share it on a central code repository where all team members can see the code and edit it if required.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges. For example when a team is divided on different time zones and are working on different modules/subsystems of a project they use a central code repository to share their work with all team members. They can use online tools such as GitHub for committing their code and maintain versions of the project (Räty, 2013). This helps the whole team to see the code and provides visibility of the project progress.

    Applicability

    Use Central Code Repository when:

    • Team is distributed over different time zones and is working on different modules/subsystem of the project.

    Participants

    Distributed onshore and offshore agile team members.

    Collaboration

    The onshore team and offshore team members share a keyboard with a fellow team member from their respective location and once they have finished a task they commit their code to a central code repository.

    Consequences

    The Central Code Repository pattern has the following benefits:

    1. It allows onshore and offshore team members to view each other’s code which helps overcome communication and coordination challenges.

    2. It helps in determining the progress of the project which helps overcome communication and coordination challenges.

    3. As all the team is committing to a central repository, if a team commits code with errors it can affect the whole build of the project.

    Known uses

    WDSGlobal is a leading global provider of knowledge-based services to mobile operators, manufacturers and application and sales channels. In 2004 they combined their developments, which were located in UK, USA and Singapore. They shared their code on a central code repository to minimize duplications and reduce cost of maintenance (Yap, 2005). Many companies use central code repository for their distributed projects such as Extol International (Kussmaul et al., 2004), Valtech (Danait, 2005), Manco (Ramesh et al., 2006), Aginity LLC (Armour, 2007) , SirsiDynix (Sutherland et al., 2007), CEInformant (Bose, 2008) and ABC Bank ( Modi et al., 2013).

    Related Pattern

    Central Code Repository pattern is often used with Global Scrum Board Pattern.

  3. Asynchronous Information Transfer Pattern
    Agile emphases on close face-to-face communication between the team members rather than detailed documentation. When a team is distributed on different time zones it has been observed that the teams adopted asynchronous tools for sharing information with each other such as emails, wikis, SharePoint. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Asynchronous Information Transfer

    Intent

    Due to the time difference between the onshore and offshore team use online tools to exchange information with each other. Each team should response to queries within 12hours.

    Also Known As

    Information Transfer or Knowledge Sharing

    Category

    Communication category as this pattern helps the onshore and offshore team members to answer each other’s queries within 12 hours.

    Motivation

    When a team is divided on different time zones they may have queries about work but due to the time difference they cannot get a direct reply at that time so they use emails to communicate queries, which are then answered within 12hours max. Organizations have set standards for response time in order to avoid delays in work (Vax, 2008).

    Applicability

    Use Asynchronous Information Transfer when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team members.

    Collaboration

    The onshore team and offshore team members share information and ask queries using asynchronous tools.

    Consequences

    The Asynchronous Information Transfer pattern has the following benefits:

    1. It allows onshore and offshore team members to exchange information when synchronous communication cannot be conducted due to working hours time difference.

    2. It helps team members from waiting for onshore team member availability to ask a query.

    3. If the team members don’t respond timely it can cause delays in the project.

    Known uses

    VTT Technical Research Center of Finland and National University of Ireland conducted a research on two organizations that were developing a system together. One organization was a customer organization in U.S and the other organization was a development organization located in Ireland. Based on their findings the companies used asynchronous tools for communication. They used wikis for storing documents and meeting minutes and used Emails for decisions and queries (Korkala, 2010). Similarly Valtech used Twiki for asynchronous communication (Danait, 2005).

    Related Pattern

    Asynchronous Information Transfer pattern is often used with Global Scrum Board and Synchronous Communication Pattern.

  4. Synchronous Communication Pattern
    Agile emphases on close face-to-face communication between the team members rather than detailed documentation. When a team is distributed on different time zones it has been observed that the teams adopted asynchronous tools for sharing information with each other such as emails, wikis, SharePoint. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Synchronous Communication Pattern

    Intent

    In order to discuss issues the teams uses synchronous tools for voice, video conferencing, document sharing, application sharing etc.

    Also Known As

    Synchronous Knowledge Transfer

    Category

    Communication category as this pattern helps the onshore and offshore team members to answer each other’s queries within 12 hours.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges.For example when a team is divided on different time zones they may have queries about work but due to the time difference they cannot get a direct reply at that time so they use emails to communicate queries, which are then answered within 12hours max. Organisations have set standards for response time in order to avoid delays in work (Vax, 2008).

    Applicability

    Use Synchronous Communication Pattern when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team members.

    Collaboration

    The onshore team and offshore team members share information and ask queries using asynchronous tools.

    Consequences

    The Synchronous Communication pattern has the following benefits:

    1. It allows onshore and offshore team members to exchange information when synchronous communication cannot be conducted due to working hours time difference. This helps overcome knowledge transfer, communication and coordination challenges.

    2. Team members can ask each other questions which builds trust and help understand each others socio-cultural differences, which helps overcome trust and socio-cultural challenges.

    3. It assists team members from waiting for onshore team member availability to ask a query.This helps overcome the communication and coordination challenges.

    4. If the team members don’t respond timely it can cause delays in the project.

    Known uses

    Campus Soft is a UK based company that used synchronous communication when they moved to Agile with their offshore suppliers in India and Romania. They used video conferencing facilities for planning sessions and later shifted to WebEx sessions and GoToMeeting so that they could share desktops with the remote team members. For daily Scrum meetings they preferred to use Skype call and made everyone wear headsets to make the meeting easier. For sprint review meetings they used sharing desktop tools as well as conference phones so that members from both end could talk with each other (Summers, 2008).

    Related Pattern

    Synchronous Communication pattern is often used with Global Scrum Board and Asynchronous InformationTransfer Pattern.

Collaboration Patterns

In this section we have described the detail of each collaboration pattern.

  1. Collaborative Planning Poker Pattern
    An agile team plays planning poker to put points estimation on each story card. The product owner also takes part in this activity. He tells the team the intent and value of a story card based upon which the development team assigns an estimation on the card. Based on the points assigned the team members who assigned the lowest and highest estimation will justify their reasons. The team will have a brief discussion on each story and assign an estimation upon which the whole team agrees on. It has been observed that even when the team is distributed the planning poker activity is conducted when both teams are co-located for the project planning activity. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Collaborative Planning Poker Pattern

    Intent

    Only Key people will hold this activity from onshore and offshore team.

    Also Known As

    Planning Poker or Scrum Poker

    Category

    Collaborative category as this pattern helps the onshore and offshore team to discuss the duration of a story card.

    Motivation

    The motivation of this pattern is to address the trust, socio-cultural communication and co-ordination, and knowledge transfer challenges. For example when a project is distributed to a team that is divided over different time zones, it is important that all the team members agree on the time duration of a feature before they start developing the project. This helps estimate the duration of the project completion as well as it provides visibility of project progress. For this purpose the onshore and offshore team members play planning poker in order to collectively agree on the estimation of a story card. Once the estimation is decided they write it down and approved by the product owner/client and move on to the next story card, till all the story cards are estimated.

    Applicability

    Use Planning Poker pattern when:

    • Team is distributed over different time zones and will be working on different story cards in a sprint.

    Participants

    Distributed onshore and offshore agile team and Product owner/Client.

    Collaboration

    The client approves the estimation made by the team members.

    Consequences

    The Planning Poker pattern has the following benefits:

    1. It allows the onshore and offshore teams to agree on a story card estimation, which helps the team establish their team velocity. Since members from both locations are present during this activity, this helps overcome trust and socio-cultural challenges.

    2. It provides the product owner/client with estimation of project completion.which helps overcome the communication and coordination, and knowledge transfer challenges.

    3. 3. If all team members don’t agree on estimation on a story card it can lead to a long discussion, resulting the planning poker to prolong.

    Known uses

    UShardward has development centers across North America, South America and Asia. When transitioning to distributed agile environment they used planning poker activity for estimation of their story cards (Wildt, Prikladnicki, 2010).

    Related Pattern

    Planning Poker Pattern is often used with Collective Project Planning as its better to conduct this pattern when the whole team is co-located. The estimated story cards are then shared on the Global Scrum board so that whole team can view them during the project.

  2. Follow-the-sun Pattern
    When a agile team is distributed over different time zones it has been observed that companies cut down on cost by increasing development time by adopting “follow the sun” workflow which means it allows 24 hours development due to the difference in time zones allowing a company’s employees to do development 24hrs a day (Carmel, Agarwal 2001; Yap, 2005; Kroll, et al., 2012).Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Follow-the-sun Pattern

    Intent

    Onshore and offshore teams will work 9a.m -5p.m according to their own time zones.

    Also Known As

    24hours development Patterns

    Category

    Collaboration category as this pattern helps the onshore and offshore team manage their work and handoff their work to the other team before they leave from work.

    Motivation

    The motivation of this pattern is to address the communication and co-ordination, and knowledge transfer challenges. For example consider a team that is divided into sub-teams that are located on different time zones. To adjust the working hours of the offshore team for both the onshore and offshore team work together is difficult as the offshore team has to come in the evening and stay till early morning. This makes the offshore team feel they are less important in comparison to the onshore team and it affects the employees’ social life. In order to avoid that, the onshore and offshore team “follow-the-sun” approach. For example an employee works from 9 a.m. to 5p.m. in the USA. At 5 p.m. she hands over the incomplete task to a colleague in Australia who works from 9 a.m. to 5 p.m. based on his time zone. At 5 p.m. according to his country, he transfers the updated task to a colleague in Poland who works on the updated task for the next eight-hours and then forwards it to his colleague in the USA (Gupta, 2009). While the employee in the USA had left work two of her colleagues worked on her task as when she will come to the office next morning a lot of the work would have been done. This work scenario takes advantage of the geographical distances as it allows people from different time zones to work round-the- clock in order to build software (Gupta, 2007). The work distribution among the team can be done in two ways. First either the 3 teams distributed on different geographical locations work on the same task and each team keeps updated the task as mentioned in the above scenario or secondly a most efficient way is that we divided different aspect of the same problem among the team for example in Figure 3 we can see how a problem has been distributed among 3 teams (Gupta, 2009):

    Applicability

    Use follow-the-sun pattern when:

    • Team is distributed over different time zones.

    • The onshore and offshore teams are working on different tasks.

    Participants

    Distributed onshore and offshore agile team.s.

    Collaboration

    Both onshore and offshore team hand over their work to each other at the end of every working day using online tools.

    Consequences

    The follow-the-sun pattern has the following benefits and liabilities:

    1. It allows continues development during different working shifts across different time zones, which helps overcome the communication and coordination challenges.

    2. It allows both onshore and offshore team to work according to their time zone without having to either come early to work or stay late till early morning and share their work without having to either come early to work or stay late till early morning. This helps overcome the knowledge transfer challenges.

    3. It reduces the development life cycle or time-to-market (Denny, et al., 2008).

    4. It limits the onshore and offshore team from real-time communication as the overlapping working hours between different time zones can be less or zero.

    Known uses

    Yahoo! used follow-the-sun approach when they off shored their Yahoo! Podcast product from Sunnyvale, California campus to Yahoo! Bangalore, India Campus (Drummond, Unson, 2008). Similarly organisations like WDSGlobal (Yap, 2005) and Wipro Technologies (Sureshchandra, et al.,2008) use follow-sun-approach.

    Related Pattern

    Follow-the-sun Pattern is often used with Local Standup meeting Pattern explained in 8.2 and Scrum of Scrum Pattern as both onshore and offshore team members are working separately.

  3. Collective Project Planning Pattern
    Agile focuses on individuals and interactions over processes and tools. While planning for the project the whole team is present. Unlike the traditional development where a project manager hands a project plan to the team. In agile the whole team takes part in the planning activity in order to determine when and how the project will be developed. It has been observed that even if the project is of a distributed nature it is better to co-locate the team onshore and offshore team for the project planning activity. Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Collective Project Planning Pattern

    Intent

    Both the onshore team and the offshore team will collectively work in the project-planning phase. Once both teams have engaged in the project planning activity, the team will prepare the project backlog.

    Also Known As

    Project Planning or Agile Project Planning

    Category

    Coordination category as this pattern helps the onshore and offshore team to work together and come up with a project plan.

    Motivation

    The motivation of this pattern is to address the trust, socio-cultural communication and co-ordination, and knowledge transfer challenges. For example consider a team that is divided into sub-teams that are located on different time zones and both the teams come to one location to do the project planning activity. In the beginning of any distributed project, the offshore team is invited to the onshore location so that they may work together and understand each other’s requirements.
    While the teams are co-located they worked on preparing the product backlog and they spend at least one or two sprints together before the offshore team leaves and starts working on the project (Cottmeyer,2008; Therrien,2008). This helps the onshore team by making the offshore team understand their working style and work standard.

    Applicability

    Use Collective Project Planning pattern when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team.

    Collaboration

    Onshore team and offshore team work together to make a product backlog.

    Consequences

    The Collective Project Planning pattern has the following benefits and liabilities:

    1. It allows the onshore and offshore teams to work together and understand each other.This helps build trust among the team members and overcome communication and coordination challenges.

    2. Onshore team works with the offshore team and makes them understand what type of work they want.This helps overcome the socio-cultural and knowledge transfer challenges.

    3. It adds additional cost of travel and stay of the offshore team at the onshore location.

    Known uses

    FAST, a search company with headquarters in Norway while building a search application on top of their core search platform used collective project planning to co-locate the team and make them work together in project planning activities (Berczuk, 2007). Siemens also used collaborative planning for their distributed projects (Avritzer, Paulish, 2010; Avritzer et. al, 2007) in which team members from multiple sites got involved in the early stages of the project in order to create an open communication channel and high level of trust among the distributed team members ( Avritzer et. al, 2010)

    Related Pattern

    Collective Project Planning Pattern is often used with Project Charter Pattern as it provides a central document that consists of the goal and objectives of the project written by the client.

  4. Visit onshore-offshore Team Pattern
    As agile emphases on close face-to-face communication between the team members it has been observed that when the team is divided on different time zones, the team members travel quarterly or annually to visit each other. This activity helps build trust among the team members and helps them understand each other’s cultural differences (Ramesh ,2006; Therrien, 2008; Summers, 2008; Paasivaara et al., 2014). Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Visit onshore-offshore Team Pattern

    Intent

    Both onshore and offshore teams should quarterly / annual visit each other in order to build trust, exchange cultural values and improve team coordination.

    Also Known As

    Travel onshore-offshore

    Category

    Collaboration category as this pattern helps the onshore and offshore team members to co-locate and understand each other and build a good relationship, which improves team coordination.

    Motivation

    The motivation of this pattern is to address the trust, socio-cultural communication and co-ordination, and knowledge transfer challenges. For example When a team is divided on different time zones they don’t feel that they are both part of one team and they don’t trust each other. They don’t understand each other’s cultural values and work ethics. In order to solve these issues the onshore and offshore team visits each other to develop the feeling of trust and understand each other’s cultural and working values. During these visits they attend training together as well as engage into informal activities to better understand each other. This helps build a bond between the team members, which results in good team coordination

    Applicability

    Use Visit onshore-offshore Team when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team members.

    Collaboration

    The onshore team and offshore team members visit each other to improve team coordination.

    Consequences

    The Visit onshore-offshore Team pattern has the following benefits:

    1. It allows onshore and offshore team members to exchange cultural values with each other and work ethics.This helps overcome socio-cultural and communication and coordination challenges.

    2. It helps team members to feel they are part of one team, which develops trust among onshore and offshore team members.This helps overcome trust and knowledge transfer challenges .

    3. The travelling adds additional cost to the project budget.

    Known uses

    Ericsson is a Swedish multinational provider of communications technology and services.To build a XaaS platform and a set of services they used agile software development methodologies. The development team was distributed over 5 sites located in 3 countries. Four of the sites were located in Europe and one was located in Asia. They conducted workshops, which were attended by team members from different locations. The purpose of these workshops was to create a common vision for the whole organisation by setting common values as well also to improve the collaboration between the sites, thus build trust (Paasivaara et al. 2014).

    Related Pattern

    Visit onshore-offshore Team pattern is often used with Collective Project PlanningPattern as planning is better done when thewhole team isco-located.

Verification Patterns

In this section we have described the detail of each verification pattern.

  1. Project Charter Pattern
    In project management, project charter is a statement that defines the scope, objectives and participants of a project. It is used to explain the roles and responsibilities, outline of the project objectives and identify main stakeholders. It has been observed that while starting a distributed project using agile many organisation use project charter to clarify the goals and objectives of the project to both onshore and offshore team (Galen, 2009).Based on this observed practice we have designed the following pattern details:

    Pattern Name

    Project Charter Pattern

    Intent

    Before starting the project planning activity, agile teams use project charter in order to have a central document between the onshore and offshore team that defines the project.

    Also Known As

    Project Definition or Project Statement

    Category

    Verification category as this pattern helps the onshore and offshore team to have a central document clarifying the project goals and objectives, which is written by the product owner/client.

    Motivation

    The motivation of this pattern is to address the trust,communication and co-ordination, and knowledge transfer challenges. For example when a project is distributed to a team that is divided over different time zones, a central document is written known as the project charter, which clarifies the onshore and offshore team the goals and objectives of the project. It also identifies the roles and responsibilities of the onshore and offshore team. The purpose of this activity is to have a document that helps the team in the project-planning task.

    Applicability

    Use Project Charter pattern when:

    • Team is distributed over different time zones.

    Participants

    Distributed onshore and offshore agile team and Client.

    Collaboration

    The client gives the project charter to the onshore team and offshore team to clarify the goals of the project.

    Consequences

    The Project Charter pattern has the following benefits:

    1. It allows the onshore and offshore teams to understand the project. This helps overcome communication and coordination, and knowledge transfer challenges.

    2. Since it is a single document stating the goals and objectives of the project it helps establish trust between the onshore and offshore team members.

    3. It is intended to clearly set the stage for the project by aligning the team and settings goals and expectations.

    Known uses

    IONA Technologies used Project Charter for their distributed projects in order to have a central document that clarifies the goals of the project to both onshore and offshore team members (Poole, 2004). Similarly in a case study conducted by Brown (2011) on Agile-at-Scale Delivery it was observed that organisations use project charter.

    Related Pattern

    Project Charter pattern is often used with Visit onshore-offshore Team.

  2. Onshore Review Meeting Pattern
    In agile, at the end of each sprint, a sprint review meeting is held in which the team meets with the clients and shows them the work they have done through a demo. In this meeting the client gives remarks about the work and if they require any changes they tell the team. It has been observed that when the team is distributed on different locations, then the team that is co-located with client conducts the review meeting.

    Pattern Name

    Onshore Review Meeting

    Intent

    The onshore team will present the demo as they are located where the client is.

    Also Known As

    Sprint Review Meeting

    Category

    Verification category as this pattern helps the client see the progress of the project as well as they can suggest early changes.

    Motivation

    The motivation of this pattern is to address the trust, socio-cultural communication and co-ordination, and knowledge transfer challenges. For example consider a team that is divided into sub-teams that are located on different time zones and one of the team is located in the same country as the client. In order to show the progress of the project it is more convenient that the team, which is located near the client, presents the demo in order to have a face-to-face meeting. Once the meeting has ended the onshore team briefs the offshore teams the remarks of the client.

    Applicability

    Use Onshore Review Meeting pattern when:

    • Team is distributed over different time zones.

    • The onshore is located in the same country as the client.

    Participants

    Distributed onshore and offshore agile team and Clients.

    Collaboration

    Onshore team presents demo to the client and discusses the meeting minutes with the offshore.

    Consequences

    The Onshore Review Meeting pattern has the following benefits and liabilities:

    1. It allows the client to meet the development team face-to-face and give feedback.This helps overcome the communication and coordination challenges.

    2. It allows both onshore and clients to discuss what changes they want and how much time will be required based on the modification.This helps overcome the knowledge transfer challenges.

    3. It limits the offshore team from meeting the clients which can cause the offshore team from discussing the changes and giving their remarks on the clients feedback.

    Known uses

    Wipro Technologies, a global service provider company used onshore review meetings so that they could get quick feedback from the customer/business user, which was then shared with the remote team over mail and/or teleconference (Sureshchandra et al., 2008). Similarly when SirsiDynix, USA outsourced their work to Starsoft, Ukrain they also used onshore review meetings to show the demo of the work done (Sutherland et al., 2007)

    Related Pattern

    Onshore Review Meeting pattern is often used with Asynchronous Retrospective Meetings Pattern because after the demo both onshore and offshore team members conduct their separate retrospective meetings.

References

Armour, Phillip G. "Agile… and offshore." Communications of the ACM 50, no. 1 (2007): 13-16.

Avritzer, Alberto, Francois Bronsard, and Gilberto Matos. "Improving Global Development Using Agile." In Agility Across Time and Space, pp. 133-148. Springer Berlin Heidelberg, 2010.

Avritzer, Alberto, William Hasling, and Daniel Paulish. "Process investigations for the global studio project version 3.0." In Global Software Engineering, 2007. ICGSE 2007. Second IEEE International Conference on, pp. 247-251. IEEE, 2007.

Berczuk, Steve. "Back to basics: The role of agile principles in success with an distributed scrum team." In Agile Conference (AGILE), 2007, pp. 382-388. IEEE, 2007.

Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., Sommerlad, P., & Stal, M. (1996). Pattern-oriented software architecture, volume 1: A system of patterns.

Bose, Indranil. "Lessons learned from distributed agile software projects: A case-based analysis." Communications of the Association for Information Systems 23, no. 1 (2008): 34.

Brown, W.J., Malveau, R.C., McCormick, H.W.S., Mowbray, T.J.: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. J. Wiley, 1998.

Carmel, Erran, and Ritu Agarwal (2001). "Tactical approaches for alleviating distance in global software development." Software, IEEE 18.2, 22-29.

Cottmeyer, Mike. "The good and bad of Agile offshore development." In Agile, 2008. AGILE'08. Conference, pp. 362-367. IEEE, 2008.

Damian, Daniela, and Deependra Moitra (2006). "Guest Editors' Introduction: Global Software Development: How Far Have We Come?." Software, IEEE 23, no. 5, 17-19.

Danait, Ajay. "Agile offshore techniques-a case study." In Agile Conference, 2005. Proceedings, pp. 214-217. IEEE, 2005. Drummond, B., and John Francis Unson. "Yahoo! Distributed Agile: Notes from the world over." In Agile, 2008. AGILE'08. Conference, pp. 315-321. IEEE, 2008.

Fowler, Martin. Analysis patterns: reusable object models. Addison-Wesley Professional, 1997.

Galen, RobertSCRUMProductOwnership – BalancingValue from the InsideOut RGCG LLC 2009. ISBN: 978-0-578-01912-3

Gamma, Erich, Richard Helm, Ralph Johnson, and John Vlissides. Design patterns: elements of reusable object-oriented software. Pearson Education, 1997.

Gupta, Amar (2009). "Deriving mutual benefits from offshore outsourcing."Communications of the ACM 52, no. 6 : 122-126.

Holmstrom, H., Conchúir, E. Ó., Agerfalk, J., & Fitzgerald, B. (2006). Global software development challenges: A case study on temporal, geographical and socio-cultural distance. In Global Software Engineering, 2006. ICGSE'06. International Conference), 3-11.

Hossain, Emam, Muhammad Ali Babar, and Hye-young Paik. "Using scrum in global software development: a systematic literature review." In Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International Conference on, pp. 175-184. Ieee, 2009.

Kamaruddin, Nina Kamarina, Noor Habibah Arshad, and Azlinah Mohamed. "Chaos issues on communication in Agile Global Software Development." In Business Engineering and Industrial Applications Colloquium (BEIAC), 2012 IEEE, pp. 394-398. IEEE, 2012.

Kroll, Josiane, Alan R. Santos, Rafael Prikladnicki, Estevão Ricardo Hess, Rafael A. Glanzner, Afonso Sales, Jorge Luis Nicolas Audy, and Paulo Henrique Lemelle Fernandes. "Follow-the-Sun Software Development: A Controlled Experiment to Evaluate the Benefits of Adaptive and Prescriptive Approaches." In SEKE, pp. 551-556. 2012.

Korkala, Mikko, Minna Pikkarainen, and Kieran Conboy. "Combining agile and traditional: Customer communication in distributed environment." In Agility Across Time and Space, pp. 201-216. Springer Berlin Heidelberg, 2010.

Kussmaul, Clifton, Roger Jack, and Barry Sponsler. "Outsourcing and offshoring with agility: A case study." In Extreme Programming and Agile Methods-XP/Agile Universe 2004, pp. 147-154. Springer Berlin Heidelberg, 2004.

Maruping, Likoebe M. "Implementing Extreme Programming in Distributed Software Project Teams: Strategies and Challenges." In Agility Across Time and Space, pp. 11-30. Springer Berlin Heidelberg, 2010.

Massol, Vincent. "“Case Study: Distributed Agile Development." TheServerSide. com (2004).

Modi, Sunila, Pamela Abbott, and Steve Counsell. "Negotiating common ground in distributed agile development: A case study perspective." In Global Software Engineering (ICGSE), 2013 IEEE 8th International Conference on, pp. 80-89. IEEE, 2013.

Paasivaara, Maria, Sandra Durasiewicz, and Casper Lassenius. "Using scrum in distributed agile development: A multiple case study." In Global Software Engineering, 2009. ICGSE 2009. Fourth IEEE International Conference on, pp. 195-204. IEEE, 2009.

Pilatti, Leonardo, and Jorge Luis Nicolas Audy (2006). "Global Software Development Offshore Insourcing Organizations Characteristics: Lessons Learned from a Case Study." In Global Software Engineering, 2006. ICGSE'06. International Conference, 249-250.

Poole, Charles J. "Distributed product development using extreme programming." In Extreme Programming and Agile Processes in Software Engineering, pp. 60-67. Springer Berlin Heidelberg, 2004.

Ramesh, Balasubramaniam, Lan Cao, Kannan Mohan, and Peng Xu. "Can distributed software development be agile?." Communications of the ACM 49, no. 10 (2006): 41-46.

Räty, Petteri, Benjamin Behm, Kim-Karol Dikert, Maria Paasivaara, Casper Lassenius, and Daniela Damian. "Communication Practices in a Distributed Scrum Project." CoRR (2013).

Robertson, S. (1996). Requirements Patterns Via Events/Use Cases. In Proceedings Pattern Languages of Programming.

Šmite, Darja, Nils Brede Moe, and Pär J. Ågerfalk (2010). "Fundamentals of Agile Distributed Software Development." In Agility Across Time and Space, pp. 3-7. Springer Berlin Heidelberg

Summers, Mark. "Insights into an Agile adventure with offshore partners." In Agile, 2008. AGILE'08. Conference, pp. 333-338. IEEE, 2008.

Sureshchandra, Kalpana, and Jagadish Shrinivasavadhani. "Adopting agile in distributed development." In Global Software Engineering, 2008. ICGSE 2008. IEEE International Conference on, pp. 217-221. IEEE, 2008.

Sutherland, Jeff, Anton Viktorov, Jack Blount, and Nikolai Puntikov. "Distributed scrum: Agile project management with outsourced development teams." In System Sciences, 2007. HICSS 2007. 40th Annual Hawaii International Conference on, pp. 274a-274a. IEEE, 2007.

Therrien, Elaine. "Overcoming the Challenges of Building a Distributed Agile Organization." In AGILE, pp. 368-372. 2008.

Vax, Michael, Stephen Michaud, "DistributedAgile: Growing a PracticeTogether,"AGILE Conference, pp. 310-314, Agile2008, 2008

Wildt, Daniel, and Rafael Prikladnicki. "Transitioning from Distributed and Traditional to Distributed and Agile: An Experience Report." In Agility Across Time and Space, pp. 31-46. Springer Berlin Heidelberg, 2010.

Yap, Monica. "Follow the sun: distributed extreme programming development." In Agile Conference, 2005. Proceedings, pp. 218-224. IEEE, 2005.

Contact Us

Maryam Kausar

Email: m.kausar@edu.salford.ac.uk

Phone: +44 (0) 74 00 218592



Adil Al-Yasiri

Email: a.al-yasiri@edu.salford.ac.uk

Phone: +44 (0)161 295 6399