Scrumconix: Agile and documented method to AGSD Luis T. Portela Programa Educativo de Ingeniería en TI Universidad Tecnológica del Sur de Sonora Cd. Obregón, México Gilberto Borrego Facultad de Ciencias Universidad Autónoma de Baja California Ensenada, México Abstract—Many companies have adopted agile software development (ASD), mainly due to it can handle scarce requirements. However, some unsolved challenges exist in ASD, particularly in global software development (GSD) companies (known as AGSD). These challenges include ASD lax documentation contrasted by the methodological standardization required in GSD, due to its inherent distances. Lax documentation leads to documentation debt and architectural knowledge (AK) vaporization, which cause negative effects on the development process and on the product itself. In order to reduce these effects, we propose Scrumconix, a hybrid method that uses a lightweight approach to document in AGSD environments, which also aims to decrease the effect of linguistic and cultural distances. In addition, we present preliminary results of Scrumconix implementation in a Mexican AGSD company. Keywords— agile global software development; architectural knowledge vaporization; documentation debt; Scrum; ICONIX. I. INTRODUCTION Agile software development (ASD) have become a popular and effective way to deliver software in situations with scarce requirements [1]. Many companies, including those that apply global software development (GSD), have adopted ASD [2], since they have recognized its benefits (e.g. manage changing priorities, team productivity and project visibility [3]). However, unsolved challenges exist in ASD, particularly in GSD companies (named AGSD companies). One of the main challenges in AGSD relates to software documentation. On the one hand, methodological standardization is preferred in GSD, which involves comprehensive documentation [4]. This preference is driven by the inherent distances in GSD: linguistic, cultural, physical and temporal [5]. On the other hand, in ASD individuals’ interactions and working software are preferred over comprehensive documentation, processes and tools [6]. This reduces the formality and the quantity of documentation [7]. Further, ASD practices dominate GSD practices in an AGSD environment [8]. Thus, there is a lack of formal documentation in AGSD, which leads to architectural knowledge (AK) vaporization and documentation debt [9]. In ASD, documentation debt is solved with teammates' interaction, however in AGDS, the four distances hinder this solution. This lack of documentation causes defects in software evolution and maintenance, lack of visibility for project monitoring and technical solutions, and poorly understood requirements [10]. Furthermore, ASD developers omit documents due to sprint pressure [9], and because they consider documentation as a secondary and non-creative activity [11]. However, ASD developers recognize that documentation is important to understand and communicate about a software system [12]. In order to reduce AK vaporization and documentation debt in AGSD, we propose a hybrid method (called Scrumconix), which uses lightweight documentation, mainly based on diagrams, to decrease the effect of linguistic and cultural distances. Also, we present preliminary results of Scrumconix implementation in a Mexican AGSD company. II. SOFTWARE DEVELOPMENT METHOD DEFINITION Scrumconix uses the project managing framework of Scrum [13], and part of the software engineering guide of ICONIX [14]. It is basically composed of two parts: Sprint Zero and Sprint One to N, described below. The Scrum activities that are not described is because they are unchanged. A. Sprint Zero In this sprint the Scrum Team gets the overall project understanding, through the following phases. 1) Overall requirements gathering. The product owner gather overall project requirements supported with Graphic User Interface Storyboards (GUIs) (i.e. mockups, wireframes, etc.). Namely, while the product owner is gathering the client requirements, he could draw the corresponding GUIs, to better confirm the requirements understanding. 2) Domain and use case modeling. The product owner leads a two-hour meeting where, based on the product owner’s project knowledge and GUIs, the Scrum team develops the domain model. This model is an UML class diagram (without attributes and methods), that represents the real-world objects involved in the project. The domain model is refined throughout the project to reflect the current problem understanding. Then, in another session(s), the Scrum team develops the use cases diagram, supported by the domain model, GUIs and the product owner’s project knowledge. Subordinated use cases [15] are preferred since they are more useful in the estimation phase. 3) Reference software architecture. Based on the use cases diagram, domain model and product owner’s project knowledge about non-functional requirements, the Scrum team has the elements to propose a reference architecture (RA) [16] to the project. 4) Overall project estimation. Once the Scrum team knows the involved use cases and the project RA, the use case points technique could be applied for estimation. In this manner, a project’s end date could be obtained, as well as, project effort in terms of hour/person. 2016 IEEE 11th International Conference on Global Software Engineering 2329-6313/16 $31.00 © 2016 IEEE DOI 10.1109/ICGSE.2016.39 195