Classes of Distributed Agile Development Problems

Mira Kajko-Mattsson, Gayane Azizyan, Miganoush Katrin Magarian, KTH School of Information and Communication Technology

Royal Institute of Technology Stockholm, Sweden

mekm2@kth.se, gayane@kth.se, mkmk@kth.se

Abstract— Little is known about problems encountered in distributed Agile development environments. There have been some case studies reporting on them. However, these studies have been mainly limited to the scope and context of only one or a few companies. As a result, we do not possess an overall picture of what types of problems and challenges the companies may encounter in distributed Agile environments. In this paper, we analyze twelve case studies from the existing literature, identify thirteen problems reported in them and their solutions, and we group the problems into six classes: Culture, Time Zone, Communication, Customer Collaboration, Trust, Training and Technical Issues.

Keywords- culture; communication; trust; customer availability; time zones

I. INTRODUCTION Being in stark contrast with each other, Agile and

Distributed Software Development (DSD) methods are regarded as partners in an impossible marriage. Despite this, many organizations consider them as practices worth striving for. Hence, they attempt to combine those two into a common Distributed Agile Development (DAD) model [7, 8, 15, 19].

The matrimonial relationship between the two methods has been evaluated in various individual case studies. These studies provide valuable feedback on problems and challenges that might be found useful by the companies and academics willing to integrate the two methods. Their results, however, are strongly dependent on their individual study contexts. They are also scattered in different articles. As a result, the software community lacks an overall picture of what types of problems and challenges companies may encounter when attempting to marry Agile and distributed methods. They are also not sure whether it is possible to combine those two methods.

In this paper, we have analyzed twelve different case studies and consolidated their results by creating seven DAD problem classes and by identifying their solutions. Our goals are (1) to identify common DAD problems faced by the companies today, (2) to keep software organizations alert on the DAD problems, (3) to elicit solutions to them, and finally, (4) to provide a platform for further DAD problem classification and software development research.

In striving towards that end, this paper is organized into six major sections. The next section, Section 2, describes the research method taken in this study. Section 3 briefly

compares Agile and distributed methods. Section 4 presents the case studies that were included in our analysis as well as the problems and their solutions extracted from them. Section 5 presents the DAD problem classes and their solutions. Finally, Section 6 makes conclusions and suggestions for future work.

II. RESEARCH STEPS Our study was entirely based on reviews of various

articles dealing with Agile principles in DSD. It was conducted in six main phases: (1) Conflict Identification, (2) Criteria Definition for Choosing Case Studies, (3) Choice of Case Studies, (4) Problem Extraction, (5) Problem Classification, and finally, (6) Solution Analysis.

In the Conflict Identification phase, we compared the inherent characteristics of DSD with Agile principles. For each DSD characteristic, we listed some of its conflicting Agile principles. The goal was to identify potential difficulties and sources of problems that might arise when implementing Agile practices in a distributed setting.

Today, there is a myriad of research publications on the subject. To identify the most appropriate ones, we defined criteria for selecting them in the Criteria Definition for Choosing Case Studies phase. The publications to be chosen should contain a detailed description of the problems encountered and the solutions used to address them. Case studies which did not contain enough details or complete information were left out.

In the Choice of Case Studies phase, we searched for publications using the specified criteria. We studied sources such as IEEEXplore, ACM, Springer, Wiley & Sons and the like. To our surprise, we only found twelve case studies satisfying our criteria. These were [1, 2, 6, 9-14, 16-18]. It is these case studies that constitute the platform for the work presented in this paper.

As a next step, in the Problem Extraction phase, we listed all the problems that have been reported in the case studies. To get their full and consistent understanding, we first defined a pattern for how to describe them. The pattern covered the following structure: (1) problem name, (2) problem class, (3) problem description, (4) problem reasons, (5) problem remedies, and finally, (6) identification of the related problems.

