Implementing Agile Processes for Deploying Software Processes Improvement based on Scrum at Chemtech Taciana Melcop#1, Juliana Acchar#2, Gustavo Costa#3 , Analia Irigoyen Ferreiro Ferreira*4, Anne Elise Katsurayama*5, Mariano Angel Montoni*6, David Zanetti*7 #
Chemtech – A Siemens Company Rua da Quitanda, 50, 21º andar, Centro, 20011-030 Rio de Janeiro, RJ, Brazil 1
2
[email protected] [email protected] 3
[email protected]
*
ProMove – Business Intelligence Solutions Rua Marechal Mascarenhas de Morais, 120, Copacabana, 22030-040 Rio de Janeiro, RJ, Brazil 4
5
[email protected] [email protected] 6 7
[email protected] [email protected]
Abstract— This paper presents the experience in implementing software processes adherent to CMMI-DEV Maturity Level 3 and MPS.BR Level C at Chemtech, using an agile approach based on Scrum. The activities executed for implementing the processes are described in this paper. Moreover, the lessons learned, success factors, difficulties and weaknesses observed during this experience are also described. The knowledge acquired during the execution of the process not only provided the means for the Chemtech’s members to conduct the trainings in the defined processes, but also enabled the execution of pilot projects after eight sprints and four months since the beginning of the implementation. Keywords— CMMI-DEV, MPS.BR, Scrum, agile, process improvement.
I. INTRODUCTION In Brazil, software development organizations have been increasingly looking forward to improve the quality of its products and to reduce the cost of development by software processes deployment [1, 2]. Moreover, the marketplace is recognizing these quality certificates as a way to qualify and differentiate the potential software suppliers. In this context, the importance of implementing processes adherent to standards and reference models such as MPS.BR [3], CMMI-DEV [4] or ISO 9001:2008 [5], and the agility in deploying process improvements become essential to make software organizations more competitive and motivated to keep the quest for quality. Thus, as a software development process, the deploying improvements process has also the main objective to develop high quality products in the shortest time.
This paper aims to describe the experience of Chemtech in deploying new processes compliant to CMMI-DEV Maturity Level 3 and MPS.BR Level C, which began in July 2009, to improve the quality of its processes. Despite this goal, the organization had set some other targets: define the processes compatible with the organization culture (agile and easily adapted to innovation situations); integrate these processes with already defined processes compliant to ISO 9001:2008; and the employees themselves were responsible for defining the processes, characterizing the importance of knowledge management throughout this initiative. The challenge of achieving the main goal and the targets motivated the decision of Chemtech to use agility aspects in the software processes deployment. In addition, some characteristics of agility motivated the definition of these processes at Chemtech, such as [6]: all members are part of a team and are committed to the project (including the consultancy team), the team must deliver something palpable, in this case, part of the library assets (processes, process components, processes selection and deployment in tools, guidelines, technical instructions, etc.) at the end of each iteration; short iterations with predefined time (timebox); and processes adaptation to specific situations and continuous learning. More detailed information regarding the deployment process, difficulties, success factors and lessons learned are provided in the next sections. In section 2, we provide a brief review of the literature regarding agile methods for project management. Details of the current version of the approach used at Chemtech based on Scrum are described in section 3. In section 4, we discuss the lessons learned, difficulties and
results of this process. Finally, section 5 presents the paper conclusion. II. AGILE METHODS FOR PROJECT MANAGEMENT Agile methods for software development had its beginnings in the '80s as part of a movement against the bureaucratic methods of software development. The development of these methods was motivated by the need to overcome the problems of traditional methods like the waterfall model, considered by the pioneers of agile methods slow and contradictory to the efficient work of software engineers [6]. Nowadays, XP (eXtreme Programming) and Scrum are standing out among the agile methods for software development. While the focus on XP is on programming practices, Scrum focuses on project management practices. Initially, the Scrum was conceived as a project management style for automotive manufacturing companies and for consumer products [7]. Based on the Scrum formation of the Rugby, these authors noted that projects using small and multidisciplinary (cross-functional) teams produced better results. In 1993, Jeff Sutherland, John Scumniotales and Jeff McKenna have documented and implemented Scrum at Easel Corporation [8] based on the project management style observed by [7]. Finally, in 1995, Ken Schwaber formalized the definition of Scrum for software development projects and assisted in the implementation of this methodology in software development organizations around the world [9, 10]. Despite being focused on software development project management, Scrum can be applied in any context in which a group of people needs to work together to achieve a common goal, for example, a research project. Moreover, the Scrum can also be applied as a portfolio management projects approach (Scrum of Scrums) [10]. The main characteristics of Scrum are [9]: • The Scrum stages are divided into “sprints” or iterations that correspond to a period of 2-4 working weeks of the team. Each sprint follows the PDCA (Plan-Do-CheckAct) cycle and delivers an increment of the final product ready to use. The focus of each sprint is to deliver items that show highest business value (and priority) to the client, giving him something that will bring real business value. • The group of requirements is called product backlog and is ranked by priority by the product owner (client). • Every day, a brief daily meeting is carried out and is commonly called “Scrum Standup Meeting” where each team member reports the progress achieved in the task under his/her responsibility, the work to be done and the issues that is hindering the execution of the tasks. • The planning task is short and consists on selecting items for a particular sprint backlog. These planning meetings are known as: Sprint Planning 1, Estimation Meeting or Planning Poker and Sprint Planning 2. • Among the sprints there is a retrospective where team members reflect about the past sprint. These meetings are known as Review of Sprint and Sprint Retrospective.
The Scrum Master plays the role of the facilitator who must remove the obstacles for the team to reach the sprint goal. He acts as a mediator, motivating the team and ensuring that the Scrum practices are being followed. In this paper, the agile management Scrum framework was selected as the basis for defining and implementing the software process adherent to CMMI-DEV Maturity Level 3 and MPS.BR Level C at Chemtech, as shown in more details in the next section. •
III. AN AGILE PROCESS FOR SOFTWARE DEPLOYING PROCESSES AT CHEMTECH To accomplish the implementation of process improvements at Chemtech, we used an agile process based on: (i) practices defined by the Scrum framework [6]; (ii) the Organizational Process Focus (OPF) of CMMI-DEV [4] and the Organizational Process Assessment and Improvement of MPS.BR [3]; (iii) the objectives, goals and resources available for project planning; and (iv) the needs and problems identified during the sprints execution at Chemtech. To support this approach a process containing the detailed activities and tasks description was defined. The notation used to represent this defined process was developed by [11]. The defined process, shown in Figure 1, contains the organizational tasks and consists of the following subprocesses: (i) Project Planning (ii) Sprint Planning # N, (iii) Sprint Execution # N, (iv) Sprint Closure # N, and (v) Project Closure. The organization established four major goals for the project improvement initiative named "Towards CMMI ML3", besides the official assessment that is planned for being conducted as of October 2010. These goals are: (i) procedures defined adherent to the organization’s culture; (ii) processes integration already in place and adherents to ISO 9001:2008; (iii) knowledge dissemination; and (iv) validation of the defined processes in pilot projects. We considered essential the definition of mini-teams during the improvement project planning. Ten mini-teams were defined; each team was composed of three Chemtech members, according to the following areas: requirements, project management, measurement and analysis, quality assurance, testing, portfolio management, human resources, acquisition, architecture and process improvement. These mini-teams worked in parallel and each member had 20 hours dedicated to each 2 weeks Sprint. Each mini-team had a Scrum Master performed by a Chemtech member and the Product Owner role was performed by a ProMove member, the consultancy staff. A product backlog was established and prioritized for each mini-team with the Product Owner support. Moreover, the improvement project goals and mini-team were officially presented to all members of the organization. The first product backlog was based on research and discussion of each miniteam process areas. The next Product Backlogs embraced the definition of process areas procedures, guidelines, templates discussions and approvals.
Figure 1 Library Assets Deployment Process During the two weeks Sprints, the tasks were detailed in post-its attached to a whiteboard (Figure 2), and eventual misunderstandings were clarified by the Product Owners. The tasks that were not ended in the current Sprint returned to the Product Backlog and were reassigned by the project Product Owner and Scrum Master.
Figure 2 Scrum Whiteboard In the first five sprints, meetings were held with the improvement project's Scrum Master (Scrum of scrums) and the mini-teams’ Scrum Masters, with the aim of monitoring the progress of the improvement project. After the fifth Sprint
these meetings involved all available members of the miniteams, mainly because it was necessary to discuss the integration points between them. At the end of each Sprint, a Project Status report was prepared with the aim of monitoring the progress of all mini-teams involved. The "Assets Library Deployment" phase was closed at the Sprint # 8 and the actual project phase is "Monitoring of the Project Processes". IV. RESULTS AND LESSONS LEARNED The results and lessons learned with the project execution are divided according to the improvement project objectives described in section 3. The goal related to establishing procedures according to the organizational culture was deemed to be satisfied, since the asset library was established with active participation and effective adoption of more than thirty people in the organization (divided into mini-teams). Regarding the second objective, all processes defined according to ISO 9001:2008 were considered during the definition of the process, as shown in Figure 3 and Table 1. Few changes were made in the process framework. Table 1 shows the quantitative results of the asset library, while Figure 3 shows the processes framework, with their additions, changes and processes in place that had no changes.
Support
Fundamental
Organizational Process Definition
Supplier Agreement Management
Configuration Management Updated
Standard Development Process
No Changes Created
Quality Assurance
Specialized Process
Verification
Requirements Management and Development
Validation Internal Audits
Technical Solution and Decision Analysis
External Audits
Product Integration
Measurement and Analysis
Organizational Project Management
Project Management Office
Infrastructure
Software Reuse
Identification and Tracebility
Trainning
Human Resources Management
Knowledge Management
NCs, Prevention and Corrective Actions
Product Non Conformance
Portfolio Management
Action Plan Management
Figure 3 Process Asset Library Structure The third achieved goal was the management of the knowledge acquired during the execution of the process improvement implementation, and the effective dissemination of knowledge about the reference models adopted and the organization’s own processes. The evidence of the achievement is that the organization's own staff members of the mini-teams participated in the development and taught the trainings to other organization’s members. Regarding the fourth goal, at the end of the Sprint # 8, eight of the 10 pilot projects (deployment of the defined processes by mini-teams in real project) were executed. Improvements to the asset library were identified and the processes were considered "ready" to be institutionalized. Difficulties in sprint planning and monitoring were observed throughout the project, many of them due to the sharing of resources between the organization's projects. The main difficulties were: (i) retrospectives were made during the sprints in the meetings, diverting the defined improvement process focus and not the meeting goals, making it longer; (ii) not all members of the mini-teams participated in the meetings, making it difficult to communicate and make the sprint situation visible to all team members; (iii) the difficulty in defining the size and the time required to perform a particular activity caused some delays in the project; and (iv) high rotation of the mini-teams members. Because of the team members’ inexperience in defining processes and play the role of Scrum Master, the consultancy was a constant presence, guiding and evaluating the artifacts generated by the mini-teams members. If this presence was not constant, the visibility of the progress of the projects could be compromised. Even with these difficulties, the results at the end of the deployment of the assets library were quite positive, motivating the organization to continue using the defined processes, with some adaptations for the next phase of
the improvement project that involves the processes monitoring in the organization. The indicators of project progress are linked to the percentage of adherence to the practices of each process area. These indicators are collected by monitoring the projects using a process implementation instrument that indicates the appropriate time for performing the assessment of the implementation. V. CONCLUSIONS The use of agile methods for deploying improvements proved to be efficient especially for spreading knowledge about the reference models and best practices allowing miniteams members to have a critical view of the process areas, and making the process definition more adequate to the culture and characteristics of the organization. In addition, the team was highly motivated with the process adopted. Another important gain with the use of the agility approach in the deployment process was that by using increments and focusing on continuous improvement, the adherence of the current process to the new defined processes was anticipated and consequently facilitated. However, it is important to highlight some aspects that are critical to the success of the improvement project: the organization members should enjoy defining processes and tools, mini-teams should preferably be composed with multidisciplinary members, the consultancy that plays the product owner must be present and accessible when needed, exchanging the mini-teams members where there are conflicting priorities with other projects and identify improvements aiming to control the projects whenever necessary. The monitoring of the project will continue until the official processes appraisal where more lessons learned will be collected and improvements in the process defined for this
project will be implemented, allowing more evidence of the potential benefits of using Scrum to software processes deployment.
[5]
REFERENCES
[7]
[1]
[2]
[3] [4]
Ferreira, A. I. F., Cerqueira, R., Santos, G., et al., 2006, "ISO 9001:2000, MPS.BR Ní-vel F e CMMI Nível 3: Uma Estratégia de Melhoria de Processos na BL Informática", V SBQS, pp. 375-382, Vila Velha, Brasil. Ferreira, A. I. F., Santos, G., Cerqueira, R., et al., 2007, "Applying ISO 9001:2000, MPS.BR and CMMI to Achieve Software Process Maturity: BL Informatica’s Pathway", 29th ICSE, Minneapolis, Estados Unidos. Softex, 2009, “MPS.BR: Melhoria de Processo do Software Brasileiro”, Guia Geral, Disponível em: http://www.softex.br/mpsbr. Chrissis, M. B., Konrad, M., Shrum, S., 2006, CMMI (Second Edition): Guidelines for Process Integration and Product Improvement, Addison Wesley Professional.
[6]
[8]
[9] [10] [11]
ABNT NBR ISO 9001:2008, Sistema de Gestão da Qualidade – Requisitos, Associação Brasileira de Normas Técnicas, v. ISO 9001:2008. Kniberg, H., 2007, “Scrum e XP direto das Trincheiras”, Editora C4 Media, Publisher of InfoQ.com. Nonaka, I., Takeuchi, H., 1986, The new product development game, Harvard Business Review. Sutherland, J., 2004, Agile Development: Lessons Learned from the First Scrum, Cutter Agile Project Management Advisory Service: Executive Update, volume 05, pp. 01-04. Schwaber, K., Beedle, M., 2002, Agile Software Development with Scrum, Prentice Hall. Schwaber, K., 2004, Agile Project Management with Scrum, Microsoft Press. Aguiar, H. V., 2004, PEPP: Processo de Software para Empresas de Pequeno Porte Baseado no Modelo CMMI, Graduação, Departamento de Ciência da Computação, Universidade Federal de Lavras.
