A proposal to ensure Distributed Software Development with Scrum practices

Vctor Leonel Orozco L pez1 , Lisandra Manzoni Fontoura1 o

1

Centro de Tecnologia Universidade Federal de Santa Maria (UFSM) Av. Roraima 1000 97.105-900 Santa Maria RS Brasil
vlopez@inf.ufsm.br, lisandra@inf.ufsm.br

Abstract. Distributed Software Development (also known as DSD) and agile methodologies are two disciplines with great presence in the Software Development environment. Although both tendencies have successful examples, if these tendencies are analyzed in a supercial way, could be afrmed that they present gaps to be lled in order to work together. One of these gaps is the communication process that could present security issues if is not discussed and established properly. In order to ll that gap, this work presents a proposal to increase the security of Distributed Software Development practices when Scrum methodologies are used, covering technical and team members areas and minimizing over Scrum agile practices.

1. Introduction
Distributed Software development and agile methodologies are two disciplines with great presence at the actual Software Development environment. In recent years Distributed Software Development has increased signicantly, and actually exists many initiatives to institutionalize Distributed Software Development practices between teams over the world and these efforts are being originated even in big size companies [Union 2005]. That fact talks itself about the importance attracted by Distributed Software Development. Despite the economic advantages, one of the main concerns when the development is distributed between remote teams is the management of intellectual property[Union 2005], because the teams is note controlled anymore just at one organization, creating a need for better information sharing practices with special focus on security. On the contrary side, agile methodologies like Scrum have strong emphases in practices with a more informal approach, and these practices are resting upon three main pillars: transparency, inspection and adaptation [Sutherland 2011]. To achieve that adaptation Scrum gives priority to rapid information dissemination with daily project short meetings in a more informal discussion to get better feedback for the stakeholders in less time and to obtain constantly the status of the development process. Other authors like [Boehm 2002] have pointed that many Software developers considers than agile methodologies plan-driven software development methods (like DSD traditional practices) are polar opposites, and as a consequence is possible to afrm that the more informal practices of Scrum have will contrast with the more formal practices on Distributed Software Development. In that sense [Xu et al. 2006] presented in their work a list of key differences between Distributed Software Development and agile methodologies. In their work they try

to establish how these difference could impact the implementation of agile methodologies in Distributed Software Development environment. This facts are presented side-by-side at Table 1.
Table 1. Distributed development versus agile methodologies

Distributed development Agile methodologies Supported by formal mechanisms Supported by a more informal process Done with formal and detailed architectures Based on agile and informal interaction Based on xed quality requirements Evolving quality requirements Development controlled by process Development controlled by people Explicit targets and milestones Informal agreements to achieve goals Lack of team cohesion Full and near cooperation between teammates From the Table 1 is possible to visualize that many of the differences between Distributed Software Development and agile methodologies are related with how the information is exchanged between stakeholders. And as in most of the IT areas, that exchange is subject to present security problems. Based on these facts is right to afrm that exist a need of security practices for information exchange when the intellectual property of software projects needs to be protected. Although Distributed Software Development with Scrum practices -the combination of two worlds- is in its early stages of research, this work presents a proposal based on the ideas of [Sherwood 1997], [Layman et al. 2006] and [Azham et al. 2011], in order to increase the security in Distributed Software Development with support for Scrum practices. The rest of the work is organized on the following way, at section 2 is presented a discussion about which topics are important to ensure Scrum distributed development, at the section 3 is described a proposal to avoid security issues for the Scrum team members, later at the section 4 is described a security proposal for the communication channels that support the Scrum distributed teams, nally at the section 5 are presented the conclusions of this work.

2. Security issues in Scrum distributed development

One of the rst steps that needs to be done before ensuring a process is to dene which areas of that process needs to be ensured in order to get a safe state. [Jim nez et al. 2009] e afrm that the distributed development process is a novel area, and as a consequence it has many opportunities to research. In their work is presented a well structured description of important research areas in Distributed Software Development context, the summary of the areas is presented bellow: Communication Group Awareness Software Conguration Management Knowledge Management Coordination and Collaboration Project Management Process Support

To achieve a safe state for Distributed Software Development process these areas could be used as a guide to dene which topics of the process needs to be ensured, the proposed topics are: Communications security Safe group awareness Trustiness in software conguration management Secure practices for knowledge sharing Reliability in project coordination Secure tools for distributed development communication

To generate a more integrated proposal, the topics above were divided in two areas, one area focused on the topics related to security of information exchange between team members (reliability in project coordination, secure practices for knowledge sharing and safe group awareness) and the security topics related to the technology used by that team members(communications security, trustiness in software conguration management and secure tools for process support). The security proposals are described in the next sections following this division.

3. Avoiding security issues for distributed Scrum team members

