Incorporating CMMI with Agile Methods: Using Change Management

Incorporating CMMI with Agile Methods: Using Change Management Hassan Haghighi 1, Afrooz Khormaee 2, Mohammad shir mohammadi 3 Electrical and Computer Engineering Department Shahid Beheshti University 1 Hassan Haghighi, Assistant Professor, Faculty of Electrical and Computer Engineering, Shahid Beheshti University, Evin, Tehran, Iran. 2 Mohammad Shir mohammadi, B.S, Faculty of Electrical and Computer Engineering, PWUT University, Tehran, Iran. 3 Afrooz Khormaee, M.S, Faculty of Electrical and Computer Engineering, Shahid Beheshti University, Evin, Tehran, Iran. Abstract Agile development approaches promise increased customer satisfaction, faster development, and a solution to rapidly changing requirements. On the other hand, CMMI approaches promise predictability, stability, and high assurance. The topic talked over many times is that Agile development methods and CMMI best practices are fundamentally often perceived to be at odds with each other ; however, according to a technical document of SEI in the late of 2008 [1], it is now clear that these two approaches are compoundable. Now the main challenge is when and how to compound the two approaches in a way that takes advantage of their strengths while compensating for their weaknesses [2, 16]. More precisely, one of the main causes of failure in agile projects is stable requirements that have not been planned in initial designs, versus one of the main reasons of failure in CMMI projects are being highly variable requirements. In this paper, we provide a method for Projects structure based on the change management which clarifies when to incorporate agile and CMMI regarding features of a project. Based on our findings, we conclude that using agile approaches is appropriate for those systems which have small or medium size with a lot of changes and flexibility. In contrast, for very large and certain systems, with small or medium size and flexibility, we should use CMMI approach. Finally, for the systems with significant flexibility and changes, we could apply incorporating agile and CMMI approaches. Keywords Agile methods, CMMI, Change, Method selection, Incorporate, Software project management. 1 H_haghighi@sbu.ac.ir 2 A.khormaee@Mail.sbu.ac.ir 3 Shirmohammadi.m@gmail.com 297 I. INTRODUCTION In the software world, the main goal is quick responding to large projects which are under massive changes. Besides, in these projects some sections are partly sustainable while the others are largely changeable. The obvious thing in these systems is that not having only some aspects of agile method such as unsustainability, large changes, responding to them and interaction between the team's persons but also having some features of CMMI such as institutional and process documentation. If the agile methods only be used, then the project would not being complete because of this method could not working on large and complex projects and in other hand if the CMMI be utilized, the result is an inconclusive and ineffective project. This result is due to increasing making large changeable attempt to determining circumstance and details of the project that are under continuous updating changes and consequently they would probably be such increased that the all would be ineffective and the team become chill [3,4]. In addition, in agile methods, finding customer needs and special attendance to them led to better changes management; so attending customer beside the development team is one of techniques that these methods exploit it; but it is clear that involving customer up to this amount is one of changing system causes.

