Yes, CMMI and agile are potentially compatible, and it is possible to apply Disciplined Agile and CMMI together. Certainly it is a very good idea to adopt disciplined agile strategies into an existing CMMI environment, although the opposite direction, applying CMMI into an existing Disciplined Agile environment, is very questionable in our opinion.
The following table shows how the process areas of Capability Maturity Model Integrated (CMMI) for Development (CMMI-Dev) can be supported by aspects of the Disciplined Agile Framework.
| CMMI Process Area | CMMI
Level |
DA Implementation | Concerns with CMMI |
| Causal Analysis and Resolution (CAR). Identify causes of selected outcomes and take action to improve process performance. | 5 |
|
CMMI description is very heavy, they’re comingling defect analysis and process improvement |
| Configuration Management (CM). Establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits. | 2 |
|
Tends to be heavy handed in the description, and as a result likely goes beyond just good enough for the given context |
| Decision Analysis and Resolution (DAR). Analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria. | 3 |
|
This PA has an incredibly heavy-weight description that doesn’t reflect agile philosophies at all |
| Integrated Project Management (IPM). Establish and manage the project and the involvement of relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes. | 3 |
|
This PA assumes project teams whereas DA also supports, and encourages, stable product teams instead |
| Measurement and Analysis (MA). Develop and sustain a measurement capability used to support management information needs. | 2 |
|
None, other than keeping it as lightweight and practical as possible |
| Organizational Process Definition (OPD). Establish and maintain a usable set of organizational process assets, work environment standards, and rules and guidelines for teams. | 3 |
|
None. It is an underlying assumption of DA this this will happen, although it is kept as lightweight as appropriate |
| Organizational Process Focus (OPF) Plan, implement, and deploy organizational process improvements based on a thorough understanding of current strengths and weaknesses of the organization’s processes and process assets. | 3 |
|
This PA comes off as a bit heavy in the CMMI-Dev documentation. DA’s approach is far more collaborative, flexible, and evolutionary |
| Organizational Performance Management (OPM). Proactively manage the organization’s performance to meet its business objectives. | 5 |
|
None, other than this PA comes to late for those organizations taking a staged approach to CMMI |
| Organizational Process Performance (OPP). Establish and maintain a quantitative understanding of the performance of selected processes in the organization’s set of standard processes in support of achieving quality and process performance objectives, and to provide process performance data, baselines, and models to quantitatively manage the organization’s projects. | 4 |
|
This PA comes off as a bit heavy in the CMMI-Dev documentation |
| Organizational Training (OT). Develop skills and knowledge of people so they can perform their roles effectively and efficiently. | 3 |
|
None |
| Product Integration (PI). Assemble the product from the product components, ensure that the product, as integrated, behaves properly (i.e., possesses the required functionality and quality attributes), and deliver the product. | 3 |
|
None |
| Project Monitoring and Control (PMC). Provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan. | 2 |
|
Assumes projects and appears to imply detailed up front planning |
| Project Planning (PP). Establish and maintain plans that define project activities. | 2 |
|
Assumes projects and appears to imply detailed up front planning |
| Process and Product Quality Assurance (PPQA). Provide staff and management with objective insight into processes and associated work products. | 2 |
|
Very formal, bureaucratic description |
| Quantitative Project Management (QPM). Quantitatively manage the project to achieve the project’s established quality and process performance objectives. | 4 |
|
Assumes projects, very heavy description |
| Requirements Development (RD). Elicit, analyze, and establish customer, product, and product component requirements. | 3 |
|
Very heavy description, DA prefers a very light, evolutionary approach |
| Requirements Management (RM). Manage requirements of the project’s products and product components and to ensure alignment between those requirements and the project’s plans and work products. | 2 |
|
Heavy, assumes bi-directional traceability is desired (whereas in practice it is only sometimes needed) |
| Risk Management (RSKM). Identify potential problems before they occur so that risk handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives. | 3 |
|
Assumes projects and appears to promote a heavy approach to risk management |
| Supplier Agreement Management (SAM). Manage the acquisition of products and services from suppliers. | 2 |
|
None |
| Technical Solution (TS). Select, design, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product related lifecycle processes either singly or in combination as appropriate. | 3 |
|
Appears to promote an overly heavy approach |
| Validation (VAL). Demonstrate that a product or product component fulfills its intended use when placed in its intended environment. | 3 |
|
None |
| Verification (VER). Ensure that selected work products meet their specified requirements. | 3 |
|
Appears to promote an overly heavy approach |