Dean Leffingwell氏の開発したScaled Agile Framework (SAFe)が，コミュニティの中でその勢いを増しているようだ。スクラムの組織レベル版にあたるものだ，と評する声もある。現時点でRallyやNet Objectives，Valtechなどを含む，いくつかのベンダがSAFeをサポートしている。トレーニングや認定を行っているSaled Agile Framework Academyなどもある。そして最終的には，あなたとあなたの会社がSAFeパートナになることも可能なのだ。ツールサポートや有名ベンダによるサービス提供，認定プログラム，公式標準といったこれらすべてのものが，大規模組織のエグゼクティブたちに安心感を与えている。これらの人たちはそれぞれ，自分の役割について理解しているし，大規模組織への適用をサポートするサポートシステムも存在する。全体像という形でそれを示すために，立派なダイアグラムも用意されている。
ただしコミュニティの誰もがみな，SAFeをよいアイデアだと認めている訳ではない。それどころか，極めて否定的な意見も多いのだ。David J. Anderson氏やKen Schwaber氏といった人たちがSAFeへの反対を表明しているし，今年のアジャイルカンファレンスで筆者が，何人かの著名かつ経験豊富なアジャイル実践者やコンサルタントと話した際にも，SAFeに対して明確に反対する声が聞かれた。
そこでまずは，SAFeのメリットを確認するところから始めよう。何よりもまず，SAFeは非常に具体的である。チーム，プログラム，あるいはポートフォリオといったレベルで，明確な指針が提示されている。これらは現在のビジネス構造におけるレベルそのものなので，理解も容易だ。これが現実として何を意味するのか，RallyのRob Pinna氏は，41 Things You Need To Know About the Scaled Agile Frameworkと題したブログ記事で詳説している。
Scaled Agile Framework®(SAFe)は，アジャイルを企業レベルで適用する上でのレシピを提供します。それは全体像として説明されています。チームのアジャイルチームにスクラムがあるように，エンタープライズレベルのアジャイルにはSAFeがあるのです。
そしてDavisbaseサイトでも，Josh Fruit氏が5 reasons why we might want to consider safeと題して，SAFeを導入する理由を次のように説明している。
- チームレベルでのアジャイル導入には成功していて，現在はひとつ以上のプログラムあるいは部署に対する，一貫したアジャイルアプローチの導入に関心が移っているような場合。
- 複数のチームでそれぞれ独自にアジャイルを実践しているが，チーム間に作業の依存性が生じる度に障害や遅延，失敗を繰り返し経験している場合。
- 組織全体にアジャイルを展開したいと思っているが，新しい役割として何が必要か，既存の役割の何を変えなければならないか，といったことが分からない場合。
- 組織全体へのアジャイルの展開を試みてはいるが，ビジネス部門を越えて一貫性のある戦略，ポートフォリオのレベルからプログラムおよびチームレベルまでの一環した整合性などの実現に苦慮している場合。
- 組織として製品開発のリードタイム改善が必要であると分かっていて，かつSAFeによってアジャイルのスケーリングを実施したJohn Deereのような企業の成功例を聞いて，彼らの行った方法を知りたいと思っている場合。
そして最後に，氏はその記事の中で，SAFeをシンボル的に使用したJohn Deereの成功について触れている。非常に大きな成果を挙げたこの事例については，InfoQでも2012年３月の記事 トラクターはアジャイルで作られた で取り上げて，Chad Holdorf氏に活動の詳細について質問している。
ここまで見ると，SAFeの採用には極めて妥当な理由がいくつもあるようだ。SAFeパートナの誰かと話をすれば，大規模アジャイル採用はあたかも既定路線であるように感ずることだろう。問題解決。大組織にいるなら，SAFeを使用するべき。しかし問題をより複雑にしているのが，開発現場では，著名なコミュニティリーダからも，現場の実践者たちからも，SAFeに対して強い拒否反応があることだ。
スクラム創始者のふたりの内のひとりであるKen Schwaber氏は次のような理由で，SAFeに反対を表明している:
RUP(Rational Unified Process)の悪夢が戻ってきました。RUPでの手痛い失敗の結果から，今度はシンプルで，1サイズですべてにフィットするアプローチとして，Scaled Agile Frameworkをアジャイル組織に押し付けてきたのです。ツールベンダのRallyとパートナを組むことで，彼らのアプローチはますます複雑なものになっています。コンサルタントがカスタマイズしてくれる，という点でも，まさにRUPと同じです。
彼らは今週，ナッシュビルのAgile 2013でも，プロセスやツールを売り込んでいます。RUPカンファレンスの方がいいのでしょうが，そんなものは存在しません。ウォーターフォールカンファレンスでもよさそうですが，彼らはもうウォーターフォールではありません。そういう理由で彼らは，私たちのカンファレンスにいるのです。変な話ですが，彼らには他に行くところがありません。快く迎えてあげましょう。
かんばんの創始者であるDavid J. Andersonは，自身がSAFe認定実践者でないことを認めながらも，自身がSAFe実践者と交わした会話や，公開されている文書を元に，次のようなことを書いている。
[SAFeを構成する] プラクティスの成功事例のコレクションは，全体としても成功を収められるだろうという推測があります。この推測と，最新ジェット旅客機で行われるテストを比較してみましょう。後者では，300,000に及ぶコンポーネントを個々にテストします。すべてのコンポーネントがテストされた時点で，それらのパーツで構成される航空機全体が始めて"安全"だ，と考えるからです。フレームワークを使用することによって発生するプロセスの本質そのものが意味するのは，すべての実装には独自の部分があり得る，プロセス設計はそれ故に未テスト，ないしは未証明である，ということです。新たなプロセスはたった一度の変更で実践されます。漸進的にステップ毎に適合性をテストして，その成功を踏まえて選択する，というような進化的な方法で実行されることはありません。これが原因で生じるリスクは，歴史が十分に証明しています。
コミュニティで大きな尊敬を集めているリーダたちからの，これらは強い気持ちだ。ただし公平を期して言うならば，氏らはともにSAFeの経験を持っていないし，テクニックに関する教育も受けていない。そこで彼らよりもう少し状況を把握していて，しかも認定パートナではない人たちの意見を聞いてみよう。Dean Leffingwell氏のSAFeユーザグループミーティングに参加したRobert Galen氏が，次のような記事を書いている。
氏(Dean Leffingwell氏)はアジャイルの実例として，10のチームを引き合いに出しました。チームはそれぞれよく働き，その成果を示すべく，10件のスプリントレビューを立案しました。ステークホルダやマネージャたちは律儀にも，すべてのミーティングの第1回目に出席して，そして帰って行きました。
ここで氏が質問しました - 彼らのうち何人が，次のスプリントレビューに戻ってくるでしょう？この質問には，10チームすべての作業レビューの繰り返すために，貴重な時間を浪費できる訳がない，という含みがありました。つまり氏は，"現実の世界"において彼らにはそのための時間がないのだから，それは不適切なものだ，ということを暗に言ったのです。
むしろチームは，開発の成果をひとつのデモンストレーションイベントに取りまとめて，リリース直前ないしその近くに実施するべきでした。いわゆるリリースレビューです。この方法であれば，ステークホルダやリーダの時間は効率的に使用されることになります。チームとしても，より成熟したソフトウェアをデモできる，より広範なフィードバックと可視性を獲得できる，というメリットがあります ... 私は，リーダの時間がもっとも重要だ - チームとは本来，リーダに"仕える" ものだ - という，この説明，あるいは考え方には疑問を感じます。もしチームがすべてのアジャイルチームの中で，世界最高の優先度を持つビジネスに従事しているならば，リーダとしての私はすぐに席を立って，チームの中に飛び込んでいかなければならないと思います。彼らが何をするのか，どうやって行うのか，それがどのようなものか，熱意を持って見ていかなくてはならないのです。
そして最後に，SAFeの実施経験を持つSPC(SAFe Certified Professional Consultant)のValerie Santillo氏は，SAFeについて賛否付けがたい意見を持っている。氏はプラクティスの意義を認める一方で，人々の注目する点が間違っているのではないかと心配しているのだ。
どのようなフレームワークを使っても，十分な成果を得られないというリスクはあります。ですが，リスクを生じさせるのはフレームワークではありません。人です。フレームワークやプロセスを活かすのは人なのです。フレームワークの購入にも同じようなリスクがあります。人が人を売ることになるからです。SAFeを販売する人たちには，単なるフレームワーク以上のものを代表する責任があります。SAFeが大規模用のアジャイルであるということは，文化的ないし戦術的要素がそこにある，ということです。組織の望む結果を得るためには，そのいずれにも注意を払い，努力をしなければなりません。
明らかなのはSAFeがここにある，ということだ。巨大なSAFeには，支持者も反対者も数多く存在する。読者はSAFeについて，どのような経験をお持ちだろうか？