[Sherwood 1997] presents in his work a proposal of how the security should be managed at the outsourcing environment, his proposal is principally motivated by the need of guarantee the information exchange security between on-site teams and outsourced teams, dening a framework to administrate the responsibilities and liabilities using verication teams for the outsourcing provider and also for the outsourcing customer. He divides the responsibilities between both parts. For [Sherwood 1997] the security risks analysis (risk denition) is a responsibility of the customer and the intrinsic security management (risk strategy) is a responsibility of the provider. The main idea behind the proposal of [Sherwood 1997] is the creation of verication teams on both sides (customer and provider). To achieve that, he describes clear roles for the teams that have equivalents in both sides of the outsourcing process, these roles are: security manager, security co-coordinators, security audit department, security corporate department and security forum. 3.1. Security manager The security manager is the owner of the security process, his main objective is to ensure that the security guidelines are in line with the security goals and verify the achievement of that goals of the project. He constitutes the connection point between the customer and the provider in both sides. 3.2. Security co-coordinators The security co-coordinators are the specialists in their area, they are in direct contact with the security manager to improve his vision of the security at the project and they must take concrete actions to avoid security issues.

3.3. Security corporate department This staff acts like advisor of the right way to generate valid security policies, standards and architectures, and also to give technical assistant for the process Although the ideas of [Sherwood 1997] have a clear focus on companies with enough capacity to create middle-sized teams to dene, monitor and control the security between two teams in different places (the internal team and the outsourced team), the roles presented in his work have clear responsibilities and clear objectives to ensure the exchange of information between teams in different locations, covering key security items. Based on those ideas, our proposal is to use these concepts matching their responsibilities to existent roles in Scrum, as described at Table 2.
Table 2. Outsourcing roles matched with Scrum

Outsourcing Security manager Audit department (Auditory tasks) Product owner Co-coordinator of client requirements Software developers Co-coordinators of technical area Security department This role matching is proposed because some of the responsibilities described by [Sherwood 1997] are actually covered by Scrum team members and in order to ensure these tasks is only needed make them security aware. As an option this tasks could be guided by a new tool in the same way that sprint backlog and product backlog guide the Scrum practices. We propose te creation of a tool called information exchange backlog. As [Azham et al. 2011] previously demonstrated the addition of a Sprint Security Backlog conforms a good tool for the Scrum Master and helps him to verify if a software product is being constructed properly secured, without affecting the agility of Scrum. The principles where [Azham et al. 2011] based their work are: Principle of least privilege: Only the minimum necessary rights should be assigned Principle of failing securely: When a system fails, it should do securely Principle of securing the weakest link: Attackers are more likely to attack a weak spot in a software system Principle of defense in depth: Layering the security must reduce the successful attacks. Principle of separation of privilege: A system should ensure that multiple conditions are met before it grants permissions to an object. Principle of economy mechanism: Keep design simple and remove unnecessary data Principle of least common mechanism: Avoid having multiple subjects that grant access to a resource

Scrum Scrum master

 Principle of complete mediation: A software system that requires access, checks to an object each time a subject request access The idea behind the Sprint Security Backlog is simple, after analyzing the software requirements presented by the product owner in the product backlog is done an additional step evaluating if that requirements could generate security issues based on the principles of security. If they could present issues, these issues are considered for the sprint backlog (the goals backlog) to avoid them using software constructions techniques like double source code verications or automatized tests for the security features. For our proposal the Information Exchange Backlog must work in the same way. The idea is implement the controls after the sprint backlog denition but before of the goals distribution process between the teams. This control must be done in order to verify if the information to be distributed and the way of distribution are compliant with the security principles where [Sherwood 1997] based his work. So with this, the reliability in project coordination is veried constantly with the use of secure practices for knowledge sharing ensuring the group awareness vision by sharing only the information that needs to be shared avoiding security problems.

4. Avoiding security issues for the communication channels that support distributed Scrum process
Once the interaction between members is ensured, the communications channels also need to be ensured in order to give less chances to security problems. Now the question is: how and which communications channels and tools ensure?. For that question our proposal is based on [Layman et al. 2006] work. In their work they present essential communication practices for Extreme Programming methodology that is also an agile methodology, our idea is to dene based on that practices which technologies are common in agile environments and later propose secure solutions for that technologies. According to [Layman et al. 2006] the most common problems in communication with XP and distributed development environments are: The face to face communication is common in agile methodologies and most of its adaptability is based on meetings, but that communication is not present in distributed environments. The cultural gaps between teams represents an important barrier, because misunderstood requirements could derivate in product out of the required functionality and scope. Although the face to face information could not be achieved globally, it exists in local members and this could generate team to team information gaps. This problem is specially important in order to get good information from the customer. A direct real-time communication is not always possible, because if the teams are distributed globally the opportunities of communication are limited to the hours where the teams are active at the same time. To overpass that problems [Layman et al. 2006] proposed four success factors for globally-distributed XP projects: customer authority, team cohesion levels, face-to-face asynchronous replacement and high process visibility.

