SCRUM: Application Experience in a Software Development PyME in the NEA.

Transcription

1 SCRUM: Application Experience in a Software Development PyME in NEA. Walter G. Barrios María V. Godoy Mirta G. Fernández Sonia I. Mariño Ferno M. Ferreira Facultad de Ciencias Económicas. Universidad Nacional del Nordeste. Av. Las Heras Resistencia. Chaco. César T. Zarrabeitia Facultad de Ciencias Económicas. Universidad Nacional del Nordeste. Av. Las Heras Resistencia. Chaco. ABSTRACT In order to manage projects efficiently, agile methodologies for software development tools that improve production processes have emerged. This paper discusses adaptation implementation of SCRUM methodology in a software development company of NEA (Norast Argentina) used under a strategic management approach, redesigned for its use in a microenterprise. challenge was to achieve an effective technological linkage (between management systems) oriented to innovation in simplifying streamlining roles in implementing methodology. In paper, we introduce subject oretically n expose practical aspects of case analyze results. Keywords: SCRUM, Software Engineering, Case Study in NEA, University-Business, Interdisciplinary Work. 1. INTRODUCTION Scrum Software engineering [12] includes every aspect of software production, from initial stages of system specification up to maintenance after software has been used. Within this area methodology [8], allows to determine tasks to execute in order to improve effort gained by human resources team involved. term SCRUM refers to a strategy. It was originally coined in rugby, it is understood as to put back into game a lost ball, in which whole team cooperates decides quickly next step. Scrum is an iterative, incremental [14] framework for projects product or application development. It structures development in cycles of work called Sprints. se iterations are no more than one month each, take place one after or without pause. As agile methodology specifically referred to IS, in 1993, Jeff Surl [14] applied model SCRUM to development of software in Easel Corporation (Enterprise that in macro games of buying merging would end up uniting in VMARK, n in Informix finally in Ascential Software Corporation). In 1996 Surl presented, toger with Ken Schwaber, practices put into use as a formal process to manage software development in OOPSLA 96 [11]. experiments designed by Schwaber y Surl to manage software development are included in agile models list of Agile Alliance [10]. In [13] some implementations of SCRUM are mentioned. Takeuchi y Nonaka [15] observed for first time diverse variants of approach of such a methodology for development of new products with small high performance equipments in enterprises like Fuji-Xerox, Canon, Honda, NEC, Epson, Bror, 3M, Xerox Hewlett-Packard. Coplien [3] indicated a similar approach applied to software development in Borl. Besides Surl [13] used a refined approach of this process to development in Smalltalk Schwaber [11] to production in Delphi. SCRUM is nowadays, used by big small companies, including Yahoo, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco, GE, CapitalOne USA Federal Reserve [4]. Its basis is team work motivation an agile reaction to change oriented to final result. Those projects which requirements change rapidly are presented as most appropriate ones for its application. Its main characteristics may be summarized in [1]: Software development is carried out through iterations, named Sprints, which last for 30 days. result of each one of se is a feasible increase that is shown to client. Meetings all along Project; it is noteworthy that development team meets daily briefly, only for 15 minutes, for coordination integration. practices applied by SCRUM to maintain an agile control in project are: i) revision of iterations, ii) incremental development, iii) evolutionary development, iv) team self-organization v) collaboration. key roles, artifacts main events are summarized in Figure