In the Problem Classification phase, we went through our initial problem descriptions and classifications. This resulted in an improved understanding of the problems, leading to

2010 Agile Conference

978-0-7695-4125-9/10 $26.00 © 2010 IEEE

DOI 10.1109/AGILE.2010.14

51

improved problem descriptions and some problem re-namings and re-classifications. Based on these results, we then created seven classes of problems that have been encountered in the DAD context.

Finally, in the Solution Analysis phase, we studied the problems and their solutions anew in order to find out whether it is possible to marry the two approaches.

III. RELATED WORK In this section, we briefly describe related work. As

already mentioned, most publications deal with individual case studies. There is, however, one study attempting to provide an overview of the potential problems encountered in the DAD context [8].

Regarding the individual case studies, their main goal was to report on how organizations tried to reap the benefits of both approaches. Although most of those organizations gained success, they faced problems as well. It took them some effort and resources to understand the existing situation and to identify problems and correlations among them. It took them just as much effort and resources to solve these problems. In some cases, they had to hire consultants, or come up with a patchwork way of dealing with the situation. Obviously, they lacked a universal and well-defined overview of problems that they could refer to as a guideline. [1]

Regarding the work attempting to provide an overview of the potential problems to be encountered in the DAD context, it was made by Ramesh, Cao, Mohan and Xu [8]. By analyzing the characteristics of the distributed and Agile methods, the authors pointed out potential conflicts, such as communication need vs. communication impedance, fixed vs. evolving quality requirements, people vs. process oriented control, formal vs. informal agreements, and lack of

team cohesion. They further provided a list of practices which companies should follow in order to resolve these conflicts. They concluded by demonstrating three case studies in which these practices proved effective.

The classification conducted by Ramesh et al. [8] is the result of comparing two approaches – Agile development and DSD. It is not based on any real-life case study. It is thus a list of the potential points of conflicts between these two approaches. As opposed to the classification of Ramesh et al. [8], our classification is performed on problems encountered in the empirical case studies. Hence, it is a compilation of the experienced real-life conflicts that may arise in DAD settings.

IV. PROBLEM DESCRIPTIONS The industrial actors in the case studies are briefly

summarized in Table 1 [1, 2, 6, 9-14, 16-18]. As can be seen there, the majority of the outsourcers (9 companies) come from North America and the majority of the outsourcees come from Asia (8 companies). There are however three European outsourcers and three European outsourcees. All these companies use Agile methods, mainly Scrum and XP. In this section, we present problems as encountered by these companies. For easy referencing, we number each of the problems listed.

Problem 1: Notion of Responsibilities

The offshore team had a deep-rooted and rigid perception and understanding of their responsibilities. For example, in [14], the offshore developers felt that their seniority entitled them to conducting only pure development tasks, and that testing and documentation tasks should be carried out by junior developers with “lower” positions. In [10], team members felt that they were only responsible for their own

TABLE 1. SUMMARY INFORMATION OF CASE STUDIES

Onshore location Offshore location Agile method Project

CS1 Norcross, GA, USA India Scrum, XP Development of a billing platform for financial transactions

CS2 USA Bangalore, India Scrum Development of Podcast software

CS3 Helsinki, Finland Oulu, Finland N/A Development of a mobile front-end application integrated with

an existing product

CS4 USA Bangladesh Scrum Development of web-based management solution

CS5 UK India, Romania Scrum Migration of an educational platform from a legacy system and

development of new functionalities.

CS6 USA India, Hong Kong N/A N/A

CS7 Netherlands India Scrum, XP Development of railway information system

CS8 Santa Ana, CA, USA Bangalore, India Scrum Development of online marketing solution

CS9 CA, USA Hyderabad India,

Beijing China Scrum

Development of a web application for the automotive dealership market, Development of an internal tool

CS10 Texas, USA Krakow, Poland Scrum, XP Upgrading of the underlying technology of a real-time data

management system

