The Proposed GSD Model to Solve Coordination and Communication Problems

Published Online November 2014 in MECS DOI: 10.5815/ijmecs.2014.11.03

This study focuses on the distinctive feature of Scrum that can be used to mitigate the coordination costs in GSD projects due to temporal distance.

The paper is structured as follows. Section 2 presents related work on Scrum practices in GSD projects. Section 3 describes the problem and proposed solution. Validation of the proposed solution is covered in section 4.

• II.    Related Work

There are many articles present on how Scrum methodology is implemented in GSD environment. The experience of a global company that implemented Scrum in its two projects is mentioned in [3]. It maintained its centers in Americas and Asia. Both projects experienced challenges when Scrum was implemented. One of the challenges was in communication as the teams did not attend remote Scrum meetings and that affected collaboration between them. A bigger challenge was in changing the culture of the company from waterfall to Scrum because there was some resistance by people within the company.

The biggest challenge for implementing Scrum in GSD environment is lack of synchronous communication as reported in [6]. This paper also defined the challenging factors of using Scrum practices in GSD projects and strategies to reduce these factors. While the authors of [1] suggest a framework of research which shows how practices of Scrum can mitigate challenges in GSD. It also defines three categories of challenges in GSD that are control, communication and coordination according to socio-cultural, geographical and temporal distance. However, this framework needs to validate empirically because it is a theoretical proposition.

An empirical study to implement Scrum practices in GSD projects is reported in [2]. This study was conducted to show the distinctive benefits of applying Scrum method in GSD projects over the traditional methods to mitigate GSD coordination challenges. The result was that Scrum method offered a distinctive feature to mitigate the effects of socio-cultural and geographical, but not temporal distance on coordination in GSD projects. There is a new method for GSD like scrum UP is mentioned in [7]. It integrated the advantages of Rational Unified Process (RUP) that is used for developing software and Scrum that is performed for managing a project.

Table 1. Comparison of Related Work

Paper Title	Limitations
Usage of SCRUM Practices within a Global Company [3].	Both the distributed projects faced communication challenges while using Scrum.
Using Scrum in Global Software Development: [6].	Papers that are used in this study do not have detailed information about the challenges and strategies that deal with challenges of GDS projects that implement Scrum practices.
Scrum Practices in Global Software Development [1].	The framework needed to validate empirically because it is a theoretical proposition.
Scrum Practice Mitigation of Global Software Development Coordination Challenges: A Distinctive Advantage? [2].	This study focused only on four out of twelve GSD challenges and also on practices of Scrum instead of focusing on the mechanisms and tools that help in mitigating challenges. It shows that Scrum method offers a distinctive feature to mitigate the effects of socio-cultural and geographical, but not temporal distance on coordination in GSD projects.
Scrum-based Methodology for Distributed Software Development [7].	The result of applying scRumUP methodology is not mentioned because the paper was written at the same time the company implemented the first project that used scRumUP.
Scaling   Scrum  in   a  Large Distributed Project [8].	There were challenges in implementing and scaling Scrum in this paper like communication and collaboration were not working properly between team and area product owner. This study also focused on one project and the interviews were in two out of four sites. Most of the interviews were in the main site for restrictions in time and travelling.
On the Difficulties for Students to Adhere to Scrum on Global Software Development Projects: Preliminary Results [9].	There were difficulties faced by developers when using Scrum but they learned many methods to develop software. The source of these difficulties did not come from Scrum but from the tools implemented in the project and the distribution of teams across three countries.
Teaching a Globally Distributed Project  Course  Using  Scrum Practices [4].	The team faced some challenges at the beginning of the project. These challenges were cultural differences, time-zone differences, technical difficulties and the differences in semesters and courses between two universities.
Transitioning to Distributed Development in Students’ Global Software Development Projects [5].	There were some problems when Agile and Scrum were applied in this project such as: the developers did not work as one team but as three smaller teams.
Inter-team coordination in large-scale globally distributed scrum [10].	The results of this paper are limited as it depends on two projects only and it selected interview method for collecting data. There were challenges with coordination in both projects when applied SoS meetings.

There are various papers that present case studies about how Scrum is used in GSD context. Some of these studies faced challenges of using Scrum in GSD projects. In [8], there is a case study for a company that implemented and scaled Scrum in its distributed project. There were challenges in implementing and scaling Scrum in this project like communication and collaboration were not working properly between team and area product owner. In spite of the existing challenges, Scrum was implemented successfully and it increased the number of customers. While [9] shows a case study for the 2011 version of the GSD project that is run annually. It used Scrum for developing mobile application and also implemented the IBM Rational Team Concert tool. Scrum helped the developers for finding better ways to implement user requirements. There were difficulties faced by developers when using Scrum. The source of these difficulties did not come from Scrum, but from the tools implemented in the project and the distribution of teams across three countries.