In CMMI methods, the trend is in different way. These methods base on warily and low risk development as well as traditional relationship between team's member and with customer. Although CMMI methods concentrate on process growths and organization maturity, if CMMI would be looking forward to persuade organization maturity levels, may lose some value on the customer's view such as product, product value, executive ability and business goals [1]. According to Boehm and Turner s writing, agile and CMMI are the two ways that end to same goal [3]. In addition, SEI in technical document in late 2008 by the name of "CMMI or Agile: Why Not Embrace Both? [1] Recommended that "these two methods are incorporative and remind this point that both methods with cooperation could reach organization productivity. According to scientific and research papers, look to need for a proper strategy for project management, So it can be take advantage of both methods merits. Therefore in this article, five features by the name of: project size, personnel level, culture, flexibility and level of requirement changes are introduced for choosing proper approach. The project size declares the number of team members. Personnel feature point to their understanding level and skill that defined by Cockburn as well as project leading style that designed by Hersey and Blanchard. After that it is revised by Boehm and Turner. Culture is defined as an organization personality. Regarding the importance of organization culture and difficulty of changing it, should say that measuring cultural Readiness is an important factor. In this regards, flexibility and requirement change degree is connected to project changing filed. Attention to flexibility helps managers to following changeable rules as well as meeting customer demands and takes advantage of new technologies. Requirements degree are defined according to three need categories. The paper is organized in the following way, in the first section we provide introduction for the background and necessity of a new approach. After that in the second section, the previous incorporation works about the topic are investigated. In the third section the base concept of Agile and CMMI is studied, and in the fourth section, five key features analyzed for selecting appropriate approach in software projects. In the fifth section the graphical chart for five key features of agile and CMMI approach have been shown. 298 The sixth section the approach for selecting project proper method is proposed. And finally, concluding remarks and future developments will be outlined. II. BASIC CONCEPTS A. Agile In the late 1990 s several methodologies began to get increasing public attention. Each had a different combination of old ideas, new ideas, and transmuted old ideas. But they all emphasized close collaboration between the programmer team and business experts; faceto-face communication (as more efficient than written documentation); frequent delivery of new deployable business value; tight, self-organizing teams; and ways to craft the code and the team such that the inevitable requirements churn was not a crisis The Agile Manifesto was written in February of 2001, at a summit of seventeen independent-minded practitioners of several programming methodologies. The participants didn't agree about much, but they found consensus around four main values [5]. Supplementing the Manifesto, the Twelve Principles further explicate what it is to be Agile. We are uncovering better ways of developing software by doing it and helping others does it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. These characteristics bring dynamism to development, motivation to the team, and more comprehensive information about the real situation of the project for the customer. Some conventional methods claim to be predictive. In contrast, Agile Methods are adaptive. This approach is fundamental for the success of most projects because requirements change as the customer needs change. There are several Agile Methods based on the principles proposed by the Agile Manifesto, including: Extreme Programming (XP) [6,7], Scrum[8], Crystal Methods[9], Lean Software Development[10], Feature Driven Development (FDD)[11], Adaptive Software Development[12], and Dynamic System Development Method (DSDM)[13].

They are used in small, medium companies and universities to build different types of software and have produced excellent results extensively described in the literature. B. CMMI There are many maturity models for managing systems to be used in different fields, including for software industry. The most recent is CMMI (The Capability Maturity Model Integration). CMMI is an extension of the CMM approach developed by SEI (Software Engineering Institute) at Carnegie Mellon jointly with DoD and industry. It was designed to integrate the proliferation of models like SW-CMM, SE-CMM, IPD- CMM and to be an aid for organizational and project process improvement. As Glazer et al say in [1], CMMI is not a process standard, but a model having as central theme the process management. CMMI is necessary to be and the best practices to be used for growing the capabilities of the organization. The appraisal method for process improvement is SCAMPI (Standard CMMI Appraisal Method for Process Improvement) and uses a review/journal of the process story containing the CMMI model used, the development practices of the organization, the improvements identified, and the ability in integration. There are two representations that called continuous and staged [14]. The most well-known representation of CMMI is the staged representation, which has five levels of process maturity for organizations. Performed Process is unpredictable, poorly controlled, and reactive. Managed Process characterized for projects, and is often reactive Defined Process is characterized for the organization, and is proactive Quantitatively Managed Process is measured and controlled Optimizing Focus is on continuous process improvement Each of the five levels is composed of several process areas for each process area, several goals are defined which contain different practices. III. RELATED WORK CMMI and agile methods are investigated in many researches; Boehm argues agile and plan-driven methods both form part of the planning spectrum and both have a home ground of project characteristics in which each 299 clearly works best, and where the other will have difficulties[15]. He suggests that hybrid approaches that combine both methods are feasible and necessary for projects that combine a mix of agile and plan-driven home ground characteristics. Boehm and Turner [2, 16] have also introduced a method for plan-driven and agile approach from riskbased view. They declare critical level, culture, dynamic, personnel, as five important factors for decision making and describe their method by using of risk-based method. They mention about themselves method: "Our method uses risk analysis and a unified process framework to tailor risk-based processes into an overall development strategy." In 2005, David fits the requirements for CMMI Level 3 by adopting the teachings of W. Edwards Deming and by stretching the MSF for Agile Software Development method [17]. In 2007, Jeff, Carsten and Kent [18] described in their paper that using of CMMI and Scrum simultaneously is not only improve significantly the performance, but also maintain following of CMMI. At this paper we analysis the effect of implementing the agile method (Scrum) on "Systematic CO" that is on level 5 of CMMI. After that by getting help of 12 ways of CMMI level 2 and 3, we show How to help an organization that makes use of agile methods. In the late of 2008, SEI [1] describe in a technical sheet that CMMI and Agile method are incorporate and Higher values of cooperation can be achieved. In Project level, CMMI focuses on project actual performance, while Agile, focuses on Product development projects. In 2009, Mary Sakry, Neil Potter [19] in their paper for comparing Scrum and CMMI, propose that: Scrum is a good implementation for some of the practices in Level 2. Therefore, a group can use Scrum and CMMI together. In 2011, Mariana, Sorin, Constantin, examined three approaches: CMMI, PMI, Agile methods in term of their relevance to the microelectronics projects. For selecting proper approach for these projects, three factors of size, changing level and Ease of Implementation have been implemented [4]. IV. FIVE KEY CRITERIA FOR SELECTING THE APPROPRIATE APPROACH Analyzing of The mentioned Agile and CMMI features, conduct us to defining five important factors for selecting appropriate method on projects. That these factors have been shown in table 1.