CS11 Toronto, Canada Berkeley, CA, USA Concord, MA, USA

XP Development of a portal-based e-learning system

CS12 Canada Russia Scrum Migration of existing e-commerce system to a new platform

52

parts. They did not feel collectively responsible for the overall development. We call this problem the Notion of Responsibilities problem. It directly opposes the Agile principles of collective code ownership, self-organizing and cross-functional teams.

The Notion of Responsibilities problem is attributed to cultural differences [14]. To make it more specific, we attribute it to a hierarchical structure in the workplace, where there is a strict division between different ranks and responsibilities.

Hierarchical perceptions of responsibilities directly hurt productivity and affected teamwork. To remedy the problem, exchange visits and team building exercises were organized to show the offshore team that all team members could perform documentation and testing tasks, regardless of their seniority and role assignment [14]. As a result, team members became collectively responsible for the Sprint deliverables. The Sprint review and retrospective meetings became increasingly productive.

Problem 2: Notion of Directness and Honesty

The communication between the onshore and offshore teams was not always honest and direct. This was due to different perceptions of how honest and direct one should be. For example, (1) the offshore team was filtering only positive information to the onshore team, being reluctant to provide honest information about problems [2], (2) the offshore team members were not accustomed to giving and receiving direct feedback [2], (3) the offshore team members were not willing to express disagreements, to debate ideas, or to reveal that they had understanding problems [2], and finally, (4) the onshore team members were loud and direct, while the offshore team members were timid and careful in expressing their opinions [12].

The problem of directness and honesty in communication is attributed to cultural notions in [9], where it is not common to provide direct and open feedback, especially negative one. Being uninformed about each other’s problems, a knowledge mismatch between the onshore and offshore teams was created. This directly opposed the Agile principles of open, direct communication and trust.

The Notion of Directness and Honesty problem was remedied by coaching the offshore team by a neutral, third-party Agile coach, which led to a more open, free and honest communication [2]. Moreover, the onshore team members were coached on how to provide constructive feedback [9]. The information shared in this manner helped both teams to understand the existing problems and introduce changes. The onshore team members succeeded to create a safer, more open environment and to maintain good personal relationships by being very explicit in their communication and by organizing travels at the beginning of and throughout the project. In addition, a team culture aimed at openness and direct communication was actively developed by the ScrumMasters.[1, 12]

Problem 3: Notion of Authority

The offshore team had a hierarchical notion of authority. The bodies regarded as authorities were onshore

management and clients and offshore senior team members. The offshore teams had a “command-and-control” view of management, deferring to team leads and managers as being the sole decision-makers and speakers during meetings [1. 12-14]. Hence, the offshore team members did not dare to disagree with the onshore team members due to their seniority and client role. They viewed the client as being their “boss” and thus felt compelled to oblige to any request [1, 9, 11, 14].

Consequences of the authority problem were not explicitly mentioned in the case studies. However, when further analyzing them, we understood that these problems hindered communication, open knowledge transfer, process improvement and created divisions between team members and management. This opposes the Agile principles of open, direct communication and trust as well as close cooperation between business people and developers.

To remedy these problems, an attempt was made to break the hierarchical relationships and to build trust. To realize it, open office spaces were created by removing cubicles and relocating managers and leads from separate offices into a common space. Also, to boost unhindered communication, the people were encouraged to address each other by first name [9].

Other remedies to the problem concerned team building exercises and requirements negotiations. For instance, team building exercises were launched to blur distinctions between different roles [14]. To learn the process of negotiation, the offshore team was allowed to participate in the negotiation meetings with the client [9]. Finally, in cases when a successful solution could not be found, the onshore team members had to learn the body language of the offshore team members instead [11]. With some practice, they could understand the underlying problems in an implicit way.

Problem 4: Language Barriers

Communication between the onshore and offshore teams was immensely hampered due to language barriers [14]. The corporate language was English implying that all business, meetings, and conference calls were conducted in this language. Here, poor knowledge of English of the offshore side created great communication difficulties.