Another team faced some challenges at the beginning of teaching course about GSD in collaboration between Victoria University in Canada and Aalto University in

Finland. These challenges were cultural differences, timezone differences, technical difficulties and the differences in semesters and courses between two universities as reported in [4]. In [5], there is a case study of a team that developed a Target First Grade project that was a mobile application for children learning mathematics, reading geography and writing. This project took nine weeks to develop. It implemented Scrum and used IBM Rational Team Concert environment as tooling.

There were some problems when Scrum was applied in this project such as: the developers did not work as one team but as three small teams. The experience of applying Scrum-of-Scrum meeting (SoS) is mentioned in [10]. It was used for inter-team coordination in two large distributed projects from two companies. SoS did not work effectively in the first project, while a new meeting called Feature SoS was added to the second project and it was very useful. The second project also implemented Grande SoS that is wide SoS meeting, but it caused problems for the teams. So, there were challenges with coordination in both projects when SoS meetings were applied. The limitations of each paper are illustrated in Table 1.

• III.    Problem Statement and The Proposed Solution

Although the literature indicates that the Scrum method is not offering a distinctive feature to mitigate the effect of temporal distance challenge that includes "increased coordination costs" in GSD projects. This research proposed solution by considering some factors such as reducing the time of communication between distributed

Scrum teams’ as much as possible and using technologies. So, the Scrum method can offer a minor distinctive feature to mitigate the effect of temporal distance challenge.

Based on the difference in time zones between sites in GSD, the time of communication between distributed Scrum teams can be reduced by dividing the Scrum meetings into local meeting and global meeting. Local

Fig. 1. The proposed GSD Model

Fig. 2. The technical details of interaction with virtual teams

meeting should be held in each site, while global meeting should be held between sites. This division will minimize hours of Scrum meetings and the number of persons in each meeting. In addition, this paper suggests developing a web application to improve communication between distributed sites.

Fig. 1 presents proposed GSD model to implement Scrum. Fig. 2 shows the technical details of interaction with virtual teams. It is designed for a company with distributed sites (main site onshore and distributed site offshore). Main site (site A) has three persons (product owner/project manager, test engineer and architect as minimum) and server that is connected to database. In each offshore site, there is one Scrum master and Scrum team. The onshore team is responsible for maintaining the product backlog, creating the specification for the sprint backlog at offshore sites and verifying completed software before delivery to customers. The offshore team members are involved as single Scrum team in the development. For example, if project members work with each other in large time difference zones between these sites, there will be increased coordination costs between sites. The proposed structure presents a distinctive feature of Scrum to reduce the coordination cost by applying the proposed solution. The length of Sprint is two weeks in this structure. After applying this structure, the duration of Scrum meetings is reduced.

At the beginning of Sprint, the Sprint Planning meeting is divided into three meetings: Sprint pre-planning meeting, global sprint planning meeting and local sprint planning meeting. Sprint pre-planning meeting is held online between onshore and offshore sites to provide the details of tasks that are required in the next sprint from onshore site to offshore sites. The product owner/project manager, Scrum Master in site B and Scrum master in site C who attend this meeting which takes one and a half hours instead of two hours by synchronizing hours between them and using web application for communication. Then Scrum Masters conduct an online global sprint planning meeting which takes two hours via web application to divide tasks between offshore sites. Finally, each Scrum Master holds face to face local sprint planning meeting which takes an hour with his team to assign tasks to them. So the time of sprint planning at offshore sites is three hours instead of four hours.

• IV.    Validation Of The Proposed Solution

Validation of the proposed solution is done by using an electronic questionnaire. The electronic questionnaire composes of 20 close ended questions divided into 3 goals. Questions were arranged according to their relevancy to defined goals. This questionnaire is distributed via social sites such as Twitter, Facebook and email. Once data is collected, a statistical analysis is applied on it. The analytic form is represented by using frequency tables and bar charts. The next section shows the results of questionnaire and statistical analysis. This section shows the results of statistical analysis for each goal.

• A.    Cumulative Statistical Analysis of Goal 1

Goal 1: The potential benefits arising from the global software development and the trend in recent times to use them. This goal cover questions regarding the level of lower costs resulting from GSD and potential access to a larger and better-skilled developer pool. As it is cleared from the cumulative descriptive analysis of goal 1 that As it is clear from the cumulative descriptive analysis of goal 1 that 2.8% of respondents are strongly disagreed, 4.4% are disagreed, 13.8% are neither agree nor disagree, 35.6% of the them are highly agreed and 43.4% of them are very highly agreed. The result of the analysis of the goal 1 is shown in Table 2 and fig. 3.

• B.    Cumulative Statistical Analysis of Goal 2