2 Sprint Assessment: At Sprint review meeting, Team presents what was developed during Sprint to Product Owner any or stakeholderss who want to attend. After t Sprint review prior to t next Sprint planning meeting, m ScrumMaster also holds a Sprint retrospective meeting inn order to encourage Team to revise, within w Scrum process framework, its development process to makee it more effective enjoyable for next n Sprint. Figure 1. Key roles, artifacts, principal events inn SCRUM [4]] Sprint Sprint phase is one in which software development takes place. It consists of a selected list of requirements to be implemented in next iteration, selected by team toger with Scrum Master Product Owner inn Sprint planning meeting. Roles In Scrum, re are threee roles: Product Owner, Team, Scrum Master [4]: Product Owner: is responsiblee for maximizing return on investment (ROI) by identifying product features, translating se into a prioritized list, deciding which should be at top of list for f next Sprint, continually re-prioritizing refining list. In some cases, Product Owner e customer aree same person. team: is responsible for building product customer will use, it is self-organized (self-managing), it has a highh degree of autonomy responsibility, r re is not a project leader. Team decides what to commit to, how to do best to t accomplish that commitment. It usually consists of sevenn people. El SCRUM Master: is responsible for SCRUM functioning in project. He takes caree of aspectss organization needs, according to his knowledge / or experiencee with model. And also he takes care of those aspects that or people lack knowledge of. He makes sure everyone (including Product Owner those in management) understs followss practicess of Scrum, y help lead organization through often difficult change required to achieve success with agile development. ScrumMaster protects team from outside interference, educates guides Product Owner Team. SCRUM Meetings SCRUM conducts monitoring Project management through three meetings that make up model [6]: Sprint Planning: bases for planning are client business needs priorities. At this stage it is also determinedd which functionalities will product incorporate after next Sprint how. Sprint Monitoring: a brief, daily meeting, no more than 15 minutes, in which each member of f team explains tasks y are working in, if any difficulty has aroused or if any is already anticipated, updates upon Sprint backlog finished tasks, or remaining work time. SCRUM Files Within generated files [9] d [4] are mentioned: Product Backlog. It is a high level file for Project, it is evolving constantly. It contains generic descriptions d of all requirements, desired functionalities, etc., e ranked according to its business b value. It contains estimates, for business value as well ass development effort required. User Story S is a term very much used to designate Product Backlog requirements or functionalities. Sprint Backlog. It describes in detail how e team will implement requirements during next Sprint. Tasks are divided in hours, with a maximum of 16 hours. If this happens, tasks must be divided d in a more detailed way. tasks in Sprint Backlog are not assignedd but rar performed by teamm members way y best consider c it. Burndown. It is a public graphic that measures amount of unresolved requirements in Project Backlog, at beginning of each Sprint. progress off project can be seen when drawing a linee that connects dots of all finished Sprints. commonn thing is that this line be descending (in cases in which everything goes right, r in sense that equirements aree well definedd since beginning y do not vary) until it reaches r horizontal axis, inn which case project has ended (re are no more unresolved requirements in Backlog). If during processs new requirements are added straight line will have ascending slope in some segments, if some requirements are modified, slope will vary or even worth zero inn some stretches. SCRUM Phases methodology proposes following three phases p [7]: Planning Phase: Planning: team, tools, development system are defined. Product Backlog is created as well as list of known requirements togerr with ir priorities, needed effort to perform it is estimated (Sprint Backlog). Architectural Design: architecture of product is defined. It has too be one that permits to implement requirements. Development Phase: it is agile part, in which system is developed in Sprints. Each Sprint includes i all traditional stages in software development: equirements survey, analysis, design, d implementation delivery. Completion Phase: it includes integration, testing y documentation. It indicates implementationn of all requirements, leaving Product Backlog empty. 2. EXPERIMENT Company origin methodologyy exposed above, was applied to a company, physically located in Corrientes province, offering software development services in NEA region of country. It was set upp by integration of professionals d advanced students from t careers 111

