ING Retail Banking NetherlandsのJan-Joost Bouwman氏とMark Heistek氏はDevopsdays Amsterdamで，CMMI-ITIL型の組織がよりアジャイル的な価値観からどのような恩恵を受けられるか，という内容のプレゼンテーションを行った。INGで見られたのは，運用システムにデプロイされる変更数の著しい増加，そして変更に対するリスク値の減少だった。
INGのIT部門はITILに従っているため，時間を掛けて多数の指標を測定し，アジャイル転換の影響を評価することが可能だった。アジャイルおよびDevOps実践のためにIT部門を再構築していた期間を除けば，変更の回数は明らかに増加した。
(ING Netherlands提供)
INGではそれぞれの変更に，リスク値を関連付けている。平均的な変更に対するリスク値は，長期間にわたって減少傾向が続いている。
(ING Netherlands提供)
インシデントの回数はほぼ横ばいだった。変更数増加の直接的な結果として，変更当たりのインシデントの割合は低下した。
(ING Netherlands提供)
(ING Netherlands提供)
最後の指標はINGを驚かせた。従来の方法では重要な存在であったプロセスマネージャが，大した価値を持っていないという結論に結びつくからだ。注目すべきなのは，Jan-Joost Bowman氏が，残っている数人のプロセスマネージャのひとりであることだ。
氏とMark Heistek氏は，同じ道筋を歩みたいと望む企業に対して，自分たちが学んだことを教えてくれている。
- どのような試みにも言えることだが，バリューチェーン全体の参画を得ること。これから進む道に対して開発，運用，マネージメント，ビジネスが同意することが重要だ。
- 少数で限定的とはいえ，プロセスが必要であることに変わりはない。
- ITILはDevOpsのニーズを満たすように修正可能である。INGの経験からは，ITILとDevOpsは相反するものではないことが分かる。事実，DevOpsの考え方には，部分的にITILが適用されている。
- 無駄の排除という中核的なリーン原則に沿って，すべてのエンジニアが価値を提供する必要がある。
今回の移行以前は，変更についてはウォーターフォールのアプローチを行っていた。要件収集，影響分析，アプリケーションアーキテクチャ設計，機能設計，技術設計，開発，テスト，運用リリースという手順だ。変更のプロセスは計画CAB(Change Advisory Board, 変更諮問委員会), 技術CAB, 展開CABという，３つのCABによって監視していた。加えて，詳細なチェックリストを備えた３つのゲートによるシステムにより，リスクを最小限にしようとしていた。プロセスマネージャ以外に，プロジェクトには"プロジェクトアライナ(Project Aligner)"と呼ばれる役割がアサインされて，プロジェクト作業のプロセスへの準拠を支援した。
アジャイルへの移行後は，展開CABのみが残されている。重要な非機能要件に対してはDoneの定義(DoD/Definition of Done)がある。各チームは，アプリケーションや技術，ビジネスパートナに応じて，独自の基準をDoDに追加することができる。
それにしても，同社が移行を実施したきっかけは何だったのだろう？ ３年前，INGのIT部門はCMMI, Prince2, ITLで管理されていた。これらの努力にも関わらず，プロセスは依然として期待よりも不安定で，運用システムを変更するための許容基準は高まる一方であったのだ。アジャイルへの移行は，少数の開発チームがアジャイルメソッドを適用するところから始まった。それらのチームの成果は，当初はウォーターフォールメソッドを使用するチームに劣っていたが調整期間を経て，ウォーターフォールチームを凌駕する改善成果を出し始めたのだ。彼らの成功が明らかになると，すべての開発チームがアジャイルの採用を望むようになり，やがては運用を含むIT部門全体が移行に参加した。現在では，INGのオランダ国内銀行をサポートする150チームすべてがスクラムを実施している。