Engineering Change Management within agile Product Development A Case Study

Transcription

1 Engineering Change Management within agile Product Development A Case Study Lucia Becerril, Veronika Heinrich, Annette Böhmer, Sebastian Schweigert, Udo Lindemann Institute of Product Development, Technical University of Munich, Germany (becerril@pe.mw.tum.de) Abstract Currently, numerous approaches on how to cope with engineering changes exist in form of complex Engineering Change Management (ECM) systems. However, start-ups and small companies do t implement these systems due to the lack of flexibility and agility in addition to financial aspects. A trend mostly used within Software Development to cope with fast changing environments is agile development. However, while implementing agile frameworks into the development of mechatronic systems new challenges on managing Engineering Changes arise. The approach proposed in this paper aims to manage Engineering Changes within an agile framework providing decision support for three different situations in which changes can occur. Keywords: Engineering Change Management, Agile, Scrum, 1 Introduction and Motivation An Engineering Change (EC) is an alteration made to parts, drawings or software and it comprises any modification to the form, fit and/or function of the product as a whole or in part [1]. Currently, there are numerous approaches on how to cope with these engineering changes in form of complex processes. In many large companies, these processes are embedded into Engineering Change Management (ECM) systems. However, newly founded startups are inhibited to implement these large and expensive systems due to the little flexibility, the long waiting times, and the large infrastructure these systems entail in addition to financial aspects. In the case of startups, the management rather concentrates on the implementation of a suitable product development process that is able to deal with varying project conditions. An agile project framework that has been successfully implemented in this context is Scrum, although Scrum is mostly used within Software Development. In Scrum the development process is divided into time boxes called sprints. At the beginning of each sprint, the development team deduces concrete tasks for the sprint duration that together lead to a product increment (e.g. a new function) [7]. One of the core principles of Scrum is that ECs are made within a sprint, but incorporated into the Product Backlog, which contains the requirements to be fulfilled in the consequent sprints [3]. In the case of customer triggered changes, the process is relatively straight forward since change requests are mostly received after

2 2 finishing the sprint, during the sprint review. However, when ECs arise during an ongoing sprint (for example due to n-satisfactory partial results), few practical support exists. Thus, the development team often has to cope with the engineering changes with only intuition and common sense, especially if the team members lack experience. Within this paper, an engineering change management workflow that can be easily integrated in the agile framework Scrum. Hereby, the Scrum methodology is integrated into mechatronic product development. The situation of a change request occurring during a sprint is investigated and solved by adhering the proposed process to the Scrum framework. 2 Methodology The approach presented in this paper was formulated based on the experiences of Scrum practitioners, Scrum process regularities, and Engineering Change Management methods. A literature survey revealed a research gap in the area of Engineering Change Management within agile frameworks, especially for mechatronic product development. Thus, blogs and practitioners articles were explored and the results were discussed with project teams at a startup. Furthermore, the early stage of a development process within this company was observed. The Scrum Team comprised of four persons, including Scrum Master, Product Owner, and developers. Selected engineering change requests that were generated during ongoing sprints were then further investigated. 3 State of the Art In this section the core concepts of Engineering Change Management and Agile Development of mechatronic systems with Scrum are presented. Moreover, the research gap is further clarified. Engineering Change Management Fricke et al. [10] estimate that roughly 30% of work efforts are due to changes. Moreover, the later the engineering changes occur the more expensive it is to realize them since the risk of change propagation increases with the development progress [1]. In order to cope with Engineering Changes, a number of processes and methods have been developed. For example, Jarratt et al. [8] suggest a six step process for managing ECs. These six steps are illustrated in Figure 1.

3 3 Engineering change request raised Identification of possible solutions to change request Risk /impact assessment of solution Selection and approval of a solution by change board Implementation of solution Review of particular change process Fig. 1. Generic ECM process, adapted from [8] Furthermore, Wickel et al. [9] compared seven industry-specific Engineering Change Management processes and identified six common steps: Identification, Preparation, Decision, Operation, and Review. Although the companies studied were mostly OEMs and larger suppliers, these general steps are transferable in different scopes to the management of changes in a start-up and provide a frame for the process presented below. Agile Project Management Agile project management was derived from agile software development. Its purpose is to help a project team adapt quickly to the unpredictable and rapidly changing requirements [5]. Several approaches for developing products with agile methods exist today, for example Scrum. However, they share some basic concepts that distinguish them from traditional project management approaches [5]. The Manifesto for Agile Software Development [6] states four core principles: Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