3 Graduates in Systems (UNNE 1 ) Engineering in Information Systems (UTN 2 - FRR) in order to face toger first unique job opportunity, to develop a full software system, that includes sales client management, stock list, accounting logistics, among ors, for a furniture company from Formosa province. company was originally composed of three founding partners, whom estimated that project requested by contractor, will consume a first developing stage of between months, followed by a trial period of 6 months corresponding system maintenance. Company s structural situation Nowadays, company is at beginning of creative entrepreneur stage, which first crisis was emergence of a great deal of transactions that escape control without a formal tool. PyMES 3 current conformation is interdisciplinary, formed by 2 (two) University Application Programmers, 2 (two) Graduates in Management 3 (three) Engineers in Information Systems, whom through a rudimentary procedure intended to control ir transactions. However, when business opportunities arise, in order to make profit out of m, it is necessary to have support of an organizational structure according to requested characteristics. Origin of problem After an organizational diagnostic, carried out by Management professionals, following problems ir associated risks could be identified [2]: Inadequate Organizational Structure: risk arises due to lack of experience / or lack of management knowledge of software enterprises founders. As a consequence se companies tend to remain stuck in a certain development growth level in which structure cannot bear increasing trading volume. Inefficient Project Management: This is linked with software production area, where development is tailormade. In this process, production costs that are incurred have a high impact in total costs, mainly, developing hours (hours - man), which if not managed appropriately may provoke an important loss for company. se represent 90% of total costs in most projects. Linked closely to this problem, it is budgeting process, at this point it is vital to have an estimation as close as possible to reality. Besides, re is an essential factor in project management: team work; to find optimum way to deal with it, flexibly according to installed capacity, which will be key to success. SCRUM selection reasons Because of stated above, objective is: to strengn company s operative management, by means of using a formal tool, one that is adequate to business profile also that provides a more agile flexible view with management principles guidelines to innovation in its application. Next, main advantages that support choice for this methodology over or existing ones are mentioned: 1 UNNE: Universidad Nacional del Nordeste Facultad de Ciencias Exactas y Naturales y Agrimensura 2 UTN: Universidad Tecnológica Nacional Facultad Regional Resistencia 3 PyMES: Small Medium Enterprises It is simple: it is easy to transfer knowledge to ors, who will underst it thus being able to put it into practice. re is a need for a SCRUM Master who understs his role who s willing to carry it out with dedication, a team that will self-manage. Emphasizes visibility: it is a vital factor of SCRUM that progress achieved is visible, that is to say, that deliverables be functional probable. re is a key moment in which that characteristic reaches its peak, during Sprint Review, moment in which team presents progress made in last Sprint. On top of this, client may decide to put into production already developed stuff, thus determine beginning of recovery of his investment. It has clear rules roles: Every activity workflow is defined explicitly by use of clear norms. SCRUM Master role makes it possible controls that se rules are obeyed. It is based upon personal commitment: team is committed to implement certain functionality in a certain time (generally 15 days duration Sprints). It does not have power over what only over how much (how much can be done in a Sprint) how (it is responsible for technical solution). It solves problems day by day: daily SCRUM meetings are, in an effective way, good for detecting problems, carry out a daily monitoring, planning to short term, thus y permit to materialize optimize use of time. It allows carrying out agile measurements: se measurements facilitate feedback. For example: team s developing speed can be measured; it is possible to compare progress time among different Sprints projects that later facilitate incorporate accuracy to process of time estimation budgeting. SCRUM Implementation After organizational diagnostic carried out by specialists in Management, process of SCRUM implementation started. It consisted in three stages: 1. In first place, development team suggested this methodology as most adequate one to strengn company s projects management. This proposal was verified with management report of Management specialists. A training meeting in SCRUM methodology was arranged. In this meeting, most important concepts principles of Agile Movement a oretical basis of SCRUM were exposed, n application concepts were both presented discussed. After this stage, all members of company had a clear understing of adopted methodology. 2. SCRUM Application to an ongoing Project: at this stage, management team had to design take over role of SCRUM facilitators. y had objective of guiding developers in application; that is to say, apply all conceptual contents learned, in an ongoing project in company, thus accomplishing ory-practice relationship in reality. 3. innovation at this stage was linked to fact that role of SCRUM Master was not formally assumed by any developer, idea was to encourage team self-management that every member should have knowledge of responsibility that it implies. Thus it was decided that mentioned role 112