Goal 2: Problems and challenges in the global software addressed by the proposed methodology. This goal covers questions that are related to differences and cultural dimensions, and geographical that affects coordination of resources and communication process and devises requirements. As it is cleared from the cumulative descriptive analysis of goal 2 that 2.14% of respondents are strongly disagreed, 5.14% are disagreed, 17% are neither agreed nor disagreed. 36.80% of the respondents are highly agreed and 38.80% are very highly agreed. The result of the analysis of the goal 2 is shown in Table 3 and fig. 4.

Table 2. Cumulative Statistical Analysis of goal 1

Q. No.	Very low	Low	Nominal	High	Very high
1	0%	3%	11%	43%	43%
2	6%	11%	15%	22%	46%
3	4%	2%	9%	31%	54%
4	1%	6%	15%	52%	26%
5	3%	0%	19%	30%	48%
Total	14%	22%	69%	178%	217%
Average	2.80%	4.40%	13.80%	35.60%	43.40%

Fig. 3. Cumulative Analysis of Goal 1

Table 3. Cumulative Statistical Analysis of goal 2

Q. No.	Very low	Low	Nominal	High	Very high
6	6%	6%	9%	29%	50%
7	1%	4%	15%	37%	43%
8	5%	6%	19%	37%	33%
9	0%	6%	20%	33%	41%
10	2%	4%	22%	39%	33%
11	1%	6%	19%	33%	41%
12	0%	4%	15%	50%	31%
Total	15%	36%	119%	258%	272%
Average	2.14%	5.14%	17%	36.80%	38.80%

Fig. 4. Cumulative Analysis of Goal 2

• C.    Cumulative Statistical Analysis of Goal 3

Goal 3: User satisfaction for the proposed methodology. This goal covers questions that are related to the proposed scenario is able to reduce the challenges facing the globally distributed software. As it is cleared from the cumulative descriptive analysis of goal 3 that 2.37% of respondents are strongly disagreed, 5% are disagreed, 12.37% are neither agreed nor disagreed, 34.12% are highly agreed and 46.25% are very highly agreed. The result of the analysis of the goal 3 is shown in Table 4 and fig. 5.

Table 4. Cumulative Statistical Analysis of goal 3

Q. No.	Very low	Low	Nominal	High	Very high
13	2%	7%	15%	22%	54%
14	0%	4%	9%	39%	48%
15	4%	0%	7%	39%	50%
16	3%	2%	19%	28%	48%
17	2%	7%	6%	44%	41%
18	2%	4%	19%	30%	46%
19	4%	7%	13%	30%	46%
20	2%	9%	11%	41%	37%
Total	19%	40%	99%	273%	370%
Average	2.37%	5%	12.37%	34.12%	46.25%

Fig. 5. Cumulative Analysis of Goal 3

Table 5. Final Evaluation of all goals

Q. No.	Very low	Low	Nominal	High	Very high
1	0%	3%	11%	43%	43%
2	6%	11%	15%	22%	46%
3	4%	2%	9%	31%	54%
4	1%	6%	15%	52%	26%
5	3%	0%	19%	30%	48%
6	6%	6%	9%	29%	50%
7	1%	4%	15%	37%	43%
8	5%	6%	19%	37%	33%
9	0%	6%	20%	33%	41%
10	2%	4%	22%	39%	33%
11	1%	6%	19%	33%	41%
12	0%	4%	15%	50%	31%
13	2%	7%	15%	22%	54%
14	0%	4%	9%	39%	48%
15	4%	0%	7%	39%	50%
16	3%	2%	19%	28%	48%
17	2%	7%	6%	44%	41%
18	2%	4%	19%	30%	46%
19	4%	7%	13%	30%	46%
20	2%	9%	11%	41%	37%
total	48%	98%	287%	709%	859%
average	2.40%	4.90%	14.35%	35.45%	35.45%

• D.    Cumulative Statistical Analysis of 3 Goals

0.00%

The evaluation of 3 goals together showing that 2.40% are in favor of very low, 4.90% are supporting low, 14.35% are neither agreed nor disagreed, 35.45% are highly agreed and 35.45% are very highly agreed. The result of the analysis of the 3 goal is shown in Table 5 and fig. 6.

40 ОО%

Fig. 6. Final Evaluation of all Goals

• V.    Conclusion

Global Software development approach has become a reality with the increasing growth of the software. Wherefore, this approach needs further attention due to the imbalance in the understanding of the requirements that occur due to the factors of cultural diversity, time zone difference, inadequate communication and improper knowledge management and so on. In order to overcome these problems, we have proposed an approach that focuses on the key challenges and proposed a set of Strategies used with each case. Taking into consideration the cognitive behavior of stakeholders in order to identify technology that is best for them .The result of the validation showed that the suitability of the proposed approach to mitigate the obstacles in the GSD environment. In the future, we seek to verify our approach by applying it on a sample of more than one team.