4.1. Identify and give for the customer the authority to resolve issues The authority for the customer is their participation in the denitions at the software development process, so to increase customer authority [Layman et al. 2006] proposed an increment on the customer participation into the entire development process, introducing it directly into XP process, in our case is not necessary because in Scrum the client has a good representation with the product owner role. 4.2. Improve the cohesion between teams with one or more bridgeheads, leaders tightly aware of all remote teams In order to increase team cohesion, is necessary to create an special role called bridgehead that has to be aware of the actual state of the project on all teams and provides that information and details of the teams when is required. 4.3. Asynchronous communications loops as sufcient surrogates for face-to-face sync In the case of study explored by [Layman et al. 2006] were explored four ways of communication between team members, instant messenger, VoIP calls, emails and mailing list. Although the instant messenger and VoIP calls could be considered as the modernest communications channels they also presented two limitations: the lack of propagation of the information generated at the discussions and the limitation imposed by the hourly zones of the teams. In that sense e-mail presented a higher preference, motivated by its natural asynchrony and because the information propagation is easily achieved by using mailing lists with well dened groups. 4.4. Create high process visibility to guide the project effectively For this topic the suggestion was to use a some kind of software conguration management tool to achieve visibility for all the members of the process. At this stage we got enough concepts to give suggestions about with communications channels need to be ensured, our proposal is described following: 4.5. Ensuring customer participation channel In Scrum the customer participation often is considered as mandatory, so to give to him a good view of the process the software conguration management needs to implement access to only the sections that are interesting for a role. To do that the decision over the SCM tool should be done evaluating its user and roles management. Also as an additional warning, the participation between customer and product owner needs to be specied with the support of legal contracts and non-disclosure agreements in order to give guarantees that the information will be treated with caution. 4.6. Ensuring bridgeheads channel The bridgeheads roles could be achieved by Scrum Masters, and automatically are under the scope of our proposal with the practices described at the previous section, so we can point again that the concerning the right SCM tool should be done, evaluating its support for roles and users.

4.7. Ensure asynchronous communication channel As described previously the most effective channels for asynchronous communications where email and mailing list. To ensure that channels an integral politic of use needs to be created, with the objective to force the participation of the stake holders over secure channels like encrypted email communications and mailing list with access and role policies, so in that way the channel will not be compromised. 4.8. Ensure high process visibility Finally as early mentioned the SCM tool will play a crucial role as a support communication channel, mostly motivated by the lack of traditional and physical Scrum supporter tools (white-boards, wall burn-downs graphics). Also in addition of the SCM, the continuous integration tools -part of an standard SCM environment in agile teams- need to be selected with the same security considerations, using ensured version control systems over secure channels, and continuous integration builders with authentication and roles management support.

5. Conclusions
Although the distributed development area is still an on going research area with many opportunities, we were able to present a proposal to ensure Distributed Software Development with Scrum methodology. The suggestions of this work were done following a simple technique, rstly dening what topics need to be ensured because of the adaptation of Scrum to Distributed Software Development environment and later proposing solutions for every one of these topics. At the work the considerations were dened in two areas, the team mates interaction area and the communications channel area, because of the problem with team mates is more related with people interaction process and on the contrary the communication channel problem is more a pure technical problem, that enabled us to give a more consistent proposal. Many of the proposals presented here are well tested solutions in their own context and environments, so this proposal is a start point to future works that could try to test its effectiveness when all are present in the same project, but is important to point that the Scrum process itself is not guided by rigid plans so the proposals could be adapted for the project characteristics.

References
Azham, Z., Ghani, I., and Ithnin, N. (2011). Security backlog in Scrum security practices. 2011 Malaysian Conference in Software Engineering, pages 414417. Boehm, B. (2002). Get ready for agile methods, with care. Jim nez, M., Piattini, M., and Vizcano, A. (2009). Challenges and Improvements in e Distributed Software Development: A Systematic Review. Advances in Software Engineering, pages 114.

Layman, L., Williams, L., Damian, D., and Bures, H. (2006). Essential communication practices for Extreme Programming in a global software development team. Information and Software Technology, 48(9):781794. Sherwood, J. (1997). Managing security for outsourcing contracts. Computers & Security, 16(6):523. Sutherland, J. (2011). The Scrum Guide. Framework, 2(July):17. Union, W. (2005). Source out, risk in. (April). Xu, P., Cao, L. A. N., and Mohan, K. (2006). Can distributed software development be agile? 49(10):4146.