Mapping CMMI to Disciplined Agile

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
  • Retrospectives
  • Measured Improvement
  • Defect Analysis (when the change is coming from Parallel Independent Testing or Production)
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
  • Automated dashboards (development/IT intelligence)
  • Explicit support for Goal Question Metric (GQM) approach
  • Teams run regular demos to stakeholders
  • Team Lead and Product Owner report out to their respective reporting chains
 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
  • The DA philosophy of enterprise awareness promotes a culture that accepts help and guidance from outside of the team
  • Explicit support for the IT Governance process blade
  • Governance activities are built into all process blades
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
  • Explicit support for many technical practices such as continuous integration (CI), parallel independent testing, regression testing, initial architecture, architecture spikes, continuous delivery and many more
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
  • See the Develop Initial Release Planning process goal
  • Evolutionary planning is supported throughout construction via iteration planning and updating of release plan as part of iteration wrap up
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
  • Support for automated dashboards (development/IT intelligence)
  • The Move Closer to a Deployable Release process goal suggests many quality-oriented practices such as continuous integration (CI), regression testing, and non-solo collaborative work
Very formal, bureaucratic description
Quantitative Project Management (QPM). Quantitatively manage the project to achieve the project’s established quality and process performance objectives. 4
  • Support for automated dashboards (development/IT intelligence)
  • Light-weight delivery governance is built right into the framework via active stakeholder participation, transparency. lightweight risk-based milestones, demos, and many more
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