Although direct consequences are not mentioned in the case studies, we believe that language barriers directly affect productivity and create problems of miscommunication. This opposes the Agile principles of open, direct communication, and trust, as well as close cooperation between business people and developers. The language barrier problem was remedied by organizing language classes [14].

Problem 5: Public holidays and vacations

Different cultures often have different public holidays at different dates. Moreover, people of different cultures prefer to take vacations at different times of the year. These factors must be taken into account in order to ensure and plan for the availability of different team members, as well as, to prevent frustration of having to work during public holidays. In the analyzed cases studies, problems arose while scheduling projects because public holidays in the onshore and offshore

53

countries were not considered in advance [10], For instance, unavailability of the customer on the onshore side early in the development stage made the offshore team waste their time while waiting for his feedback. This caused a major disruption and delay of the project.

We believe that the problem of public holidays and vacations originates from cultural differences. Not paying heed to them caused scheduling problems as well as customer unavailability during critical times. As a remedy, a team calendar was built which took into account all the differences [10]. This substantially helped in future project planning.

Problem 6: Synchronization and Planning

Due to time zone differences between onshore and offshore teams, it was difficult to organize daily meetings. The teams had to work outside ordinary working hours. In many cases, one of the teams had to work long hours from home in order to accommodate the other team. It was even more problematic when the teams did not have overlapping weekends. In the worst case scenario, there was a 12-hour time zone difference between the teams, and the onshore team had weekends on Saturdays and Sundays whereas some offshore teams had weekends on Fridays and Saturdays. [1, 2, 9, 13, 17, 18].

The time zone problem resulted in tired and frustrated team members. To remedy it, the companies studied created solutions such as (1) the daily working hours were shifted towards the evenings or mornings to prevent team members from having extremely long workdays, (2) whenever possible, the teams tried to find meeting times that fit best for both locations, (3) the teams worked late shifts, (4) the teams had daily meetings either early in the mornings or late in the evenings, and finally, (5) the teams had asynchronous meetings via project managers [1, 2, 9, 13, 18].

Problem 7: Distant Collaboration

Due to the distributed nature of the teams, it became a challenge to find efficient ways of communicating between onshore and offshore team members. In most cases, emails and instant messages proved to be insufficient for maintaining the daily communication as dictated by the Agile values. For example, copying and pasting code in emails was inefficient and unproductive when detailed code discussions were necessary [17]. Audio discussions were not always possible or they were cumbersome because all screens were not synchronized. Using emails and instant messages resulted in a slow turnaround communication [18] and often caused misunderstandings due to their being composed quickly [1]. It was difficult to communicate the client’s nuances, contexts, and priorities to the offshore team members [12]. With time, managing emails and electronic spreadsheets became more difficult and burdensome as the team and project knowledge grew in size and complexity [9].

In the case studies studied, direct consequences of the Distant Collaboration problem are not mentioned. Implicitly, however, we understand that the main consequence is the additional burden on the onshore and offshore teams and thereby a negative impact on productivity [1]. The problem

Distant Collaboration directly opposes the Agile principle of close, face-to-face communication.

Although there is lack of a universal solution to this problem, the teams attempted to find ways to mitigate it. These ways encompassed solutions such as (1) desktop sharing combined with videoconferences and virtual stand-up meetings [17], (2) use of asynchronous communication tools such as a wiki, bug management systems, newsgroups, and email [17], (3) replacing direct communication with documentation [1], (4) use of specialized collaboration tools replacing spreadsheets and emails [9], (5) establishing several lines of communication between the onshore and offshore teams in which, for instance, the ScrumMasters communicated on status and task information while the technical leads communicated on design and technical issues [18], (6) encouraging communication between team members on all levels by providing contact details on the project site, and, finally, (7) by scheduling regular travels [12].

