ITILとDevOpsを比較した議論は珍しいものではない。このテーマにはさまざまな見地がある。ITILとDevOpsは考え方が異なるというものがあれば，適合性があるというものもある。この２つは異なるものだが，IT分野においてそれぞれの役割を持っている，という意見もあるのだ。Open Group IT4IT Forumでアジャイルワークチームのリーダを務めるCharles Betz氏は，“ITビジネスを管理する，ベンダニュートラルなリファレンスアーキテクチャ”の提供を目的とした先日の記事で，この２つには基本的な原則の対立がある，と論じている。フェーズ分割されたワークフローから抜けられていないITILに対して，DevOpsは仕掛管理や管理キュー，小バッチ管理といったリーン製品管理の教義を採用しているというのだ。
Betz氏と，同じくITILに懐疑的なJeff Sussna氏は，ともにITILがITコミュニティに対して，“サービス中心，アウトサイド・イン，顧客中心思考の促進”を通じて多大な功績をした点は認めている。しかし彼らは，ITプロセスをビジネスニーズに継続的に整合させようという，“継続的サービス改善”を巡る議論が，ITIL V3で起きたにも関わらず，ITILは相変わらずフェーズステップ的思考に留まっている，と強く主張する。Betz氏は言う。
“反復”あるいは“フィードバック”に関する言及ひとつに対して，“計画”ないし“立案”ということばが10回使われているのです。特に注目するべきなのは，サービス戦略の中での数回を除けば，“試み(experiment)”ということばが，他の場所ではまったく現れないという点です。
Sussna氏はITIL V3について，
V3ではサービス戦略や設計，移行，運用で構成されるフェーズセットの最後に継続的サービス改善を配置しています。このようなウォーターフォール的アプローチを見て，私は少々ショックを受けました。
Betz氏はITILを，“戦略，開発，運用の間で綿密に計画された作業の大規模バッチ”というITパイプラインについて述べたものだ，と評している。また，ITILは基本的に，主要な問題解決メカニズムとしてのプロセスと，計画と資料作成を通じたリスク緩和を信奉しているのだ，とも述べている。これらの基本的概念の説明として，ITILの大部分は10年以上前に書かれたものである点を氏は指摘する。従ってITILは時代遅れである，と言うのだ。
ITILは，実行とフィードバック，フローを中心とした社会技術的システムとして，ITデリバリの基本モデルの改善を求めているのです。
それに対してGene Kim氏は，ITIL/ITSMとDevOpsは極めて親和性が高い，と述べている。
ITILとITSMは依然として，IT運用を支えるビジネスプロセスとしては最高の体系です。実際にそれらは，IT運用がDevOpsスタイルのワークストリームをサポートする上で必要な機能の多くを取り上げています。
そして，
さらに重要なことは，ITSM実践者たちがDevOpsの取り組みを支援し，ビジネス価値を創造する能力を独自に備えている，という点です。
そしてKim氏は，ITIL/ITSMの実践者がビジネスバリューを提供している例をいくつか紹介する。インフラストラクチャ自動化プロジェクトでは，既存の“リリース管理準備チェックリスト，セキュリティ強化チェックリストなど”への，自動ビルドプロセスの統合を実現している。また，ITILで頻繁に使われる用語の“標準的変更(Standard Changes)”は，頻繁で文書化された，リスクの低い，事前承認された変更を表している。ITSMを実践することで，この“標準的変更”を，実運用システムへの自動デプロイに組み込むことが可能なのだ。
Rob England氏はBetz, Sussna，Kim各氏とは意見を異にする。ITILとDevOpsは正反対ではあるが，どちらも同じIT組織の中で独自の位置を確保している，と氏は言う。氏は，バイモーダルモデルとペース層モデルによるマルチスピードITを提唱する，Gartner氏から受けたインスピレーションについて説明している。
- 保守型(Conservative): 従来型すなわちウォーターフォール型の変更管理と運用。
- 敏捷型(Nimble): DevOpsあるいはその亜種
ビジネスはいずれかのアプローチを選択しなければならない，と England氏は言う。一部のビジネスニーズやそれをサポートするアプリケーションには，イノベーションや変革のスピードを必要とするものがある。それらには敏捷型アプローチが必要だ。別のビジネスニーズは安定性が必要で，リスクは極めて低い。それらには保守型アプローチが適当だろう。