4 4 Moreover, agile project management emphasizes two important concepts [5]: The first one is focusing on short iterations of clearly defined deliverables and thus minimizing risk, especially in fast-changing environments. The second is emphasizing direct communication over project documentation. One popular agile framework is Scrum. It comprises roles (Product Owner, Scrum Master, and Development Team) and artifacts (Product Backlog, Sprint Backlog, and Product Increment). The Product Owner decides what work will be done, while the Scrum Master ensures the best use of Scrum. Moreover, the Development Team develops the product incrementally, in a series of short periods of time named Sprints. A sprint is a fixed timed period, usually between one and four weeks, in which the team develops and delivers a Product Increment. [7] Furthermore, the product backlog is a list of ideas for the product while the Sprint Backlog comprised the detailed plan for the next Sprint. The Product Increment is a recognizable, visibly improved, operating subset of the product and the required result of a sprint. [7] 4 A Workflow for Managing Engineering Changes within an Agile Framework This section gives an overview of the workflow proposed for managing Engineering Changes within an agile framework. This workflow has three decision points that cover most cases of changes that can occur within a sprint. These are: The engineering change is implemented in a future sprint (as foreseen in the Scrum methodology). The engineering change is implemented within the current sprint. The cause of the engineering change compromises the Product Increment so that the current sprint is cancelled. The flowchart in Figure 2 illustrates the proposed approach. In the first step of the proposed workflow, an Engineering Change Request (ECR) is created. Once the ECR is evaluated and approved, it is transformed into one or more requirements of the product backlog, which is then prioritized as indicated in [3]. Although they are important, the steps of Identification, Preparation and Review of the engineering change mentioned above (c.f. [9]) are outside of the scope of this paper. It is assumed that the change requested is useful and should be implemented. A number of existing support approaches for this decision can be found in the literature (c.f. [1]). Besides adding the ECR to the product backlog, this workflow proposes to evaluate the implication of the request for the ongoing sprint. If the EC causes the sprint goal (i.e. the Product Increment) to be invalid, the current sprint should be terminated in agreement with the product owner and the stakeholder and a new sprint must be planned (Path C). If the planned sprint goal is valid despite the change causes, but the value of the results would be (significantly or somewhat) reduced by t implementing this change, then, the ECR could be added to the ongoing sprint backlog. However, it

5 should be assessed if the sprint goal is still achievable within the planned timeframe after adding these additional tasks (Path B). If t, the requirements derived from the ECR are executed in a future sprint, which is the regular procedure in Scrum (Path A). If the value of the sprint results is t (or slightly) affected by the EC, the sprint will also continue as specified in the sprint planning and the standard procedure for managing changes will be followed (Path A). 5 Include ECR as a requirement in PB (PO) Re-prioritize PB (PO) Plan sprint (PO, DT, SM) Start sprint DT Development Team EC Engineering Change ECR Engineering Change Request PB Product Backlog PO Product Owner SM Scrum Master SH Stakeholder Request and approve EC* Is the goal of the sprint compromised? Request permission to cancel the sprint from PO and SH Cancel sprint C Is the value of the sprint reduced by t implementing the EC? Is the sprint goal achievable if the ECR is added to the sprint backlog? Add additional task to sprint backlog B End sprint as scheduled A *It is assumed that the EC is useful and will be implemented at some point in the project Fig. 2. Managing engineering changes within Scrum. A: Engineering change is implemented in future sprint (Standard procedure) B: Engineering change is implemented within current sprint. C: Engineering change requires immediate reaction. Current sprint is cancelled.

6 6 5 Case Study The startup in which this case study was conducted, founded in 2012, is currently implementing agile product development. This company focuses on the realization of invative engineering ideas from different external customers and the development of a fundamental prototype that can be carried over to the production stage by the customer. Several development projects in small teams of two to five developers are running at the same time. Each development team is individually composed of graduate students and young professionals from an internal database that covers the fields of computer science, mechanical, and electrical engineering. Thus, every project is conducted by the best matching developers from the pool. The start-up s customers vary from large experienced industrial partners to private citizens having technical background but an invative idea. Moreover, the company emphasizes the close collaboration between development team and customer. Thus, it ensures that most change requests made by the customer are implemented. One of the pilot projects for implementing agile frameworks was the development a food processing system. Within this project, the development team faced both the challenges arising from the integration of agile project management and the product-related technical problems of early development phases. Furthermore, the analyzed project was funded by a governmental organization with few technical background. Hence, the development project had abundant iterations while working under time pressure. Engineering changes were required frequently. This and similar projects are the reason why a framework how to deal with engineering change requests is essential. Nevertheless, comprehensive ECM Systems are very expensive and their implementation is time consuming [1]. Furthermore, due to the lack of flexibility of these systems and their scope, these established ECM processes and tools are t suitable for start-ups with less mature development processes like the one presented in this case study. As a result, an alternative solution is required for this situation, which can be easily embedded into the agile framework. For this purpose, core principles of the agile framework should be kept for example, usually t making alterations during a sprint. As stated in section 3, the standard process within Scrum when the necessity of an Engineering Change arises during an ongoing sprint, is adding the ECR to the product backlog. Subsequently, the product backlog has to be re-prioritized and the highest prioritized items of the backlog are carried out throughout the following sprint [4]. In this case, the sprint can be completed as scheduled without extending the sprint backlog. However, this procedure only works if the results of the current sprint are t significantly affected by the cause of the ECR. In this case study, the project examined presented two situations in which the value of the sprint goals would be significantly reduced or could t be reached following the standard approach. These two situations required immediate action of the development team and the stakeholders. The first EC was triggered by an incomplete CAD-Model, which caused an incorrect drawing. Then, this drawing was sent to an external workshop for manufacturing a part. The error was discovered when the prototype showed a malfunction that