Problem 8: Increased documentation Lack of close collaboration between distributed teams

resulted in increased documentation. Both onshore and offshore teams had to rely on written communication, that is, documentation [1, 10]. This opposes the Agile value of less documentation.

A solution to the Increased Documentation problem was to write as little documentation as possible, sufficient enough to maintain communication. [1]. The solution was to avoid heavily documenting requirements [10]. Instead, important information, such as information elicited during conference calls, should be documented in presentation slides. It should be documented in such a way so that it could provide support for organizing and sending important messages and clarifications.

Problem 9: Inefficient Remote Conferences

Remote conference calls were used for conducting meetings with remote team members. In some case studies, they were however not always efficient. The problems as reported by the case studies were (1) some team members became inactive during meetings held over text or voice chat [17], (2) it was not clear whether there would be an eventual response, whether the participants were simply distracted, or whether the discussion should continue [17], (3) video conference calls were problematic and much time was spent on resolving technical issues [16], (4) bad quality sound combined with the overlaps of several people speaking at the same time caused the remote listeners to lose track of what was being said and by who [16].

A direct consequence of the Inefficient Remote Conferences problem was a hindered communication between onshore and offshore teams. To remedy the problem, the following solutions have been implemented: (1) the companies used mainly video conferences for resolving misunderstandings and doubts [5], (2) the video conferences were used for long meetings only [16], and (3) team members participated in conference calls from their own desks instead of participating in a common conference room.

54

Problem 10: Team Bonding and Cohesion

Due to the team distribution over different locations, additional efforts were needed to foster team bonding, to boost efficient collaboration, and to build trust between distributed team members. When a new team member was added to the offshore team, it was not always clear how this would affect the team chemistry and collaboration [17]. It was anticipated that there would be a problem of team bonding and close relationships among the teams due to lack of frequent face-to-face communication [1, 2, 9-11, 18]. There was a concern that due to lack of trust, both onshore and offshore team members would not be able to show vulnerability or weakness without losing self-esteem [14].

The reason behind the Team Bonding and Cohesion problem was lack of face-to-face communication between the onshore and offshore teams. Although direct consequences are not mentioned, we believe that the problem had led to lack of trust and loss of productivity. To resolve it, the teams tried to create closer connections with each other. For instance, (1) the onshore and offshore team members exchanged photographs of each other and hung them up on the walls [1], (2) planned personnel rotations were organized, where a small part of the offshore team was moved onshore [1, 10, 11], (3) new team members were introduced to everyone by means of a video conference [17], (4) all team members were regularly brought together for planning meetings [2], and finally, (5) team building exercises were conducted to build trust between team members [2].

Problem 11: Unavailability of Customer or Customer

Proxy The offshore teams had no direct communication with

the customer. Being located onshore, the customer or customer proxy was not easily available to the offshore teams, who lacked insight into the direction of the project and felt disenfranchised in the development process [11, 13, 16]. The situation was strongly aggravated by the fact that the offshore teams only received brief story descriptions or acceptance criteria. Having insufficient domain knowledge, they could not even make educated guesses [16]. In other cases, problems arose because the customer proxy between the development team and the product owner could not communicate with the customer on a daily basis, given that the customer did not actively respond to questions and emails [6].

Reasons to the customer unavailability are not directly mentioned in most case studies. Only one case study states that the Agile customer did not communicate with the offshore team due to being overburdened with writing user stories and answering the questions of the onshore teams [16].

Having no direct access to the customer caused the offshore teams to lose an overall vision of the product. Misunderstood requirements were continuously implemented, thus leading to frequent need for rework [13]. The offshore team did not have anyone to answer their questions and to verify acceptance criteria, causing substantial productivity decrease [16]. In some cases,

customer unavailability indirectly caused other problems. The outsourced team believed that the proxy role was well-informed about the customer requirements, even though in some cases, the proxy lacked information from the customer. This situation created a false sense of confidence and security within the outsourced team. [6]

