Combining CMMI and Agile Methods

Transcription

1 Combining CMMI and Agile Methods Lamis Atia Elshafey Research student Department of Information Technology Faculty of computers and information Cairo University Dr.Galal Hassan Galal-Edeen Associate Professor Head Department of Information Systems Faculty of computers and information Cairo University Abstract Software Organizations are continuously trying to improve their processes to deliver successful software packages on time, with high quality, low budget resulting in a satisfied and delightful customer. Rapid change and increasing software criticality drive successful development and acquisition organizations to balance the agility and discipline of their key processes. Organizations use both Capability Maturity Model (CMMI) and Agile development to improve. However, both approaches have shortcomings and issues that need to be overcome for better results. Although lots of people believe that both approaches are contradictory, we believe that they can work together for better improvement; the challenge here is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses. Keywords: Agile Methods, CMMI, process improvement, customer satisfaction. 1.1 Introduction Organizations begin the journey of process improvement for different reasons, some realize the need for improvement when their products fail after release and must be repaired. Others are driven by mandates and regulatory requirements, such as the need to achieve certification at one of the Capability Maturity Model Integration (CMMI) levels, to show that they comply with the global standards. Significant business issues, such as a lost contract or a new market opportunity, can also draw attention to process improvement. As Siviy claimed the most effective and sustained improvement of any type is done in response to performance needs, not compliance goals. organization's purpose should be to close the gap between actual and desired performance where "desired" is driven by factors such as customer requirements and the needs of the business[1].organizations that attempt to improve often find themselves juggling many approaches for improvement, an approach of selecting and using what seems best from various system can be very helpful here, all approaches selected by an organization can be implemented in an integrated fashion, to try getting the best of each of them that fits their needs, and meets business objectives. One approach for improvement is CMMI which presents the best practice standard for software development process control and quality improvement, it promises predictability, stability, and high assurance. Anther approach is agile development methods that promise higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements. However, both approaches have shortcomings and issues that need to be faced; numerous questions have arisen around their integration. The challenge here is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses. An increasing number of researchers have attempted to discuss organizations' successful integration of CMMI and Agile Methods. These organizations have found ways to find common grounds between both improvement initiatives and overcome the perception that the initiatives are competitors and are trying to effectively apply agile methods and CMMI to better achieve their organizational missions. We have scanned the literature for research that discussed the compatibility of CMMI and Agile methods and how they can work together into a seamless framework. Through analyzing some of the major literature available on both of them, we abstracted the common grounds and contradictions, showed how they can complement each other. We are not aiming to present an exhaustive list of all integration attempts, but rather reflective of patterns observed. Through the paper we will give a quick overview on CMMI in section (1.2), then we will introduce Agile INFOS2008, March 27-29, 2008 Cairo-Egypt 2008 Faculty of Computers & Information-Cairo University SE-27