7 was traced to this part. If this ECR was t attended immediately the Product Increment (e.g. the prototype) will t meet its requirements at the end of the sprint. The effort estimation indicates that the part can be modified rapidly without delaying the sprint. Hence, the sprint backlog is extended by the corresponding task complete CAD-Model to ensure a satisfactory product increment by the end of the sprint (Fig.3). 7 Request and approve EC* Is the goal of the sprint compromised? DT Development Team EC Engineering Change ECR Engineering Change Request PB Product Backlog PO Product Owner SM Scrum Master SH Stakeholder Is the value of the sprint reduced by t implementing the EC? Is the sprint goal achievable if the ECR is added to the sprint backlog? Add additional task to sprint backlog B End sprint as scheduled Fig. 3. The EC is added to the product backlog to be implemented in a future sprint The second EC derives from a more complex situation. The rough concept of the food processing machine was required by the stakeholders at the beginning of the project. Due to time pressure the team neglected evaluating the concept thoroughly. Several weeks after the project had started, the developers examined the concept by conducting a series of experiments, with the outcome that the properties of the selected material are inadequate for the proposed concept. After experimenting with different materials, the initial concept had to be discarded. Since the necessary change involves re-designing the whole concept, to continue the current sprint is useless. Thus, it is necessary to request a cancellation of the ongoing sprint (Fig.4). Once the permission is given by the stakeholders, the sprint is cancelled and the product backlog can be modified to the new proposed concept.

8 8 Plan sprint (PO, DT, SM) Start sprint DT Development Team EC Engineering Change ECR Engineering Change Request PB Product Backlog PO Product Owner SM Scrum Master SH Stakeholder Request and approve EC* Is the goal of the sprint compromised? Request permission to cancel the sprint from PO and SH Cancel sprint C Fig. 4. The sprint is cancelled after approval of PO and SH 6 Conclusion and outlook In contrast to the standard Scrum procedure for managing changes, the herein proposed approach regards the development situation at the time of an ECR. However, the simplicity of the workflow proposed, comparing it to existing ECM approaches, enables to easily integrate it into an agile framework. Furthermore, the Workflow for Managing Engineering Changes within an Agile Framework provides decision support for evaluating the change request s implications on the ongoing sprint. This is illustrated in the presented case study. Nevertheless, it is suggested to proactively manage changes by scheduling short sprint durations at the beginning of the development process and deriving highly specific tasks from the product backlog [3]. Consequently, significant errors will be detected earlier and the change effort remains low. Future research will examine, whether this approach is a sufficient documentation of engineering changes, when adding and removing requirements to and from the product backlog. This is especially relevant for companies, such as automotive suppliers, that are required to compile with rms for documenting their engineering changes (e.g. DIN [10]). Moreover, the workflow should be further evaluated by implementing it in a broader selection of startups that use agile project management methodologies.

9 9 References[LB1] [1] Jarratt, T. A. W., Eckert, C. M., Caldwell, N. H. M., & Clarkson, P. J. (2011). Engineering change: an overview and perspective on the literature. Research in engineering design, 22(2), [2] Sharafi, A. (2013). Kwledge Discovery in Databases: Eine Analyse des Änderungsmanagements in der Produktentwicklung. Berlin: Springer. [3] SCRUMstudy (2014, June 09). How is Change management embedded into the Scrum Framework? Retrieved from [4] Schneider, S. (2015, November 01). Scrum und Änderungsmanagement. Retrieved from [5] Cervone, H. Frank (2011): Understanding agile project management methods using Scrum. In: OCLC Systems & Services 27 (1), S DOI: / [6] Beck et al. (2001): Manifesto for Agile Software Development. Retrieved from ( ) [7] Scrum Alliance Inc. (2012) Scrum: a description. Retrieved from ( ) [8] Schwaber, Ken (2004): Agile project management with Scrum. Redmond, Wash.: Microsoft Press (Microsoft professional). [9] Scholz-Reiter, B., Krohne, F., Leng, B., & Höhns, H. (2007). Technical product change teams: an organizational concept for increasing the efficiency and effectiveness of technical product changes during ramp-up phases. International journal of production research, 45(7), Chicago