To remedy the Unavailability of Customer or Customer Proxy problem, the product owner traveled to the offshore team at the start of each release, as well as communicated directly with the offshore team by means of emails [11, 13]. This helped the offshore team gain an overall vision of the product as well as increased the team trust and efficiency. In other cases, a senior offshore developer with good domain knowledge was assigned the role of a customer proxy and feature owner [16]. Engaging other team members in the requirements process helped to detect issues that otherwise passed unnoticed by the proxy role [6].

Problem 12: Skill Differences

The onshore and offshore teams had differences in skills. They were manifested in various ways. For instance, (1) the offshore team lacked methodological skills in the Agile methods [1, 2, 9, 14], or the onshore and offshore teams were implementing Agile practices differently and had no visibility into each other’s way of working [10], (2) there was a dramatic difference in technical skills between the onshore and offshore teams [1], (3) the teams were proficient in different programming languages, and none of them was willing to change programming languages [17], and finally, the customer had no previous experience in Agile development [12].

The consequences of the skill differences were decreased productivity and hindered teamwork. The velocity of the onshore team greatly decreased when the onshore senior developers had to work above their capacity in order to compensate for the lack of skill of the offshore team. This caused frustration and tiredness of the onshore team [1].

Lack of training in Agile methods was solved by providing an initial training by an Agile coach [2, 14]. The offshore team and the product owner became habituated with the Scrum artifacts and practices on a pilot project and an on-site informal training session [9]. To overcome the difficulties caused by the different implementations of Agile practices in the onshore and offshore teams, each team prepared a detailed presentation regarding their daily work, and a wiki page was set up where teams described in detail how they implemented different Agile practices [10]. In order to bring the customer into an Agile way of working, an Agile project manager was brought into the company [12]. In cases where the teams were proficient in different programming languages, a common framework was introduced that enabled both teams to work with the languages they were proficient in [17].

Problem 13: Technical Issues

Differences in infrastructure, technology availability and organizational standards hamper the collaboration of the onshore and offshore teams. For example, (1) the offshore team failed to adhere to coding standards or they developed

55

new components instead of re-using the existing ones [14], (2) the offshore team members had very inconsistent access to high-speed internet from their homes which forced them to be present in the office during all meetings [13], (3) infrastructure issues affected connectivity during conference calls, and (4) the onshore and offshore teams used different platforms and operating systems [17].

Given the wide variety of technical problems, their solutions are equally wide and varied. In some cases, the offshore team received developer support in order to avoid gathering of technical debt, exchange visits from the onshore team were increased in frequency, and the onshore team was given less complicated tasks [14]. When lack of a common infrastructure was anticipated to create problems, a shared electronic workspace was set up for maintaining contact, for giving status updates, and for sharing news and documentation [18]. In some cases, a good solution for solving the technical issues was not found [13].

V. PROBLEM CLASSES The thirteen problems listed in this paper provide many

challenges to the organizations adopting Agile methods in distributed settings. As shown in Table 2, we have identified five classes of problems. These are Culture, Time Zone, Communication, Trust, Customer Collaboration, Training and Technical. Below, we briefly elaborate on them.

TABLE 2. CLASSES OF DAD PROBLEMS

Culture

P1 Notion of Responsibilities

P2 Notion of Directness and Honesty

P3 Notion of Authority

P4 Language Barriers

Time Zone

P5 Public Holiday and Vacation

P6 Meeting Synchronization and Planning

Communication

P7 Effective Collaboration

P8 Increased Documentation

P9 Effective Remote Conferences

Trust

P10 Team Cohesion and Bonding

Customer Collaboration

P11 Unavailability of Customer or Customer Proxy

Training

P12 Skill Differences

Technical

P13 Technical Issues