Feature Size personnel Culture Flexibility Requirements change degree International Journal of Emerging Technology and Advanced Engineering TABLE І FIVE AGILE AND CMMI KEY FEATURE Five agile and CMMI key feature Agile features Proper for medium and small projects Need to continuous existence of level 2 and 3 specialists. Leading style is participatory and delegated. Agile approach emphasis on cultural cooperation among development team members. In this approach beside believe on every team person; It is expected that the members will do anything for project success. Flexibility considered as a creative and innovative response to the defined changes. Proper unsustainable and changeable projects. CMMI features Proper for large projects Need to level 2 and 3 specialists. During the project, and if the environment is not very dynamic, could work by the less number of personnel.leading Style is obligatory. CMMI culture defines Each person well-defined tasks. This approach shows low levels of trust among the team's developers. Flexibility considered as a predefined response to the defined changes. Proper for too many sustainable and low changeable projects. Since the number of person and team is different in each of agile methods and by considering this matter that the most agile successes are in the small size of projects, so Averaging methods are used to determine the scope of the agile approach. Versus in CMMI methods the best performance is for large projects. Other factors such as person/hour and application size determining could not determine the size of the projects. According the above contents, the size of the project is categorized base on the number of involved people. 1- Small projects: between 1-16 2- Medium size projects: between 17-99 3- Large size projects: more than 100 B. Personnel One of factors in determining whether a new project is proportional with CMMI methods or fit with an agile method is the number of involved people. So in this paper introduced two important factors by the name of person degree and management style and for person degree determination is used of Boehm and Turner research [2, 16]. 1B level people could have good performance in software developments in the sustainable situation. But it may reduce the agile speed for copying with rapid changes. If there is the enough number of level 2 people, the 1A people could act properly in agile teams. Level 2 people could act properly in small projects managements but they need to level 3 people in large projects. The second important factor is project management. According to Hersey and Blanchard theory [20], there are four leading style for life cycle: "telling, selling, participating, and delegating. According to people level and management style factors that have been introduced for involved people in project, three level of A, B and C is used for showing the proper approach in the projects. Level A: express the use of agile approach. Level B: express the use of incorporating of agile and CMMI. Level C: express the use of CMMI. In following the brief description of each of the key factors shown on the table 1, described. A. Size The size of projects is an important factor that is influential on determining agile and CMMI approach. One of key factors on projects size determining, is the number of involved person that should be measured for each one of the above approaches. 300 C. Culture The third factor that can be used for determining the agile approach and CMMI is Culture. Organizational culture can be simply defined as the characteristic or personality. Culture in organizations is important, because it can affect the behavior of individuals and Hardly changes and applies their impact in many obvious ways.

