English (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. Introduction
Agile approaches such as the Dynamic Systems Development Method, the family of Agile Crystal methods, eXtreme Programming (XP), Adaptive Software Development and Scrum (hereinafter agile approaches), are a set of processes and techniques used for software development, which appear in response to traditional methodologies, such as RUP (Rational Unified Process), characterized by excessive documentation that hinders the development process. However, agile approaches have been originally conceived to be implemented in set teams, generating some concerns about the loss of advantages of these approaches, when used in the Global Software Development (GSD). Due to this, in the last years, a series of solutions have arisen that start from the proposed agile approaches, (especially Scrum) that try to lessen the GSD’s own challenges such as communication, coordination and cooperation problems.
Among the main techniques found in the literature we have: Scrum of Scrums [1], Scrumconix [2], LeSS [3], Nexus [4] and SAFe [5], which offer mitigation strategies for the challenges of the GSD [6], since the activities of these agile approaches allow fulfilling the emerging needs in the organizations that apply this type of development.
However, the solutions created do not consider the problems generated in the management of GSD projects when multiple models, standards and approaches (hereinafter reference models) are used to support the management of a GSD project. Additionally, it must be taken into account that the reference models in a GSD context have not been widely developed, and therefore, the efforts to improve processes specifically in a global approach, have had limited success [7].
On the other hand, in the literature it is possible to identify some proposals and solutions that allow supporting the harmonization between the structural and terminological differences using multiple reference models, also known as definition of hybrid models. From these proposals, it was observed that their main effort focuses on obtaining an integrated model that adopts characteristics of different/multiple methodologies, this, from the homogenization of their differences, comparison and integration of best practices, to be later implemented and institutionalized in an organization through a single Software Process Improvement (SPI) [8]. However, until now in none of the found studies, there is evidence of the efforts made about its application in the definition of hybrid models, that allow supporting global software development environments.
Given the situation outlined above, this article presents an agile guide that ease the implementation of practices related to project management in global software development environments, when multiple reference models are present. The defined guide describes different activities, roles and criteria, which should be considered in a GSD project. The Scrum+ guide has been designed to lessen some of the challenges present in the GSD, by adapting proposed solutions and the Scrum harmonization, with other certifiable reference models such as CMMI-DEV, ISO 9001 and ISO/IEC 15504, to provide support to multi-model environments that a global software development project may face. This guide is part of the research efforts that have been conducted in the research groups involved and which aim at defining better agile practices that allow addressing the challenges and needs of current software development companies. This paper is an extension of the conference paper presented in [9], unlike the paper presented previously, here we present in detail the harmonization of multiple models carried out and the correspondence among Scrum and ISO/IEC 15504, ISO 9001 and CMMI-DEV to design the proposal. Likewise, some examples of some flow diagrams are presented.
Apart from this introduction, the article is organized as follows: section 2 presents a summary of the related works. Section 3 presents the Scrum+ guide, and it describes the activities, tasks and roles proposed. Section 4 presents a summary of the evaluation of the guide carried out through the application of a focus group and an agility assessment. Finally, section 5 presents the discussion, lessons learned, conclusions and future work.
2. State of the art
Based on the results obtained from the literature review made and related to the management of global software development projects in multi-model environments, Table 1 shows some of the developed proposals, that allow the management of global software development projects or projects where multiple development teams are involved.
Considering the related works, it is possible to observe that although there are different proposals that try to lessen some of the challenges of the GSD, there are no studies or proposals that consider the possible multi-model scenarios that can be generated in this type of environments.
3. Research method
In order to develop this guide, it was used the Action Research method with multiple linear cycles and a focus group as a research method [10, 11]. Taking into account the phases and activities proposed by the Action Research methodology, three research cycles were carried out for the development of this proposal. The cycles and activities carried out sequentially and incrementally for the development of the guide are listed below.
Cycle 1. Conceptual analysis. Here the systematic review of the current state of the art was carried out, related to the agile project software management in distributed environments, in scenarios where multiple models intervene for its management. Also, during the development of this cycle, the different proposals, existing solutions and the sensitive elements to be considered for the definition of the solution were identified and studied.
Cycle 2. Defining and designing the agile guide. In this stage, the process of harmonization of the different models and standards for project management and the agile Scrum approach was defined. As an outcome of this cycle, the Agile Scrum+ guide is established based on the results obtained from the harmonization process.
Cycle 3. Evaluation of the proposal. The evaluation of the proposal was carried out through the use of the focus group research method, in which experts participated in different areas related to the proposal.
4. Harmonization of multiple models for the definition of the Scrum+
For the definition of Scrum+, it was out carried the harmonization of multiple models from the comparison and identification of the differences and similarities among the activities defined by the reference models: ISO/IEC 15504 [12], ISO 9001 [13] and CMMI-DEV [14], these reference models were compared 1 to 1 with the agile Scrum approach [15]. The comparison allowed knowing the degree of correspondence between the multiple models. The results of this process were considered to define the activities that allow Scrum+ to support the management of projects in multimodel environments. HFramework was used to carry out this process [8], which is a framework that allows supporting the harmonization of multiple models through a harmonization strategy consisting of three methods: homogenization, comparison and integration. Due to the limited space, this paper presents the results of the harmonization in a summarized way.
Table 2 shows an excerpt example of the comparison template used and the relationships with the specific goal (SG) 1: "Use the project defined process from the process area integrated project management (IPM)" of the CMMI-DEV model and the activities defined by Scrum.
Table 2 Excerpt example of the comparison template used between the specific goal (SG) 1 of CMMI and the Scrum practices. Own source
4.1 Correspondence among Scrum and ISO/IEC 15504, ISO 9001 and CMMI-DEV
As can be seen in Table 3, regarding the ISO/IEC 15504 standard, 57.1% (4) of the clauses have a HIGH level of correspondence in relation to the activities proposed by Scrum, while the remaining percentage 42.9% (3) of the clauses have levels of correspondence among MODERATE, LIGHT and NULL with 14.3%, corresponding to the clauses 3.3.1.4 Process of risk management, 3.3.1.6 Process of measurement and 3.2.1.5 Process of configuration management, respectively. The same occurs with the ISO 9001 standard, 4 of the compared clauses have a HIGH level of correspondence, the remaining percentage corresponds to the clauses 8.5 Production and supply of the service, 8.1 Operational planning and control and 8.4 Processes control, products and services provided externally. Regarding the CMMI-DEV, it can be seen that 42.9% (3) of the processing areas have a HIGH level of correspondence, while 28.6% (2) have a MODERATE level of correspondence with the agile Scrum approach. While the 14.3% represented by the process Quantitative Project Management area (QPM) retains a LIGHT level of correspondence, similarly 14.3% (1) of the CMMI-DEV process areas have no correspondence or relationship among the activities defined by Scrum. The process area that has a NULL correspondence with Scrum is the Supplier Agreement Management (SAM) area.
With the comparison of the models, it was possible to identify that out of 21 relationships that can exist between the clauses and process areas of the reference models and Scrum, 3 of them were classified with a NULL level of correspondence, that is 14.3% of the related processes elements have no correspondence, while 85.7% (18) are related in some degree to Scrum activities.
5. Scrum+: guide for the management of projects in organizations with global environments when multiple reference models are present
The purpose of Scrum+ is to guide organizations in project management in global environments when multiple reference models are present. This guide adapts Scrum and some of the methodologies that scale it like Nexus, LeSS and Scrum of Scrums; used in global development projects. Scrum+ defines its roles, activities and artifacts according to Scrum as an agile approach to project management. So, its components will be familiar to those who have knowledge in Scrum.
As a result of the harmonization process, a Scrum list of activities, which cover different areas of the aforementioned reference models was obtained. These activities were considered to define Scrum+.
5.1 Roles
Scrum+ scales some of the traditional Scrum roles and also defines new roles that facilitate the interaction between distributed teams and their members, see Table 4.
5.2 Scrum+ activities
Scrum+ is composed of seventeen (17) main activities, which are distributed in ten (10) phases described below:
Phase 1. Initiation
During this phase, the initial activities of a global software development project are carried out. In this phase, the vision of the project is created; the requirement for the distributed development is defined, where the distribution needs, according to the general vision of the project are detailed. The distributed development centers that fulfill the distribution needs through standards, geographic location, developers’ work capacity, services offered are decided, the Scrum+ team is conformed.
Phase 2. SprintZero+
This phase is done with the help of the Scrum+ team and the technical representatives who plan and define strategies that facilitate their coordination during the development of the project. In addition, the selection of the technical representative of each team to participate during the SprintZero+ meeting is made. The SprintZero+ meeting aims to coordinate the activities that the teams will develop during the project. Once the SprintZero+ meeting is over, the technical representatives return to their teams and socialize the decisions made.
Phase 3. Product backlog refinement
During this phase, the Product Backlog is reviewed to add, eliminate or re-estimate previously defined user stories. It is necessary that during this phase, the user stories are divided minimizing or eliminating any type of dependence among them. It is suggested to perform a risk assessment in each of the tasks or user stories of the Product Backlog, as from which actions will be taken on the existing dependences.
Phase 4. Planning and assessment
During this phase, the SprintPlaning+ meeting is held, where the PO+ socializes the client’s needs, performs the necessary orientations and prioritizes the user stories. During this meeting, the technical representatives based on their experience will determine the tasks that their team can develop during the Sprint. Once this meeting is over, Sprint planning is done within each team.
Phase 5. Implementation and integration
In this phase, the teams carry out the implementation of the functionalities of their respective Sprint Backlog, and if necessary, a meeting is held among the technical representatives of each team to socialize the current status of each team's work and the obstacles that their work can generate to other teams.
Phase 6. Sprint review
During this phase the increments are reviewed and it is decided if the ones made by each team are approved. In this phase, the Sprint review meeting is held, where each team presents their increment to their Product Owner. Once this meeting is over, the Sprint+ meeting is held, where the increments delivered by each of the teams are reviewed.
Phase 7. Integration+
During the development of this phase, the Scrum+ team is responsible for the integration of the increments delivered by the different teams. This integration is left in charge of the Scrum+ team to avoid coordination and communication problems when carrying out this task. Likewise, during this phase the Scrum+ team is responsible for integrating and sharing the different management artifacts generated by the different teams, this in order to keep track of the progress of each team and the project in general.
Phase 8. Release
During the release phase, the technical representatives along with their Scrum Master, deliver the integrated increment to the client and the PO+, who will give a feedback of the work done.
Phase 9. Sprint retrospective
During this phase, each team performs a self-analysis of their work in the Sprint and identifies their strengths and weaknesses at a team and project level, with the aim of planning improvement actions. Once the Sprint Retrospective meeting is over, the Sprint+ Retrospective is held, where the technical representatives share the results of the retrospective of each team. Based on these results, the Scrum Master+ proposes an improvement plan at a project level.
Phase 10. Change management
The needs of the interested parties are presented during the change management meeting, and the Product Owners are in charge of socializing these needs to each of their teams. Team members estimate the effort and cost of these changes and the Product Owner informs the interested parties of the associated costs. In case of being accepted by the client, the Product Backlog is re-prioritized considering the new needs presented. In spite of the flexibility and adaptation to the change offered by Scrum+ throughout the development of the project, it is suggested that the change management be carried out at the end of the Sprint to facilitate the coordination and control of the project and its members. In addition, Scrum+ compiles a series of recommendations for the management of the teams, the making of the events and the selection of support tools. Table 5 presents some of the mentioned recommendations.
Some examples of flowcharts defined in Scrum+ can be seen in Figure 1 and Figure 2. Figure 1 shows the flowchart for the activity related to the creation of the Product Backlog. Figure 2 shows the flowchart for the SprintZero+ meeting Scrum+ uses the notation business process modeling notation or BPMN and incorporates a special notation, the rectangles (activity / task) of green color represent distributed activities, a new icon is added in the form of clouds and roles, which represents the artifacts that should be shared among the distributed teams, the blue rectangles (activity / task) maintain the same original meaning of the notation and are used to represent the activities that are not done in a distributed manner. The complete and detailed version of the proposed guide can be found at: http://artemisa.unicauca.edu.co/~piedadchilito/
Figure 1 Example of the flow diagram related to the activity: Creation of the Product Backlog in Scrum+. Own source
6. Proposal evaluation
This section shows the evaluation process of the proposed Scrum+ guide, through a focus group applied to experts in the quality area, project management, agile approaches, IT governance and people who are part of the local software industry. Additionally, a formal agility evaluation of the proposal was made.
6.1 Focus group
In [11], the focus group is referred to as a quick and cost-effective empirical method for obtaining qualitative information and feedback from a specific group. The focus group is adequate to obtain information from the participants about research questions or new concepts. It also allows the initial evaluation of potential solutions based on the opinions of participants or potential users. It also allows compiling recommendations of learned lessons or generating new ideas. The evaluation of the proposal was carried out under the parameters established in [11]. According to [18], the number of members in a focus group can range from 3 to 12 participants, to have sufficient sustainability and carry out the objective evaluation of the proposal, we decided according to our experience, to make an adequate selection of the participants according to their experience in the subject addressed in the research (see section related to design of discussion groups).
6.2 Focus group objectives
To obtain feedback from participants on questions and concepts defined in Scrum+ as a guide that facilitates the management of global software development projects when multiple reference models intervene.
6.4 Design of discussion groups
For the selection of the focus group participants, the following criteria have been defined:
6.5 Analysis of results
Once the application of the focus group was finished, an analysis of the questionnaires completed by each of the participants (7 in total) and a classification of the contributions made during the discussion sessions was carried out. The following Table 6 presents the questions asked and the response count. The participants of the focus group answered according to the following scale based on their level of compliance: totally in agreement (TA), largely agree (LA), partially agree (PA), little agreement (LTA) and disagree (D).
Figure 3 graphically presents the results previously presented in Table 6. In general, it can be seen that the participants agreed with most of the aspects evaluated during the focus group session. However, in Figure 3, it is also possible to observe that there are some aspects such as those evaluated in the questions: P5, P7 and P8 that are not considered as favorable, therefore, improvement actions were considered. In the following section in Table 7 the improvement actions carried out are summarized.
7. Improvement actions
Based on the analysis of the results and the comments obtained in the discussion session, improvement actions were carried out on the guide, thus obtaining a final version, which is presented in this document. The following Table 7 shows the improvement actions carried out on the Scrum+ guide.
8. Analysis of the degree of agility of Scrum+
In order to determine if Scrum+ can be considered as an agile guide that supports the management of global software development projects, an additional evaluation was carried out using the analytical framework known as 4-DAT [19], which allows performing a qualitative and quantitative evaluation to determine the degree of agility of any existing or under construction approach, method or process through 4 dimensions: (i) Method Scope, (ii) Agility Characterization, (iii) Agile Value Characterization and (iv) Software Process Characterization. Due to the space limit, just an extract of the application of the 4-DAT framework and the findings obtained for dimension 2 are presented. Table 8 presents a set of characteristics to be evaluated in the dimension 2 proposed in 4-DAT and with which a methodology or proposal must be considered to be agile. The evaluation of the proposal was carried out by analyzing the phases defined in Scrum+, assigning the value of one (1) to the characteristics that are present in them and zero (0) if the characteristic is not present in the analyzed phase. The results of the evaluation of characteristics in the dimension 2 are presented in Table 9.
As a result of the evaluation, and after applying the 4 dimensions proposed in 4-DAT, and the relationship with the assessment of agility in dimension 2, an 82% degree of agility was obtained, which allows us to consider that the proposal has a favorable degree of agility for the management of global software development projects.
Because the final objective of evaluating the degree of agility of the proposal, is to determine if it can be considered as an agile guide for the management of DSD projects, it is important to highlight that there was a certain degree of subjectivity during the evaluation of agility through the 4-DAT framework, to reduce bias during the evaluation of the proposal, an effort has been made to reduce the degree of subjectivity through the application of two evaluations through focus groups, in which the participants were asked about some aspects of agility present in the proposal.
9. Conclusions
From the development of this work, it is possible to conclude that the global agile development has become a trend in recent years, making more and more proposals for this type of projects to appear. However, these proposals leave many open gaps and do not fully cover the needs of global software development projects, this is because the vast majority of proposals are designed for specific cases. For this reason, a new approach that meets the needs of any type of organization is necessary.
Although several proposals that scale agile aproaches have been designed, many of them do not consider that the development of a project can be carried out by different service providers, which can work with different models of reference for the development of your projects.
As future work, a new evaluation of this proposal is expected through one or more case studies to verify compliance with the objectives of the guide under a real environment. Similarly, it is expected to develop a web tool that allows managing global software development projects through Scrum+. On the other hand, some future works will be addressed, they are: (i) to develop a software tool that supports the proposal. So far, the guide is a theoretical support for the management of GSD projects under multi-model environments, in the future it is expected to develop a software tool based on the definition of the Scrum+ guide that complements the GSD project management process in environments multi-model. (ii) To define metrics for the management of GSD projects. According to the results obtained in the systematic review carried out, it was possible to determine that measurements and metrics are important elements for the successful development of GSD project management. Currently, the research group is working on the definition of metrics for the management of distributed software development projects, it is expected that the results of this research work can be adapted to the Scrum+ guide and thus complement the control of GSD projects under a multimode environment. (iii) To extend the definition of the proposal with other reference models. So far, the guide has been developed to support the project management practices of the ISO/IEC 15504, ISO 9001 and CMMMI-DEV reference models. However, it is expected that the guide does not limit itself to offer support to the management of projects in organizations that use one of these three models of reference, on the contrary, it is intended to update the guide, which allows the inclusion of other reference models highly used in the industry. (iv) Finally, we hope to use the lessons learned and the knowledge generated to determine which practices should be sensitive to be taken into account as a reference for an effective and successful adoption of practices related to global software development. With results obtained, it is expected to develop a solution that allows evaluating the degree of satisfaction of elements and/or fundamental practices in this type of contexts, this would allow the software companies to identify their strengths and weaknesses, and so, to be able to plan more objective way your process improvement projects.