• Cultural Differences: Being part of one culture, we share common beliefs, values, attitudes, hierarchies, religions, notions of time, spatial relationships and the like. When being forced to interact with each other, our belongings to different cultures manifest themselves in various problems. In the DAD context, we have identified five cultural problems. They concern Notion of Responsibilities, Notion of Directness and Honesty, Notion of Authority and Language Barriers.

• Time Zone: Time zone differences can be both

beneficial and detrimental for a project. It is beneficial in the sense that it implies working in shifts. For example, an onshore team could assign a task at the end of the working day and the offshore team could provide the result in the next morning. When it comes to intimate co-operation in the Agile way, time zone differences may be detrimental. This has proved true in the DAD context in the sense that the companies distributed over several time zones encounter the problems of Public Holiday and Vacation, and Meeting Synchronization and Planning.

• Communication: Communication involves parties such

as onshore and offshore teams and media such as documentation or technical transmission solutions. In the DAD context, we have identified the following communication problems: Effective Collaboration, Increased Documentation, and Effective Remote Conferences.

• Trust: Trust is a conviction and reliance on a person or

organization that they behave responsibly and honorably with respect to the obligations assigned to them. In the DAD context, we have identified one trust problem. It concerns Team Cohesion and Bonding.

• Customer Collaboration: In an Agile context,

customers are expected to make personal commitments to being available to developers on a frequent basis. In the DAD context, we have identified one customer collaboration problem which is Unavailability of Customer or Customer Proxy.

• Training: Training issues may arise in virtually any

context where a new method is introduced. In the DAD context, these issues are aggravated by the problems of Skill Differences.

• Technical: Similarly to the training problem described

above, technical problems may arise in any context. In the DAD context, we have classified such problems under Technical Issues.

56

VI. FINAL REMARKS In this paper, we have analyzed twelve different case

studies and consolidated their results by creating seven DAD problem classes. They are based on common DAD problems as faced by the companies today. For this reason, we believe that it creates an excellent source of information and alerts for the companies willing to introduce Agile methods in their distributed development environments. Many of the problems listed in this paper are not new. Some of them are encountered in somewhat different wrappings in non-distributed development environments as well [3, 4, 5]. Hence, some of solutions as identified in this study may be relevant for both distributed and non-distributed environments.

For most of the problems, the organizations could find solutions. Communication problems were remedied in various ways depending on the context. Whereas documentation of requirements was decreased to avoid the communication and change overhead, the documentation of the process related issues was increased to replace direct communication and to avoid miscommunication and misunderstandings. Tools were introduced and more direct contact was increased in form of regular travels. Also, specific roles were assigned the responsibility for communicating on limited areas. Finally, lack of direct contact was remedied by introducing video conferences to be managed directly from the team member desks.

The times zone problems were removed by shifting the working hours of both the onshore and offshore teams, by adjusting direct meetings to the time zones or by creating asynchronous meetings via project managers. Even the holiday and vacancy problem was partly remedied by creating a team calendar aiding in project planning.

The trust problem was resolved by frequent meetings in various forms such as video conferencing, personnel rotations, and team building exercises. The customer collaboration problem was solved by frequent travels of the onshore product owner or by creating an offshore customer proxy. The training and technical problems were overcome by presenting detailed descriptions of daily work, by allowing teams to work with the technology they were comfortable with, and by supporting each other with respect to various technical problems.

Even the trickiest problems, the cultural problems, could be remedied to some extent. Many cultural problems are built on strong and deep rooted differences in mentality and culture. Aspects such as hierarchical way of acting or indirect honesty can take several generations of programmers before they get solved. They were, however, partially remedied via (1) team building exercises to blur the distinctions between different role levels, (2) imposition of collective ownership, (3) introduction of a neutral third-party Agile coach, (4) removal of the physical walls between the managers and developers, and (5) the creation of a close cooperation between business people and developers.

VII. EPLOGUE As always, pairing dissimilar mates implies many infant

