近年来，敏捷开发方法能够更好地适应现代软件开发，逐渐发展成为一种主流开发方法，也正在改变着软件开发过程。然而，敏捷开发方法常常被认为同CMMI过程无法共存，因为CMMI被看做是以规格化方法控制软件开发过程。
2008年，Hillel Glazer, Jeff Dalton, David Anderson, Mike Konrad 和 Sandra Shrum出版了《CMMI和敏捷方法：为何不彼此相容》一书，为那些既想保持项目过程可控又想体验敏捷开发灵活性的开发组织开启了一扇窗口。CMMI过程管理通常被看作实施敏捷开发的障碍，看作自组织团队的敌人，因为CMMI组织和敏捷团队具有不同的文化背景，这也导致了很多误解。比如，敏捷团队很少使用“可预测性”一词，但是“可预测性”却是CMMI过程管理模型的关键所在。
另一方面，CMMI是一个跨组织的方法，CMMI的严格执行可以改进软件质量和控制软件开发成本，尽管执行CMMI过程管理会花费开发组织的很多精力。
项目管理者往往倾向于采用CMMI过程管理,而开发组织内部的那些自组织的开发团队却并不认可,甚至把CMMI过程管理视为项目的一大危险。对立的两者如何才能统一起来？大型开发组织的自组织敏捷团队如何才能满足软件开发成熟度（2级到3级）呢？
消除语言障碍
让对立的两者统一起来，首先要解决的问题是语言沟通障碍。为了使敏捷传道者或过程管理工程师能使用同一语言跟使用不同技术的开发团队沟通交流，就需要使用一种名为“元语言”的现代技术交流方法。使用元语言，你要能保证团队成员能够把元语言转化成他们的自然生命周期语言。举一个例子，一个PMP爱好者经常谈论“功能需求”，但是敏捷团队成员却喜欢使用“用户故事”一词。他们在谈论着同一个概念，但是却使用着具有不同意义的词汇。在这个例子中，你可以统一使用“规格说明”作为元语言，使两者都乐意接受并且统一认识。
元语言是统一敏捷开发过程和CMMI过程管理的关键。如果CMMI传道者、项目管理者和敏捷成员能用统一的元语言进行沟通交流，那么才能消除语言障碍，才能保证沟通交流通畅。
比如,在需求开发阶段，敏捷开发者和普通开发者就可以使用元语言来统一他们各自的生命周期语言。如下表所示：
|
Metalanguage Term 元语言 |
Formal Methodology 正规开发方法 |
Agile Methodology 敏捷开发方法 |
|
Goal 目标 |
Functional Scope 功能范围 |
Epic 史诗故事 |
|
Business Case 业务用例 |
Use Cases 用户用例 |
User Story 用户故事 |
|
Appliance 应用需求 |
Scenario Requirements 场景需求 |
Acceptance Conditions 验收条件 |
|
Review 复查 |
Periodical Tracking Meeting 定期走查会 |
Retrospective 项目回顾 |
图1：列举客户需求开发阶段的一些元语言
识别和使用统一的元语言就要求：CMMI过程管理的传道者能识别元语言，统一元语言，缩小同成熟度模型之间的的差异，而且，还必须认识到元语言需要不断的扩展和提炼，这是一项没有终点的工作。
图 2：你能否识别出这是产品未完成清单还是需求清单？理想情况是你能把你自己的生命周期模型应用于公共模型。