スクラムはプロジェクト管理プロセスを改善できるか(can scrum help to improve a project management process) と題した記事で，Javier Garzás，Mark C. Paulk両氏は，CMMI-DEV(Capability Maturity Model Integration for Development，開発のための能力成熟度モデル統合)のプロジェクト管理プロセス領域とスクラムとの関連性について検討を行っている。
Jeff SutherlandとKen Schwaberの両氏によって説き始められたスクラムは，最も一般的なアジャイル手法のひとつとして認められるまでになりました。スクラムはプロジェクト管理の方法論，あるいは反復型開発のフレームワークである，と説明するのが妥当でしょう。
CMMI-DEV(Capability Maturity Model Integration for Development)は，ソフトウェア開発企業の組織的成熟度の評価手法であり，現在ではプロセス改善フレームワークのデファクトとなっています。CMMI-DEVの "レベル" を達成することにより，多くの組織が生産性と製品品質のレベルの向上を果たしています。
氏らはCMMIとスクラムの関連性をまとめた表を公開して，個々のプロセス領域に対応している。CMMIのプロセス領域のいくつかは，スクラムのプラクティスの展開によって充足可能だと氏らは言う。
スクラムとの対応は次のようなものだ。
- "要求管理 (Requirements Management)" – プロダクトバックログとスプリントバックログ内のユーザストーリ
- "プロジェクト計画策定(Project Planning)" – ストーリポイントの見積，反復型ライフサイクル，さまざまなミーティングなどのセレモニ，プロダクトバックログとスプリントバックログなどを通じて対応する。
- "プロジェクトの監視と制御(Project Monitoring and Control)" – バーンダウンチャートとミーティング
- "統合プロジェクト管理(Integrated Project Management)"の一部 – ロールとミーティング
ただしスクラムでは対処できないCMMIプロセス領域もいくつかある。
スクラムはソフトウェアプロジェクト管理のフレームワークですが，"供給者合意管理(Supplier Agreement Management)" や "リスク管理(Risk Management)" などは扱いません。これらは一般的に，アジャイルプラクティスのスコープ外なのです。"供給者合意管理" が適用されるのは，下請契約を行う組織のみです。"定量的プロジェクト管理(Quantitative Project Management)" は，プロセスに期待されるパフォーマンスを定量的に理解するための統計的概念を扱うものですが，これも対象外です。
氏らはCMMIに基づくプロセス改善に対して，スクラムがどの程度サポートできるかを示すことによって，自らの記事の結論付けている。
スクラムのプラクティスは多くの組織において，プロジェクト管理のベストプラクティスとして理解されるべきものです。CMMI-DEVのプロジェクト管理プラクティスすべてに完璧に対処することはできないとはいえ，スクラムは優れたサポートを行うことができます。
アジャイルあるいはスクラムとCMMIとの組み合わせについては，その他にもいくつかのリソースがある。
- CMMI研究所には，CMMIとアジャイル の組み合わせを支援する公開資料のリストがある。CMMIとスクラム についても公開されている。
- Agile CMMI というLinkedInのグループがあり，CMMIとアジャイルに関する情報を公開している。