4 was rotational among members from one Sprint to or. 4. Monitoring of SCRUM applicationn in company: it was supported by management team in ir facilitators role. A web service of shared storing was implemented in order to carry out tracking off project s documents (workingg hour charts, Burndown, etc.). Project study case in whichh exposed methodology was applied, tackled execution of o an integrated management software system for a furniture factory network located in Formosa province. following roles weree assigned to e participants: Product Owner: one case peculiarities p is that Product Owner is outside Corrientes province. This determined thatt communication between him team was made through , e Messenger, Skype, etc., supported byy post-planning documentation online reviews. Project focused more towardss self-management than to SCRUM Master prevalence. Facilitator team (administrators): y were in charge of promoting SCRUM application of including a holistic view upon software development management. development team members,, constituted by 5 (five) Analysts-programmers: had an active role during whole SCRUM application process. Initial Backlog of product Product Backlog was developed from interviews with Product Owner key people interested in project; main objective was to havee all necessary information about Business Case. n, it was created a list with all requirements or functionalities ranked; se weree obtained from an immediate need analysis of business. This stage was characterized for difficulty to conciliate objectives; manage different codes, from part of company technicianss Product Owner. Before planning meeting of first Sprint,, working team created a requirement list based on needs exposed by Product Owner. Team s initial working speed In order to estimate team's workingg speed, first it was determinedd how many available hours each e team member had during 15 days of Sprint [5]. A total of 101, 5 weekly hours was obtained, consideringg that 100% % of total hours are not worked entirely. It was decidedd to implement a dedication factor (percentage of effective work to be done). Its value was determined in 40% based on work experiences on current publications [5], that is to say, it was stablished an efective work time t of 81, 2 hours for 15 days duration of Sprint. Thus team agreed to carry out ir tasks in a more appropriate way according to ir real capacity. Sprint Duration It was agreed to use Sprints of 155 working dayss during whole project, such a time was defined as suitable because it had been decided to generate constant contact with client thus respond r appropriately to e requested changes to e possible problems that couldd arise. Functionalities breakdown of Product Backlog Product Backlog B functionalities which were previously prioritized in agreement with Product Owner were broken down basedd on team s technical experience, in concrete manageable tasks. t objective was to determine simple tasks that allow a practical assignment more convenient thatt at end of Sprint ree was a functional deliverable, visible to client. Tasks Estimation: Use of Pokerr Planning After, breaking down functionalities into tasks, re was a general view of ir volume. It was specified: Task Name. Work Order. Time Estimation. Technical comments for its execution. In order to carry out tasks estimation time, Poker Planning technique was used: each member of o team had a pack of 13 cards (Figure 2). Each time that a task should be estimated, it was selected a card that represented r its time estimationn (in developingg hours) it was placed with numbers facing down on table. Once all team members selectedd ir cards, se were turned up at same time. Thus each member r was forced too think for him/herself instead of following ors estimation. After a debate about technical opinions, specific times for each task were w agreed on. estimations were register on an excel chart similar to that on Figure 3. objective of this planning was: Involve each member in every task. Obtain eachh member own view without being affected by that of expert. Solve conflicts prior to development. Exploring possible inconvenients anticipating solutions. Discuss technical aspects in n each task. Share experiences. Figure 2. Planning Poker Cards Sprint Planning It is most important meeting in SCRUM application; it is vital to devote necessesary time to it. Upon reached conventions, deadlines, estimations deliverables were defined. Its importance lies in fact that it is software development process starting point. results are exposed next: 113