2 methods in section (1.3), in section (1.4) we will be discussing the common grounds and contradictions between both of them, then we will propose a strategy in which both initiatives can be integrated in section (1.5) 1.2 Overview of CMMI The Software Engineering Institute's (SEI) Capability Maturity Model Integration (CMMI) is a model for organizational maturity and continuous improvement of capability intended to help a business become more effective through the improved quality and reliability of its operations. It is a non-prescriptive collection of best practices that infuse quality into products through the use of better processes throughout the entire product life cycle; it addresses practices that cover the product's life cycle from conception through delivery and maintenance [2]. CMMI model developed by a group of industry, government, and SEI representatives, and is made up of best-of-the-best processes gleaned from multiple disciplines integrated together like (the Software Engineering Institute's Capability Maturity Model for Software (SW- CMM), which focuses on improving software, and the Electronic Industries Alliance's (EIA's), Systems Engineering Capability Model (SECM), which focuses on systems engineering). CMMI provides guidance in specific process areas by providing goals and a set of expected practices needed to meet those goals. Höggerl explained that CMMI contains 25 process areas that cover the systems and software engineering disciplines and cover integrated product and process development (IPPD), these 25 process areas are divided between 5 maturity levels(initial, managed, defined, quantitatively managed, optimizing). To satisfy a process area, certain unique characteristics must be present. These characteristics are described in what the CMMI calls specific goals. The model also includes generic goals, which are goals that appear in multiple process areas. The activities that are expected to result in the achievement of specific goals are called specific practices, while generic practices appear in multiple process areas and are considered important in achieving associated generic goals. CMMI Product Team 2006 in CMMI V1.2 technical report, removed 3 process areas from maturity level 3 (Defined) to make the total number of process area in this new version 22 and updated 7 other process areas. The three process areas that were removed in version 1.2 are Integrated teaming, Integrated supplier management and Organizational environment for integration [2]. CMMI provides a way to assess the state of an organization s ability to build software in a repeatable, predictable and a stable way. In order to reach a certain level, an organization has to fulfill all process areas of that level as well as those of lower levels; a process area is a summary of all requirements for a certain topic. CMMI guides you by showing what needs to be done in each process area but not how to do it, it is also about process management, not development processes in specific so it gives the upper guidelines for the whole process improvement Issues in adapting CMMI As any other methodology CMMI have critics and issues that was faced during CMMI adoption. the most common issues discussed in the online encyclopedia Wikipedia where as follows[3]: CMMI seems to favor large and bureaucratic organizations This point of attack is most likely caused by the fact that the SEI was sponsored by the U.S.DoD. Governmental organizations are known for being large, bureaucratic bodies. If the organizations deploying CMMI are large enough, they employ a team of auditors reporting their results directly to the executive level. The use of auditors and executive reports may influence the entire IT organization to focus on perfectly completed forms and documents rather than application development, client needs or the marketplace. CMMI's exclusive focus on the process. The second point of attack is that CMMI concentrates on the process as a factor in software development, sparing out people and technology. It promotes the process over all other issues like human cognitive, organizational and cultural factors. CMMI is rigid and not flexible to rapid changes. This point of attack is that CMMI depend on a very early full defined and documented requirements upon which a detailed design is build, any changes that comes from the customer leads to lots of change not easily accepted. CMMI does not describe how to create an effective software development organization. CMMI contains behaviors or best practices that successful projects have demonstrated, it doesn't tell organizations how to improve their software development. Following CMMIframework or guidelines is not a guarantee that a project will be successful; however it can increase a project's chances of being successful by following the best practice of other projects. SE-28

3 We conclude the discussion of issues with a complete quote of Bamberger, one of the key authors of the CMM, in The Essence of the Capability Maturity Model "The CMM wasn't intended to be all things to all people or cover all possible aspects of software and system development. The view that guided me during my many years' work as a CMM author, contributor, and reviewer was that the CMM was intended to provide one set of guidelines for managing software development projects and making improvements over time. This set of guidelines was based on best practices, software engineering discipline, real-world experience, and extrapolation from other industries. And, most importantly, this set of guidelines was just that guidelines not requirements or a checklist of must do items; the guidelines were intended to be interpreted, tailored, and applied within the culture and context of each unique organization."[4]. 1.3 Agile Methods As an answer to the challenges of modern software development which in many cases can not be dealt with by traditional processes, different lightweight approaches have been established called "Agile Methods". Nerur and Balijepally defined agile methods as people-centric, that recognize the value skilled people and their relationships bring to software development. They also explained in their paper that agile methods focus on providing high customer satisfaction through three principles: quick delivery of quality software; active participation of concerned stakeholders; and creating and acting effectively toward changes. They added that big upfront designs, plans and extensive documentation are of little value to practitioners of agile methods. The important features of agile methods as they see are evolutionary delivery through short iterative cycles of planning, action, intense collaboration, selforganizing teams, and a high degree of developer maturity [5] Agile Manifesto The Agile Movement in software industry saw the light of day with Agile software development Manifesto published by a group of software practitioners and consultant in 2001[6]. Agile modeling recognizes that the values of agile development are keys to your being effective. The values honored by the agilest are presented in the Manifesto for agile software development where agile manifesto is a document developed and signed by a group of agile proponents known as the Agile Alliance. "We are uncovering better ways of developing software by doing it and helping others do 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 in the left more."[7] Agile Principles As the Agile Manifesto site states, the characteristics of agile methods are elaborately defined in the twelve principles behind the agile manifesto [7]: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer s competitive advantage. 3. Deliver working software frequently, from couple of weeks to a couple of months, with preference to the shorter time scale. 4. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the ob done. 6. The most efficient and effective method of conveying information to and within a development team is faceto-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhance agility. 10. Simplicity the art of maximizing the amount of work not done is essential. 11. The best architectures, requirements, and designs emerge from self-organizing team 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile methods encourage programmers to drop their heavyweight process chains, embrace change, and escape into agility. Advocated methods have short cycle times, close customer involvement, and an adaptive rather than predictive mind set Misusing Agility Lots of people misuse what agility means, they think that it is not doing everything that they hate in process driven approach as an example of agile misuse [8]: SE-29

4 "Extreme programming expert Bob Martin said at 2001 XP Universe conference that he ran into someone who said his organization was using XP. Martin asked him how the pair programming was viewed, and the reply was, we don t do that. Martin asked how refactoring was working out, and the reply was, we don t do that. Martin asked how well the planning game was working, and the reply was, we don t do that. Well, Martin asked Then what are you doing? We don t document anything! was the answer. " In general, agile methods are very light processes that imply short iterative cycles; actively involves users to establish, prioritize, and verify requirements; and rely on tacit knowledge with in a team as opposed to documentation. Truly agile method must include all of the following attributes: 1. Iterative: several cycles. 2. Incremental: not deliver the entire product at once. 3. Emergence: processes, principles, work structures are recognized during the project rather than predetermined. Anything else is lightly defined process, although such processes can exhibit considerable agility Existing Agile Methods There are a growing number of agile methods. The core set of these includes: Extreme Programming (Beck 1999b), Scrum (Schwaber 1995; Schwaber and Beedle 2002), Crystal family of methods (Cockburn 2002a), Feature Driven Development (Palmer and Flesing 2002), The Rational Unified Process (Kruchten 1996; Kruchten 2000), Dynamic System Development Method (Stapleton 1997), Adaptive Software Development (Highsmith 2000) and Open Source Software development (e.g., O Reilly 1999) [6] Agile Methods Practices Agile Practices are the concrete activities and practical techniques used to develop and manage software projects in a manner consistent with the Agile Principles [9]. Each agile method have some practices of its own that are used while adoption of this method, some of these practices are similar others may have different conventions but same purpose, others totally differs, Sidky took an approach to identify a list of all the agile practices The approach was to collect all agile practices used by current agile development methods, the collection process weight includes grouping similar practices together, the result was a set of 40 different agile practices. Sidky said that this compilation provides a starting point, but does not by any means limit agile practices to this list only [9]. Below listed some of the most common practice from those 40 conducted by Sidky Self organizing teams Frequent intensive communication Test Driven Development Pair Programming Re-factoring and Continuous improvement No big design up front (BDUF) Unit Tests Coding standards Continuous integration Smaller and more frequent releases Customer immediately accessible(on-site Customer) Collaborative teams and Empowered and motivated teams Collaborative planning Daily progress tracking meetings User Stories Software configuration management Client driven iterations Continuous customer satisfaction feedback Each of these practices when used in software development moves us a step forward to being agile. Agile Practices either replace an existing non agile practices or redefine or complement them Issues in Agile Methods Some of the most common issues that organization faces when adopting agile methods as Barnett discussed her survey were as follows[10]: Lack of discipline. Lack of structure and necessary documentation. Only works with development process. Incorporates insufficient software design. Requires too much cultural change to adopt. Impossible to develop realistic estimates of all work effort needed, as at the beginning of the project no one knows the entire scope/requirements on the other hand estimates precision is increased through a short planning iterations or phases. Lack of up-front planning. Lack of predictability. It requires highly qualified developers. 1.7 CMMI and Agile Methods Compared CMMI is a widely known appraisal approach for determining organizational maturity and process capability, it provides predictability, stability, and high assurance through discipline, most organizations now depend on CMMI to build the needed improvement SE-30

5 framework for their organization. On the other hand the agile development methods are a light weight development approach that allow for creativity and responsiveness to changing conditions by emphasizing customer participation, quick reaction to requirements changes and continuous releases. However, both approaches have shortcomings that need to be addressed [11] [12]. Although lots of people who looks from an upper point of view believe that both of them contradict, we claims that they can work together to support and complement each other, the challenge here is to balance the two approaches to take advantage of their strengths and compensate for their weaknesses overcoming the perception that they are competitors or mutually exclusive alternatives. The table below compare CMMI and agile methods believes and core values. Main Goal Core Values People Characteristics Communication Knowledge Management Focus Customer Trust Characteristics CMMI Measure and improve organization's processes including software development to produce quality software and gain customer satisfaction Better Process Leads to a Better Product Disciplined, Follow Rules, Risk Averse Can be done through documents or mails or meetings and taking meeting minutes Process Assets, Standardization Business Focus internal, rules) Predictability, Stability In Process Infrastructure Iterative, Incremental, Rapid Changes, Barely enough documents 1.8 CMMI Process Areas and Agile Practices Analysis Now we need to do a deeper analysis for both CMMI process areas with agile practices and principles, the approach taking in this analysis will be determining which process area can benefit from the agile practices, in other words which agile practice can complement, enhance or accelerate the implementation of a certain process area. Following this approach we will categorize the 22 process areas into one of 3 categories based on the following rating: (S): when most parts of the process area is supported by multiple agile Agile Methods Improve software development processes to produce a high quality software product with in shorter development times, fewer defects Customer Responses, Minimal Overhead, Requirements Refinement Comfortable, Creative, Risk Takers Face to face communication is the best way to communicate People Business Focus (External, Innovation) Performance, Speed Working SW, Participants Procedural, Extensive planning, Careful changes, Heavy documents practices that will help enhance or accelerate its implementation. Partially (PS): when only a small part of the process area is covered by an agile practice, it can't help implementing this process area on its own other non agile practices will be needed. Not (NS): when process area is not addressed by agile methods at all. Taking into consideration that CMMI present the guidelines, upper framework of process improvement and answer the question of what to do to improve, while agile answers the question of how to do it[12][14][18][19]. We analyzed every process area (specific goals and specific practices if needed) in details showing which agile practice can fit into this process area and under which category, agile practices used in the analysis SE-31

6 will be written in bold and between double quotes. PA1: Requirements Management (S) SG 1: Manage Requirements Understanding of the requirements (SP1.1) can be enhanced by 2 agile practices which are "Frequent intensive communication" between team members and the customer also by having "Customer immediately accessible (On-site Customer)" who is available all the time to be asked for any ambiguous requirements or details needed. Theproject participants commitment to the requirements (SP1.2) is obtained by involving team members in customer communication. Changes of requirements (SP1.3) is fully welcomed and supported by agile methods as one of the agiles' principles is "Welcome changing requirements". While maintaining traceability of requirements (SP1.4) is not a goal of agile methods, they don't do so, as agile concentrates on getting requirements just enough to deliver quality working software to customers, they believe documentation does not deliver value to the customer, they don't care so much for keeping or tracking requirements for future changes, agile uses user stories written on cards for requirements and this is one of the most common critics in agile methods. Inconsistencies between project work and requirements (SP1.5) can be detected by "Continuous customer feedback", and "unit tests" practices, so agile practices and principles can complement 4 out of 5 specific practices in the requirements management process area. PA2: Project planning (S) SG1. Establish estimates Although in agile methods it is impossible to develop realistic estimates of all work effort needed at the beginning of the project, as no one knows the entire scope, but the agile practice "smaller and more frequent releases" increases estimates precision due to short iterations and smaller phases scope. SG2. Develop a project plan Agile methods can help produce more reliable project schedule, budget and plan (SP2.1, SP2.7), when plans are applied to small releases or phases, using "smaller and more frequent releases" practice, as smaller scope help produce better plans and schedules for each iteration and then iteration plans evolve throughout the project phases. Therefore long term plans remain vague and only short term plans are detailed. Also small iterations helps to identify risks easier (SP2.2), better resource allocation (SP2.4), better identification for needed skills for a certain phase (SP2.5). The "Collaborative planning" agile practice encourages the involvement of all relevant stakeholders in the planning phase (SP2.6). Agile methods doesn't plan for data management so (SP2.3) in this process area is not covered with agile. SG3. Obtain commitment to the plan The "Collaborative planning" agile practice as we said before encourages the involvement of all relevant stakeholders in the planning phase which increase the commitment to the iteration plans through the high involvement and responsibility it offers. PA3: Project monitoring and control (S) SG1. Monitor project against plan Schedule and estimates are monitored through the whole project cycle. 3 agile practices ensure this monitoring is done, those practices are "Self organizing teams" that consist of frequent regular status meetings, face-to-face, reporting to the other team members' accomplishments, work commitments and obstacles, "Daily progress tracking meetings" where the team must stay informed on a daily basis regarding the status of the iteration against plan and "Frequent intensive communication between team members". Project s progress is measured in agile methods using the above 3 practices with in each iteration. Also "smaller and more frequent releases" make it easier to monitor the project against the plan. Only (SP1.4) monitor data management is not covered by any agile practice. SG2. Manage corrective action to closure Issues that demand corrective actions are informally collected and analyzed in the "Daily progress tracking meetings" and "Frequent intensive communication between team members" (SP2.1, SP2.2) also at each new iteration of "smaller and more frequent releases", it offers a good opportunity to make corrective actions to issues in previous iterations. PA4: Supplier agreement management (NS) This process area is not addressed by agile methods at all, as it is not concerned with the SE-32

7 development process and agile only addresses development processes. PA5: Measurement and analysis (PS) SG1. Align measurement and analysis activities / SG2. Provide measurement results The only measurement objective in agile is progress control. Agile methods provide no specific guidelines for measuring, it just need to measure to keep track of the project's progress through the "Daily progress tracking meetings". The measurement data is obtained through "Frequent intensive communication between team members". So there is no agile practice that can complement the measurement and analysis as needed in CMMI. PA6: Process and product quality assurance (NS) SG1. Objectively evaluate processes and work products / SG2. Provide objective insight. This process area objectively evaluates the designated performed processes against the applicable process descriptions, standards, and procedures, no agile practices can help implementing this area. PA7: Configuration management (PS) SG1. Establish baselines Agile practice "software configuration management" states the importance to use CM tools to control different versions and iterations as continuous integration relies heavily on it. So both CM process area and agile demand the use of CM tools, but there is no add from agile to this process area. SG2. Track and control changes / SG3. Establish integrity Changes are controlled and tracked through various agile practices like "pair programming", "unit tests" and " continuous customer feedback" those practices in addition to the normal tracking and control through documentation can enhance the implementation of these specific goals. PA8: Requirements development (PS) SG1. Develop customer requirements/ SG2. Develop product requirements Documentation in agile is one of its most known issues, but agile methods have its own believes, it discourage writing unnecessary requirements documents and only uses story cards and a customer onsite to give the required requirements. Two main reasons for this, first there is cost associated with developing and maintaining documentation and second reason is that documentation does not deliver value to the customer, while working software does. Therefore, minimal documentation is promoted in agile development which came in the contrary to documentation in CMMI, as it needs every thing fully documented as to be easily tracked later on. SG3. Analyze and validate requirements Agile practices "continuous customer feedback" ensures what have been written in requirements is true, "unit tests" and "test driven development" help to understand the requirements more and validate it. In addition, "acceptance of changing requirements" and "small iterations" allow constant analysis and validation of requirements. However there is no in depth requirements analysis up front, it is done per iteration. PA9: Technical solution (S) SG1. Select product-component solutions Alternative solutions are explored at the beginning of the project through "prototypes and customer feedback" and later on through "re-factoring" and "iterative development" SG2. Develop the design Agile practice "no big design up front" helps the system to be more flexible and to accept changes easily, by keeping the cost of change low which means keeping the system as simple as possible. Design is done per each iteration and is updated iteratively also to minimize changes cost. SG3. Implement the product design This SG is the one that can most benefit from agile practices as it is concerned with the implementation phase while agile focus on the improvement of the development so it has a variety of implementation practices like "refactoring", "coding standards", "pair programming", "test driven development" and "Continuous improvement" all those practices can help enhance the implementation phase and ensures better quality. SE-33

8 PA10: Product integration (PS) Agile methods are always in need for "continuous integration" as it contains multiple iterations and since integration steps are performed very often, a thorough preparation is critical, and then integration takes place. Here there is no adding from agile practice to the process area as this was normally done. PA11: Verification (S) SG1. Prepare for verification Verification ensures that selected products meet their specified requirements. Using the agile practices "test driven development" and "unit tests" will enhance the verification process as those practices increase the probability of meeting the verified work to the specified requirements. SG2. Perform peer reviews / SG3. Verify selected work products Peer reviews are implicitly part of agile methods through "Pair programming" and the principle of "collective code ownership" so pair programming may enhance the peer review process. PA12: Validation (S) SG1. Prepare for validation/ SG2.Validate product or product components The purpose of Validation is to demonstrate that a product fulfills its intended use as required by the customer; this is greatly achieved by the agile practices "continuous. customer feedback", "customer immediately accessible" and "Frequent releases". All of these practices guarantee with the customer involvement that the product is valid. PA13: Organizational process focus (NS) This process area isn t addressed by agile methods at all because it applies to the organizational level while agile applies to a project level. PA14: Organizational process definition (NS) Also this process area isn t addressed or supported by agile methods at all as it applies to the organizational level while agile applies to a project level. PA15: Organizational training (PS) The purpose of organizational training is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently, agile practices may help a little here by "Pair programming" practice. PA16: Integrated project management (PS) SG1. Use the project s defined process Agile methods don't introduce a defined process for a project as a whole, it only define practices for the development project. SG2. Coordinate and collaborate with relevant stakeholders Agile practice "Collaborative teams" integrates and coordinate developers, customer, testers, and management, all relevant stakeholders. SG3. Use the project s shared vision for IPPD/ SG4. Organize integrated teams for IPPD Agile practice "Collaborative teams" contribute a lot to the project members integration and close collaboration. This and the "intensive communication" within the team help to establish a shared vision. PA17: Risk management (S) Agile practices "self organizing teams" and "frequent intensive communication" both helps identifying and mitigating risks through intensive and frequent communication between all team members. PA18: Integrated teaming (this process area was removed in CMMI V1.2) PA19: Integrated supplier management (this process area was removed in CMMI V1.2) PA20: Decision analysis and resolution (NS) The purpose of Decision Analysis and Resolution is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria, agile methods don't address this area at all, it identify and evaluate alternatives decisions informally. PA21: Organizational environment for integration (this process area was removed in CMMI V1.2) SE-34

9 PA22: Organizational process performance (NS) This process area isn t addressed by agile methods, because it applies to the organizational level while agile applies to a project level. Agile focuses on individuals than on issues that are as process oriented as this process area. PA23: Quantitative project management (NS) Agile methods don't have any statistical focus. Therefore, agile practices can add nothing here. PA24: Organizational innovation and deployment (NS) Again this process area is related to organizational process focus, a process area that is out of the agile methods scope. PA25: Causal analysis and resolution (NS) Agile methods neither measure defects nor analyze its cause and therefore don't address cause of effect; this area also is not covered. Based on the above analysis we found that we can enhance or accelerate the implementation of 7 process areas using the agile practices while implementing those process areas, other 6 process areas can partially benefits from using agile practices during implementation but they still needs other non agile or different practices to implement all the process area goals cause some of the goals are not satisfied by the agile practices. Which leaves us with 13 out of 22 process area, the last 9 process areas, agile practices have nothing to do with them at all, as they may be related to organizational level or supplier agreement which are both out of the agile methods scope. The chart below shows the percentage for the analysis. Not 41% Partially 27% 32% Partialy Not Figure 1: CMMI process areas that can be enhanced by agile practices and principles 1.9 Integrating CMMI and Agile Methods Based on the analysis conducted above the approach taken for integration will be illustrated but first lets scan the previous integration attempts from literature and see the approaches used. Several authors have discussed the compatibility of CMMI and agile methods. Dalton compared both agile and CMMI from a high level perspective and showed where they can meet [13], Dutton and Fritzsche also used a process area evaluation approach in their papers where they analyzed the coverage of process areas by agile methods [12] [14], while Andreson the program manager in Microsoft wrote about the story of creating MSF for process improvement at Microsoft where they stretched agile methods to fit and cover CMMI level 3[15], also Turner and Jain [16] show how CMMI can help to successfully implement agile methods, last but not least Paulk discussed the XP satisfaction of key process areas, given the appropriate environment[17]. Each of these authors tried to discuss the integration from a different perspective, sometimes times trying to fit agile into CMMI and vise-versa and other time trying to extend agile to meet CMMI The Proposed Integration Approach The approach we are proposing here for integration depends on the concept that we don't have to use all agile practices, we SE-35

10 choose CMMI as the guideline and upper framework for improvement then tried to overcome CMMI issues by introducing agile practices that will help enhance or accelerate CMMI process areas and can fit agile practices into them. We claim that CMMI identifies what activities are expected (industry best practice) answering the what to do question, it offers an integrating framework and institutionalization features and discipline that are lacking in agile methods, it also covers the whole processes in the organization not only the development process while agile methods identifies how development activities might be done or improved (more efficient, more effective), it provides specific strategies, methods, and techniques for building software, answering the how to do question. CMMI evaluates an organization as a whole and its development processes. In contrast, an agile method is one individual development process. Thus, the concepts are not similar so they are not competitors. Their focus is different, but still they have interrelations. Paulk summarized that CMM/CMMI is a method for software management whereas agile approaches are methods for software development. They not only can coexist, but they even support each other [17]. The proposed integration strategy as we stated before is to use agile participles and methods to enhance or accelerate the implementation of CMMI process areas. The above analysis showed we have 7 process areas that can benefits from such integration based on the fact that agile methods can help achieve most of their specific goals and practices. Mean while we will still be working under the framework of CMMI for the other 6 process areas that agile methods don't fulfill their implementation alone other non-agile practices needs to be used, an example of this is "measurements and analysis" process area where agile can't participate much as it only measures the project status progress through daily progress tracking meeting while other measurements still needs to be covered by other practices. Finally there are 9 organizational and other related to supplier management process areas that are not supported by agile methods at all. The important part in doing this integration is that organizations have to keep in mind their needs as a first priority and start customizing their process based on those needs, the goal is not to claim the they use agile methods but is to take what ever principles from them that will help improve their processes, so they don't have to fully implement all agile aspects as they was written literally, we can select and extend them to fulfill our needs as was shown above. The next figure shows the abstract or high level relation between CMMI and agile methods then. The table below summarizes how the integration can be done by showing each process areas with the agile practices that supports it as was conducted from the analysis. Provides flexibility and focus on human and technology CMMI Agile Methods Provides a discipline and structured framework Figure 2: CMMI and Agile high level influence on each other SE-36

11 Process Area Category Agile practice supporting process area Requirements Management Frequent intensive communication Unit tests Customer immediately accessible Welcome changing requirements Continuous customer feedback Project planning Smaller & frequent releases Collaborative planning Project monitoring and control Self organizing teams Daily progress tracking meetings Frequent intensive communication Smaller & frequent releases Supplier agreement management Not Measurement and analysis Partially Daily progress tracking meetings Frequent intensive communication Process and product quality assurance Not Configuration management Partially Software configuration management Pair programming Continuous customer feedback Requirements development Partially Unit tests Welcome changing requirements Continuous customer feedback Test driven development Smaller & frequent releases Technical solution Prototypes and customer feedback Re-factoring Iterative development No big design up front design Coding standards Pair programming Test driven development Continuous improvement Product integration Partially Continuous integration Verification Test driven development Unit tests Pair programming Collective code ownership Validation Continuous customer feedback Smaller & frequent releases Customer immediately accessible Organizational process focus Not Organizational process definition Not Organizational training Partially Pair Programming Integrated project management Partially Frequent intensive communication Collaborative teams Risk management Frequent intensive communication Self organizing teams Decision analysis and resolution Not Organizational process performance Not Quantitative project management Not Organizational innovation and deployment Not Causal analysis and resolution Not SE-37

12 As a result of such integration some of the discussed CMMI drawbacks were avoided by agile methods and vise versa which helped in building a stronger framework, some of the other benefits are listed below: CMMI would provide a discipline framework for implementing a more robust agile method like in development requirements process area. CMMI will cover the organizational and supplier manager aspects that are not addressed at all in agile methods. The rapid cycle time associated with agile methods enhances and enables quick development and deployment of CMMI processes. Integration leads to a process that focuses on both processes and human aspects. CMMI tends to reduce risk in agile development. Value of fast as possible production, work flow, and minimal work in progress to produce working software. Testing and continuous integration as essential drivers for implementation of better quality products. Rework reduction through testing and pair development as cost-effective options to inspection and review, also being flexible and accept customer changes. Recognition and effective use of advanced skill sets. 1.7 Conclusions Multiple models can be integrated together targeting a better way for improvement that fits organizations needs, CMMI and Agile methods can be blended together to complement each other, benefit from combining the strength point in each approach and compensate their weak points resulting in a stronger framework that can accelerate process improvement. CMMI evaluates an organization as a whole and its development processes, providing a stable, disciplined and predicted processes but still have some weak points need to be addressed, also an agile method is one individual development process, that provides higher customer satisfaction, lower defect rates, faster development times and a solution to rapidly changing requirements, but still with some issues. Both approaches are not competitors and can work together to overcome the drawbacks of each other. The integration strategy proposed above can fit the agile methods inside the CMMI framework in the process areas that supports this and benefits from this integration to overcome some of both approaches weakness, and combining their strong points in one framework. 1.8 References [1] J. Siviy, Penn, M. Lynn & Harper, Erin "Relationships Between CMMI and Six Sigma," in CMU/SEI-2005-TN-005, [2] CMMI Product Team, "CMMI for Development, Version 1.2," Software Engineering Institute, Technical Report:CMU/SEI-2006-TR-008, August [3] Wekipedia, "Capapbility Maturity Model Integration" Wekipedia encyclopedia Retrieved 25 February 2008 from [4] J. Bamberger, "Essence of the Capability Maturity Model," IEEE Computer Society, [5] S. Nerur and V. a. Balijepally, "Theoretical reflections on agile development methodologies," COMMUNICATIONS OF THE ACM, vol. 50, pp , March [6] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, Agile Software Development Methods Review and Analysis, 1 ed. vol. 1: Espoo, [7] AgileManifesto, Manifesto for Agile Software Development Retrieved January 2008 from / [8] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, 1 ed. Boston: Addison Wesley, [9] A. Sidky, "A Structured Approach to Adopting Agile Practices:The Agile Adoption Framework." PHD Thesis Blacksburg: Virginia polytechnic institute and state university, [10] L. Barnett, "Agile Survey Results: Widespread Adoption, Emphasis on Productivity and Quality," Agile journal, Wednesday, 08 August [11] M. Pikkarainen and A. Mäntyniemi, "An Approach for Using CMMI in Agile Software Development Assessments: Experiences from Three Case Studies," in SPICE 2006 Luxemburg, [12] J. L. Dutton and R. S. McCabe, "Agile/ Lean Development and CMMI," Sysytem and Software Consortium (SEPG) 9 March [13] J. Dalton, "Agile CMMI Process Innovation at the speed of life," Software Engineering Institute March [14] M. Fritzsche and P. Keil, "Agile Methods and CMMI:Compatibility or Conflict?," e-informatica Software Engineering Journal, vol. 1, [15] D. J. Anderson, "Stretching Agile to fit CMMI Level 3," in Agile Development Conforance (ADC'05) Denver, SE-38

13 [16] R. Turner and A. Jain. Agile Meets CMMI: Culture Clash or Common Cause? In XP/Agile Universe, pages , [17] M. C. Paulk, "Extreme Programming from a CMM Perspective", IEEE, [18] A. D. Belchior, F. Furtado, A. S. Marçal, and B. C. C. Freitas, "Mapping CMMI Project Management Process Areas to SCRUM Practices," in 31st Annual Software Engineering Workshop (SEW) Baltimore, [19] J. Sutherland, C. R. Jakobsen, and K. Johnson, "Scrum and CMMI Level 5: The Magic Potion for Code Warriors," IEEE, pp , SE-39