problems. Some of them have been compiled in this paper. Their list may already provide a source of information and alerts for the companies willing to introduce Agile methods in their distributed development environments. It may also constitute an initial version of a platform for creating Distributed Agile Development problem classes. We sincerely invite the software community to further extend it with new problems and solutions. It is only in this way we may commonly help the industry to master the DAD problems.

REFERENCES [1] G M. Cottmeyer, “The goods and bad of Agile offshore

development,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 362-367.

[2] B. Drummond and JF Unson, "Yahoo! distributed Agile: Notes from the world over," in Proc. AGILE 2008 Conference, Toronto, IEEE Computer Society, Canada, 4-8 August 2008, pp. 315-321.

[3] Kajko-Mattsson M., Problems in Agile Trenches, in Proc. International Symposium on Empirical Software Engineering and Measurement, ACM, 2008, pp. 111-119.

[4] Kajko-Mattsson, M., Ochenyi, H., Good and Bad Sides of Agile Methods, Part 1, in Proc. International MultiConference in Computer Science & Computer Engineering (SERP 2009), CSREA Press 2009, ISBN 1-60132-129-5, 2009, pp. 502-508.

[5] Kajko-Mattsson, M., Ochenyi, H., Good and Bad Sides of Agile Methods, Part 2, in Proc. International MultiConference in Computer Science & Computer Engineering (SERP 2009), CSREA Press 2009, ISBN 1-60132-129-5, 2009, pp. p. 509-515.

[6] M. Korkala and P. Abrahamson, "Communication in distributed Agile development: A case study," in Proc. 33rd EUROMICRO Conference on Software Engineering and Advanced Applications, 2007, pp. 203-210.

[7] M. Passivaara and C. Lassenius, “Could global software development benefit from Agile methods?” in Proc. International Conference on Global Software Engineering (ICGSE’06), IEEE Computer Society, Florianopolis, Brazil, 2006, pp. 109-113.

[8] B. Ramesh, L. Cao, K. Mohan, and P. Xu, “Can distributed software development be Agile?,” Communication of ACM, October 2006, Vol. 49, No. 10, pp. 40-52.

[9] S. H. Rayhan and N. Haque, “Incremental Adoption of Scrum for Successful Delivery of an IT Project in a Remote Setup,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 351-355.

[10] J. M. Robarts, “Practical considerations for distributed projects,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 327-332.

[11] M. Summers, “Insights into an Agile adventure with offshore partners,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 333-338.

[12] J. Sutherland, G. Schoonheim, E. Rustenberg, M. Rijk., “Fully distributed Scrum: The secret sauce for hyperproductive offshored development teams,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp.339-344.

[13] E. Therrien, “Overcoming the challenges of building a distributes Agile organization,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 368-372.

[14] E. Uy and N. Loannou, “Growing and sustaining an offshore Scrum engagement,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, 4-8 August 2008, pp. 345-350.

57

[15] D. Wahyudin, M. Heindl, B. Eckhard, A. Schatten, S. Biffl, “In-time role-specific notification as formal means to balance Agile practice in global software development Settings,” in Proc. CEE-SET 2007, Springer, 2007, pp. 197-211.

[16] W. Williams and M. Stout, “Colossal, scattered, and chaotic (planning with a large distributed team),” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 356-361.

[17] C. Young and H. Terashima, “How did we adapt Agile processes to our distributed development?” in Proc. AGILE 2008 Conference,

IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 304-309.

[18] M. Vax and S. Michaud, “Distributed Agile: growing a practice together,” in Proc. AGILE 2008 Conference, IEEE Computer Society, Toronto, Canada, 4-8 August 2008, pp. 310-314.

[19] P. J Ågerfalk, “Towards better understanding of Agile values in global software development,” in Proc. Eleventh International Workshop on Exploring Modeling Methods in Systems Analysis and Design (EMMSAD'06), CEUR Workshop Proceedings, Luxembourg, 5-6 June 2006, pp. 13-20.

58