5 Lack of information aboutt business logic when facing a problem. Lack of communication within team. This problem wass tackled down by implementation of a virtual information storage unit, which was ass a common space for exchange update. More precisely, it was Dropbox, in its free version, tool that was used. Dropbox is a file hosting servicee that offers cloud storage, online file synchronization as well as among computers it allows to share files folders with ors. Once desktop client programmee was installed, it was possible to leave any file in a given folder. That file is synchronized in cloud in all or desktop units of Dropbox client. Figure 3. Return of scheduled tasks Sprints Construction prioritized functionalities ir corresponding tasks (estimated in developing hours) were assigned too first Sprint. To do this, team s developing speed Sprint duration were considered. Creation of Sprint board With all necessary information, e Sprint board was built; it is composed by 4 sections. first section is about unfinished tasks, second one, about assigned tasks, third section shows finished tasks d forth, represents unplanned tasks necessary for Sprint completion. In this board all t functionalities, ir respective tasks Burndown graphic are shown. Post its of different shapes, sizes, colours were used for comments lists. se allow a dinamyc agile use. Daily Work At beginning of day, developers selected d tasks to be done, choosing freely, according a to ir importance from unfinished task group. Each one chose task y felt more comfortable with, writing ir names putting m onto completed c tasks as y finished. In each daily meeting information onn board was updated. Sprint Completion At moment of ending each Sprint, re was a module of final deliverablee product. Besides, re was a meeting of retrospective. In that meeting team discussed Sprint results, analyzing Burndown graphic (Figure 4), determining changes to be done onto next one, as to increase productivity, correcting inaccuracies suggesting improvements. biggest detected problem wass linked to underestimation, in working hours, off broke down tasks in first Sprints, testing, changes in data base, correction, functionalities demonstration. This was due to team s lack of experience in i estimation. This led to delays in tasks completion. On top of this, re was inconvenient when solving problems derived from: Figure 4. Sprint Burndown Chart (Partial Sprint) 3. CONCLUSION interdisciplinary links among Graduates Engineers in Systems Graduates in Administration allowed to face SCRUM application not only o as an isolated practice within PyMES forr software development, but also as an action inside strategic plan of it. main objective o was to initiate a formalization process in projects management to developp a dynamic organizational structure that willl dispose company for future growing phases. It is considered that experience of using SCRUM was ultimately positive. A complete adapted application of all practices was carried out, involving organization actors comprehensively. planning mistakes made during d first Sprint served as an important feedback in order to replan followings. first stages meant an increasement in productive efficiency, proving that it iss possible too apply a methodology that would speed up management optimize costs, also generate software with dynamic requirements. One of most evident outcomes of application of this practice was involvement of people with project with company s objectives; exteriorized e through a high level of commitment participation from part of each member in planning, design d execution stages. fact of rotating SCRUM Master role may be favorable for future as it encourages independence in case of absence of any participant wher temporarily or permanently, allowing reassignment of role. On or h, h Burndown graphic allowed observing improvement in estimation, contributing c to facilitate completion c of any action when reality deviates from planning. Besides,, it gives team an idea about its status as regards commitment. 114

6 After continuous application of exposed model, it could be appreciated that when team moves forward faster than expected, it must consider, in Sprint planning stage, estimation of more tasks in order to continue working. Likewise, if team falls behind, because of a wrong estimation of tasks, re is possibility to cancel Sprint to plan again, this time with more accurate data. Experience was acquired in breakdown or itemization of tasks, also team s communication capacity was powered. process of adapting this practice to company s own structure culture was a right decision that will allow in midterm, adopting SCRUM fully, including it to organization in a natural way. 4. REFERENCES [1] Canós J., Letelier P. y Penadés M. (2010): Metodologías Ágiles en el Desarrollo de Software. Universidad Politécnica de Valencia. En: f. [2] Chiavenato H. (2006). Introducción a la Teoría General de la Administración. [3] Coplien, J. (1994). Borl Software Craftsmanship: A New Look at Process, Quality Productivity. Proceedings of 5th Annual Borl International Conference, Orlo, Florida [4] Deemer P., Benefield G., Larman G. y Vodde B. (2010): Scrum Primer. Scrum Training Institute. In scrumprimer121.pdf. [5] Henrik K. (2007). Traducción Proyectapolis: Scrum y XP desde las Trincheras, Cómo hacemos Scrum, [6] Mahnic V., Vrana I. (2007). Using stakeholder-driven process performance measurement for monitoring performance of a Scrum-based software development process. [7] Mendes Calo, K., Estevez, E. y Fillottrani, P. (2011): Un Framework para Evaluación de Metodologías. En: d/1878/47500/version/8/file/un+framework+para+e valuacion+de+metodologias+agiles.pdf. [8] Oliveros, A. (2007). Curso Administración de Proyectos de Software. Maestría en Ingeniería del Software. Universidad de La Plata [9] Palacio J. (2008). Flexibilidad con Scrum. [10] Palacio, J. Ruata, C. (2010) Scrum Manager Proyectos. In [11] Surl J. (1996): ScrumWeb Home Page, A Guide to SCRUM Development Process Jeff Surl s Object Technology Web Page. [12] Schwaber K. (1996): Controlled Chaos: Living on Edge. American Programmer, April [13] Sommerville, I. (2006) Ingeniería del Software, Séptima Edición. [14] Surl J., Schwaber K. (2011). Scrum Papers: Nut, Bolts, Origins of an Agile Framework, in [15] Takeuchi H. y Nonaka I. (1986). New Product Development Game. Harvard Business Review. 115