Several factors related to many organizational culture have been studied that can note the trust levels between customers and developers by using trust level that Abdul- Rahman and Hails [21] mentioned. Organizational culture is categorized by Moore [22] base on four organizational cultures that are Education, competence, collaboration, and control. Culture is studied by Boehm and Turner [2, 16, 23] as amount of order in an organization. By attention to the importance of organizational culture and its changing hardly, can note that measuring Cultural readiness is an important factor. Also by considering this matter that designing and implementing a project is costly and time consuming, the comprehension of organizational culture and readiness degree awareness is very important for avoiding loosing organization capitals. According to Turner and Boehm s idea, Cultural fitting is shown in the table 5 for any agile and CMMI approaches by the number between 90 percent (for the best agile) and 10 percent (for the best CMMI). D. Flexibility The fourth factor against three previous factors is flexibility that related to project changing filed for selecting proper method on the projects. Overall could be said that the organization structure should designed flexibility base on its mission, so changing will be possible. Flexibility concept is discussed in many literatures, for instance we can note the below definitions: 1- Ability to cope with defined and undefined changes through changing or fitting affected sections by changes and also maintaining the other unaffected sections [24]. 2- Miller on 1997 [25] notes that organization try to predict changes through flexibility and do transferring, Adaptability and anything that is needed for the organization. The above definition pay to different aspect of flexibility so could be concluded that flexibility shows the organization ability to react on changes. Flexibility in agile approach is defined as ability to respond to unexpected changes. Oosterhout defined flexibility in agile method as ability to sense and respond to inconsistent internal and external changes [26]. While according to SEI technical document [1], because customers ' demands of software is constantly changing. So CMMI approach is weak in responding to changes; so the resulted design base on this model has little flexibility in unstable condition. 301 As mentioned; flexibility has effect on changes in the environment and over time will affect the performance [27] Performance also includes Criteria such as response time and Throughput. Another important factor is the cost of operations that reflect flexibility [28]. It is worth noting that the concepts of efficiency, quality and cost are mixed and linked to each other [29]. Among the above mentioned factors, we use Performance and cost, as the criteria to show the flexibility. Since they can cover effectiveness of implementing lows and cost of implementing rules as well as operations. Following, the key factors that are effective in the measuring degree of flexibility are explained. 1- Throughput: Throughput is the system's ability to perform a certain number of processes in a given unit of time that can be considered as total number of investigated cases per month. Whatever the more case workload that the system can handle, CMMI is more proper for the organization. 2- Operational cost: the cost that been spent during the day. Human resources costs always include main expenditure in process that needs a lot of information and knowledge. 3- Cost of implementing rules: the cost spent on implementing a law or new law. Measuring the cost of implementing rules is the same as operational cost. Whatever the low implementation cost, CMMI is more suitable for organization. 4- Time of Case investigation: it shows performance time of a process and measures the time interval from creation of a case to the end. Whatever the small time, the system has more agility. 5- Time of Implementation laws: the time that spend on implementing new laws. Changing of Laws may be very different from each other. For achieving the average of law implementing, be proposed that the change in law be investigated during a 2 to 3 month time period. The less time the more agility. These five key factors are given from gong and Janssen [30] and edited by the authors. The all described factors about flexibility have been used as organizational flexibility achievement factors. A project manager should allocate a number from 0 to 10 for each above factors base on project characteristics. After that, for gaining flexibility fitting degree with each one of agile and CMMI approach, be act as below:

)І( Standard response of case processing Average time and the average of law implementing be put in X variable in below formula and their value be calculated. Next sum of all factors is obtained. According the above contents, project flexibility is categorized through below category: 1- Low flexibility- less than 20 percent 2- High flexibility more than 30 percent D. Requirement Change degree The fifth effective factor for selecting using method that related to change filed in projects is requirement change degree (RCD). This chart view, gives the very good view to the project manager for selecting the proper approach. The CMMI basis is according to identifying sustainable requirement on initial plan. So during the project, have very little changes readiness acceptation [4]. In other hands, agile methods believe that complete set of requirements at the beginning of the projects may be very undefined and ambiguous. So changing initial condition is possible and this approach has applied a flexible plan. It is ready for new conditions and new requirements supporting. According to described contents, Since the change requirements degree in the project, is an influential factor for choosing selected approach and also by attention to definition Cockburn three stability levels for dynamic by the name of: highly swinger, variable, relatively stable; project requirements be divided to three category that have been shown in the table 2. TABLE ІІ Project requirements Categorize category According to all binding documents of a contract, such as request for proposal, proposal plan, meeting and etc.., all project requirements should be gathered and be scored to each one base on the table 2. Since the number of requirements in different projects is variable, so by assuming n number of requirements and considering table 2, the maximum of requirements will be 2n. So the normalization is done by the below formula: (ІІ) ( ) So the requirements change degree categorize as below: 1- Low changing projects- less than 20 percent of requirements maximum. 2- High changing projects- more than 50 percent of requirements maximum. V. GRAPHICAL VIEW OF FIVE KEY FACTORS OF AGILE AND CMMI Five level of skill levels are as Distinguishing key factors that are influential on determining new project compatibility with Agile or CMMI. These factors have been shown in the figure 1. Project requirements Categorize Category Row Requirements Score 1 2 3 Requirements without change during project implementing Requirements that may change in the future The requirements that surely change during project implementation 0 1 2 FIGURE 1:Graphical view of five key factors of Agile and CMMI According to what was described, One of the main reasons for the failure in agile projects, is sustainability requirements that are not seen in the early in other hand, One of the main reasons for failure in the capability maturity model integrated, is existence of highly variable requirements. So for project change controlling, the two flexibility and requirements change degree are investigated. 302

According the figure 1, whatever a project features are closer to the center of chart, the project has more Proportion with Agile approach and versus whatever far away the center, using of CMMI approach is recommended more. The projects that are suite in the middle of the chart, require incorporation of agile and CMMI approach. In following the agile and CMMI proposal incorporation plan is described. VI. THE PROPOSED APPROACH FOR SELECTING PROJECT PROPER METHOD According to the described contents in the introduction and Boehm and Turner Method [2, 16], the main challenge for facing CMMI is that the model could not apply on low rate changes. On the other hand, agile methods have expanded from small beginning projects to popular organizational application and will face complexity and software development Conformity. Recommended, the project steering committee composed of key managers, consultants and representatives of the leading beneficiaries use the proposed approach in order to determining the best for present project. It is clear that steering committee is at higher level than project management team. According to the changes and their management method, selecting approach is shown as below figure: Phase 2- in this stage, in addition of evaluating results by (figure 1), the appropriation of the present project with CMMI or Agile approach should be determined. Phase 3- if the project could easily fit in the agile or CMMI approach base on figure 1, recommend, it would be in the highest level of proportion. If the project could not fit into any one or has different fields that led to standing in both agile and CMMI area, it should use of incorporation of agile and CMMI approaches. Note: the management team has very important role in project development, so propose they observe project development trend and investigate proposal changes as well as preparing appropriate situation for implementing changes. This matter is very effective in decreasing the cost, delivering time and increasing the software quality. VII. CONCLUSIONS AND FUTURE WORKS In this paper, two Agile and CMMI approaches for selecting software projects appropriate trend from point of incorporation view have been investigated. In this regards five features: project size, personnel, culture, flexibility and requirements change degree have been applied and after that by using a graphical chart, the proper features for selecting appropriate approach was shown. Step 1 - With regard to what was stated, the values of each attribute is calculated. Step 2 - Evaluate the results of Step 1, using the figure 1 Step 3 - Determining how the project is developed FIGURE 2:Steps of selecting appropriate method Phase 1- According to all binding documents of a contract, such as request for proposal, proposal plan, meeting and etc.., and the status of the project is investigated by considering five Agile and CMMI key features that shown in (figure 1). According to the chart was shown, the result was achieved that if the changes and the level of project flexibility were low, CMMI approach was recommended on the other hand, if the project changes and the flexibility level were high, using the agile approach is the best choose for in hand project. The projects that suited in the middle of feature keys need to incorporate approach of CMMI and Agile methods. After that a three staged approach for selecting project proper approach was introduced. The complete description of this incorporation will do in future. The work is performing formation and modeling of a plan during iterations the same as works on agile methods. So in the early development proposal plan, the landscape of plan must be known enough that during development process and coincide with requirements evolution, it will be completed. This matter led to manageable software architecting, decreasing the cost of implementation as well as system maintaining.at present the new approach is studied in a major project. 303

References: International Journal of Emerging Technology and Advanced Engineering [1] Glazer, H., Dalton, J., Anderson, D.J., Konrad, M. and Shrum, S. 2008. CMMI or Agile: Why Not Embrace Both. Publisher: Carnegie Mellon University, Software Engineering Institute. [2] Boehm, B. and R. Turner. 2003. Using Risk to Balance agile and Plan Driven Methods. Computer, IEEE Computer Society. [3] Boehm, B., & Turner, R. 2003. Observations on balancing discipline and agility. Proceedings of the Agile Development Conference. IEEE. doi:10.1109/adc.2003.1231450. [4] Eugenia, M., Sorin and Constantin. 2011. Selecting the appropriate project management process for R&D projects in microelectronics. U.P.B. Sci. Bull., Series C, Vol. 73, Iss. 1. [5] Manifesto for Agile Software Development. 2001. Available: http://agilemanifesto.org. [6] Beck, K. 2000. Extreme Programming Explained: Embrace Change. 1st ed. Addison Wesley Professional. [7] Beck, K. and Andres, C. 2004. Extreme Programming Explained: Embrace Change. 2 nd ed. Addison Wesley Professional. [8] Schwaber, K. and Beedle, M. 2001. Agile Software Development with Scrum. Prentice Hall. [9] Cockburn, A. 2004. Crystal Clear A Human-Powered Methodology for Small Teams. Addison Wesley Professional. [10] Poppendieck, M. and Poppendieck, T. 2003. Lean Software Development: An agile toolkit for software development managers. Addison Wesley. [11] Palmer, S.K. and Felsing, J.M. 2002. A Practical Guide to Feature Driven Development. Prentice Hall. [12] Highsmith, J. 1997. Messy, exciting, and anxiety-ridden: Adaptive software development. In American Programmer. volume10. [13] Stapleton, J. 1997. DSDM: A framework for business centered development. Addison Wesley Professional. [14] CMMI Product Team. 2010. CMMI for Development. Publisher: Carnegie Mellon University, Software Engineering Institute. Version 1.3 [15] Boehm, B. 2002. Get ready for agile methods, with care. IEEE Computer, 35(1), 64-69. doi:10.1109/2.976920. [16] Boehm, B. and Turner, R. 2004. Balancing Agility and Discipline: A Guide for the Perplexed. Addison Wesley. [17] Anderson, D.j. 2005. Stretching Agile to fit CMMI Level 3 - the story of creating MSF for CMMI Process Improvement at Microsoft Corporation. Agile Conference. [18] Sutherland, J., Ruseng Jakobsen, C. and Johnson, K. 2007. Scrum and CMMI Level 5: The Magic Potion for Code Warriors. IEEE Computer. [19] Potter, N. and Sakry, M. 2009. Implementing Scrum (Agile) And CMMI together. The Process Group. Vol. 16 No. 2. [20] Hersey, P. and Blanchard, K. 1996. Management of Organizational Behavior: Utilizing Human Resources. Englewood Cliffs. NJ: Prentice Hall. [21] Abdul Rahman, A. and Hailes, S. 1997. A distributed trust model. Proceedings of the 1997 workshop on new security paradigms - NSPW 97, 48-60. New York, New York, USA: ACM Press. 304 [22] Moore, J. W. and Rada, R. 1996. Organizational Badge Collecting. Communications of the ACM. [23] Boehm, B. and Turner, R. 2003. People Factors in Software Management: Lessons from Comparing Agile and Plan-Driven Methods. The Journal of Defense Software Engineering. [24] Schonenberg, H., Mans, R., Russell, N., Mulyar, N. and vander Aalst, W. 2008. Process Flexibility: A Survey of Contemporary Approaches. Lecture Notes in Business Information Processing, 10. 1865-1356. [25] Miller, D. 1997. The future Organization: A Chameleon in all its glory. In Hesselbein, F., Goldsmith, M. and Beckhard, R. (Eds.). The Organization of the Future. San Francisco: Jossy-Bass Publishers. [26] Oosterhout, V., Waarts, M.P.A. and Heck, E., V. 2006. E. Business Agility: Need, Readiness and Alignment with IT Strategies. In Desouza. K.C. ed. Agile Information Systems: Conceptualization. Construction and Management. Butterworth- Heinemann. [27] Wadhwa, S. and Rao, K.S. 2003. Flexibility and agility for enterprise synchronization: knowledge and Innovation Management Towards Flexibility. Studies in Information and Control, 12 (2). 111-128. [28] Nurcan, S. 2008. A Survey on the Flexibility Requirements Related to Business Processes and Modeling Artifacts 41st Hawaii International Conference on System Sciences. [29] Jansen-Vullers, M.H., Kleingeld, P.A.M., Loosschilder, M.W.N.C., Netjes, M. and Reijers, H.A. 2008. Trade-Offs in the Performance of Workflows Quantifying the Impact of Best Practices in Business Process Management Workshops, Springer, Berlin / Heidelberg. [30] Gong, Y. and Janssen, M. Measuring Process Flexibility and Agility Delft University of Technology Jaffalaan 5. 2628 BX Delft. The Netherland.