SAFe（Scaled Agile Framework for Enterprise）、Unholy Incarnation of Darkness
…またはそうではないかもしれないことに注意してください。
SAFeがそれ自体を語りたい場合は、次を使用できます。上記のリンク。数百ページのドキュメント、何時間ものビデオ、15の異なるトレーニングコースなどがあります。それが少し聞こえる場合は、各ポイントを通過するときにSAFeがどのように機能するかを説明するために最善を尽くします。
「ポートフォリオ」と呼ばれる最高レベルでは、SAFeは提唱しています。無期限の「バリューストリーム」への資金提供—通常、製品、製品ライン、または顧客タイプを表します。ただし、資金調達を管理するリーンポートフォリオ管理機能（LPM）（以前はウォーターフォールスタイルのプロジェクト予算を担当していたのと同じ人）には、どのポートフォリオエピック（大規模なイニシアチブ）が各ストリームに移動するかを承認する唯一の権限が与えられます。叙事詩は、解決する必要のある問題についての説明ではありません。これらは、これらの問題を解決するための最善の方法について事前に形成されたアイデアです。
すぐに、チームを戦略的な機能ではなく「配信」機能と見なすという昔ながらの考え方の兆候を見ることができます。レベルの思想家はアイデアを思いつき、低レベルの実行者はそれらのアイデアを実行します。仕事に最も近い人々がそれについて決定を下すのに最も適している可能性は無視されます。この誤った考え方から逃れることは、アジャイルの思考の中心的な目標です。 SAFeはリモートで達成できません。
少し低いレベルを見ると、同様の問題が再び発生します。
SAFeは、小規模な製品チーム（多くの場合スクラムチーム）を「アジャイルリリーストレイン」に収集します。 」—「プログラムレベル」と呼ばれる、各グループにまたがる管理役割の追加レイヤーを持つチームのグループ。
一般に、これらの役割はチームの自律性を妨げます。プロセスと通信のオーバーヘッドが不均衡に追加されます。
これらの役割には、製品マネージャー（PM）、Sが含まれます。システムアーキテクト（SA）とリリーストレインエンジニア（RTE）。
SAとPMは、より大きな作業（多くの場合、上記のポートフォリオプロセスから継承されます）を定義して分割し、それらをに渡します。チーム。
プロダクトオーナーとチームは、理論的には、他の小さな作業を自分に課せられた作業よりも優先することができるかもしれませんが、これらの取り組みは、上からの可視性と賛同を制限しています。すべてのチームメンバーが他のアイテムの方が価値があると信じている場合でも、最高点からの作業を最も重要なものとして扱うという自然なプレッシャーがあります。このため、プロダクトオーナーの役割は、その役割の本来の意図であったプロダクトリーダーシップの単一の説明責任ではなく、ストーリーの作成と受け入れ基準の確認に限定されます。
システムアーキテクトは実際のエンジニアリング作業に近い位置にないため、彼らが渡す建築計画は作業の現実から切り離される可能性があります。この種の役割は、大規模設計の先行ウォーターフォールプロジェクトの特徴であり、SAFeでよく保存されています。
リリーストレインエンジニアは、一貫したチーム間のプロセスとリズムを定義し、多くの運用タスクを処理します。最終的に、これにより、個々のチームが確立された基準から逸脱する方法で独自のプラクティスを変更、改善、または実験する余地が少なくなります。
これらの問題はすべて、「大規模」を追加して再び繰り返されることがあります。ソリューションレベル」—プログラムレベルと同様の役割を持つが、リリーストレインにまたがるチームのグループのグループ。これが発生すると、同じ問題が繰り返される可能性がありますが、ソリューションレベルはあまり一般的ではないようです。
SAFe（多くの場合）はRallyにバンドルされています—チームの自律性をさらに制限します
SAFeは、多くの場合、プロジェクト管理ソフトウェアRallyとのパッケージ取引です。Rallyは、期待する種類のソフトウェアです。 SAFeを使用して作成する会社—機能が多すぎて、焦点が定まっておらず、混乱し、不安定で、その結果、習得と使用が困難です。
リーダーシップにRallyを採用することの価値提案は、彼らが見ることができるということです。彼らにthのシンプルで統一された全体像を与える報告企業全体の進歩と問題。
もちろん、これは企業内の全員がRallyを使用する必要があるだけでなく、一貫した方法で使用する必要があることを意味します。繰り返しますが、これはトップダウンの口述によってのみ達成できます。ラリーとそれが仕事について考える方法は、彼らの好み、文脈、または賛同に関係なく、すべてのチームに強制されます。実際にすべての情報をロールアップするには、見積もりと追跡に信じられないほどのオーバーヘッドが必要であり、すべてが遅くなり、実際に作業を行うのに非常に混乱する可能性があります。
さらに、トップレベルのレポートは特に有用ではありません。これは、ラリーが追跡するものに焦点を当てています。配信されたストーリーポイントの量（文字通り構成されている）や対処されたバグの量（「製品品質」のひどい尺度）などの指標です。管理者がこれらの統計を無視した場合、追加されるオーバーヘッドは無駄になります。彼らがメトリクスを管理する場合、チームが見栄えが良く、放っておかれるように、統計は曖昧になります。見積もりが過剰になり、小さな作業が誇張され、信頼の崩壊につながる可能性があります。
SAFeは依存関係を管理するために可能な限り最悪のアプローチを取ります
A依存関係は、チームが自分の作業を完了する前に、他の場所で何かが行われるのを待つ必要がある場合です。 SAFeは、依存関係は受け入れられ、管理されるべき不変の人生の事実であるという後ろ向きの態度を中心に構成されています。それは時々それらを戦略的利点と呼ぶことさえあります。実際には、依存関係を悪いこと、つまりあらゆる機会で最小限に抑えることと考えると、それらの機会は豊富にあり、それらを利用することで主にメリットが得られることがわかります。 SAFeが強調しすぎている、または完全に無視しているいくつかの提案を次に示します。
- あるチームが他のチームのコードベースに他のチームに依存することなく作業を送信できる、内部調達の文化を奨励します。マージを受け入れる
- 必要に応じて、チームメンバーが一時的または永続的にチームを簡単に交換できるようにします
- チームの採用、構造化、トレーニングに重点を置き、自分のニーズに対応します外部の支援なしで
SAFeが実際に依存関係の管理を選択する方法は、計画、プロセス、階層、および標準化への注目を高めることです。予想通り、これは仕事を成し遂げる能力を妨げる多くの会議をもたらします。組織全体に一度に影響を与えるユニバーサルロールアウトを通じて、このアプローチを課します。追加の煩わしい構造がなければ、どの領域が自立できたのかは考慮されていません。
SAFeは計画を過度に重視しています
SAFeのコア機能は、約10週間というアイデアです。プログラム増分（PI）。これらの種類は、通常のスプリントをすべて含む巨大なスプリントのようなものと考えることができます。
各PIは、約2日間実行されるPI計画イベントから始まります。 PI計画には、プログラムレベルでの事前計画と事後計画の活動も必要です。
人々が直接集まって関係を築き、情報を共有し、目標に向けて方向付けることには、確かにある程度の価値があります。一方、その限られた時間枠を使用して、事前定義された機能に基づいて特定のユーザーストーリーの10週間の計画を作成し、それらの計画へのコミットメントを要求することは、はるかに価値がありません。
PI計画が終了するとすぐに、限定に基づいて作成された計画何か新しいことが学ばれるとすぐに、理解と多くの仮定は時代遅れになります。チームは、学習した計画が意味をなさないことに固執することと、チームの上位にいるチームが理解できない理由で期待の方向を変えることとの間で絶えず引き裂かれます。
SAFeはボリュームを重視しています。価値ではない
パイプラインを介したボリュームメトリック、見積もり、および攪拌作業に焦点を当てているため、実際に価値がある、または成功しているという概念は簡単に失われます。製品のエクスペリエンスが実際に苦しんでいて、ユーザーが追加機能の恩恵を受けていなくても、ドアから出荷されるより多くの作業は「価値」である必要があると考えられることがよくあります。
SAFeは次のような批判を認識しています。それは価値に焦点を合わせておらず、最近、「デザイン思考」、「顧客中心主義」、およびその他の概念をドキュメントに追加して補償しています。これまでのところ、プロセスに大幅な変更を加えて、実際にそれらの余地を作るとは確信していません。 、そしてそもそもそれらを理解することすら失敗します。
たとえば、SAFeの「顧客」の定義は、ビジネスの利害関係者またはバリューストリームに資金を提供する人々を「顧客」として定義するための扉を開いたままにします。デザイン思考のコア要素であるソフトウェアを実際に使用するエンドユーザーのニーズに焦点を合わせるために、すべての人（資金を提供する人を含む）の方向を変えることとは大きく異なります。
SAFeは不必要に複雑です
SAFeには、保護する自然な利点があります批判からそれ;非常に複雑なので、完全に理解することは困難です。フレームワークの調査にさらに時間を費やしたにもかかわらず、おそらく、いくつかの間違いを犯したり、いくつかの重要なポイントを見逃したりする可能性があります。ただし、複雑さの多さ自体が正当な懸念事項です。 SAFeには非常に多くの会議、チェックポイント、価値観、方法があるため、全員を同じページに集めることは基本的に不可能です。
SAFeは回顧と継続的な改善を制限します
プログラムレベルでの役割と上記は、すべてのチームの回顧展に参加できるとは限りません。これは、議論されていることの多くを実際に変えることができる人々が回顧展を直接聞くことがないことを意味します。
SAFeがこれを補おうとする方法は十分ではありません。
PI計画リリーストレインの全員が直接会うことが保証されているのはこのときだけです。残念ながら、計画イベント自体の成功にのみ関連する短い回顧展が含まれています。
SAFeには、各PIの終わりに向けて「検査と適応」イベントが含まれていますが、ほとんどスキップされるように設計されているようです。 RTEの調整がどれほど難しいかについて。開催されると、イベントは、もちろん、最後のPIからのボリュームメトリックを確認することによって準備されます。さらに、イベントの30分だけが、問題が表面化して合意された実際の回顧展に割り当てられます。この時間が100人のリリーストレインのすべてのメンバー間で均等に分割されている場合、各参加者は、実際に聞こえる可能性のある状況で問題を提起するために、約10週間ごとに約18秒を取得します。
SAFeには、チームがより広範囲に調査される「評価チャート」のような他の要素もありますが、これらは、SAFeの実践が効果的であるかどうかではなく、遵守されていることを確認することに大きく傾いています。
SAFe集約する概念を劣化させる
キー私がまだ触れていないSAFeの一部は、スクラム、かんばん、リーン製品、リーンUX、DevOPなどの既存の概念の集約です。
慣れていない場合は、各概念を調べることをお勧めします。一度にすべてではなく、時間をかけて独立して。多くはそれ自体が価値がありますが、SAFeは実際にそれらを合成するのに優れた仕事をしておらず、混乱を招くことがあります。適切な例：
SAFeは、その実践が「リーンアジャイル」の原則に従う方法を日常的に支持しています。秘訣は、「リーンアジャイル」が実際には「リーン」または「アジャイル」の原則を参照していないことです。
代わりに、「リーンアジャイル原則」はSAFe独自の設計の作成であり、この新しい一連の「原則」は、同化する概念を歪めます。たとえば、意思決定の分散化に関するページ（すべての原則の中で最も低いランク）は、多くのユースケースで意思決定を集中化することの重要性を強調することで、微妙に覆されています。リストされている他の原則にも同様の問題があります。このすべての情報を一度に紹介された人にとって、元の概念の実際の意味が失われる可能性があります。
SAFeはアジャイルではありません
今では、SAFeの多くの方法がアジャイルの考え方と矛盾していることはかなり明確なはずです。計画に焦点を当て、官僚的で、複雑で、多くの場合不要なプロセスが含まれ、チームの自律性が失われるなどです。
しかし、私たちが本当に気にかけているのが有効性である場合、SAFeがアジャイルであるかどうかは重要です。 ？
はい。
アジャイルの原則は、効果的であると一般に認識され、合意されているため、アジャイルの原則にすぎません。その考えは、開業医のより広いコミュニティに共鳴しました。それが運動が最初に始まった理由です。敏捷性が有効性の予測因子であると考える場合（おそらくSAFeへの関心の背後にある信念）、SAFeがアジャイルの考え方と一致しているかどうかはかなり重要です。購入しているものについて人々を誤解させることは悪いことであり、それを呼び出すのは間違いではありません。
SAFeが機能したことが示されているすべてのケーススタディはどうですか？
scaledagileframework.comには、SAFeの採用の成功に関する約40のケーススタディがあります。失敗のケーススタディは著しく欠けています。頭字語とは異なり、SAFeには、巨大なエコシステム全体にわたる巨大な新しいプロセスへの同時変更が含まれます。これは大きなリスクです。成功した40社のそれぞれに11,250人の認定SAFe実践者がいない限り、私たちが聞いていない企業はかなりあります。
また、そうするケーススタディにはあまり多くの株を入れません。存在します。彼らが焦点を当てているボリュームメトリックが本当に価値があったとしても、物事がうまくいったように見えるいくつかの統計を簡単に選ぶことができます。
特定の例に焦点を当てるために、抜粋を見てみましょう。 FitbitでのSAFeの実装に関するケーススタディから：
2016年、消費者向けテクノロジー企業であるFitbitは、4つの新製品を市場にリリースしました。消費者、および2200万台以上のデバイスを出荷しました。年間で最大数の製品を提供するのは、目標日を達成するためにチームをスケーリングする方法としてSAFe®（ScaledAgileFramework®）を採用するという同社の取り組みと成功によるところがあります。
©ScaledAgile、Inc。
過去5年間のFitbitの株価は次のとおりです：
ええ…2016年はFitbitにとって素晴らしい年のようです。
現在、Fitbitの衰退をSAFeに帰することはできません。私たちが持っている情報の量での採用。しかし、企業がこれほど苦労し、製品の意思決定の応答性を改善するものとしてSAFeの採用を歓迎する場合は、残りのケーススタディを確認するときに、さらに数度目を細めます。
移行のステップとしては問題ありませんよね？
この議論をする人なら、SAFeを移行する必要があると考える必要があります。この点で私たちは同意します！
その移行を行うには、もちろん、うまく機能しない部分を指摘するために時間を費やす必要があります。
それはあなたがしたことですに多くの時間を費やしていますか？
たとえそうだとしても、SAFeは実際に移行できないように設定されています。それが経営者の手に委ねる権限は、トップダウンの統制精神の正当化として機能します。これは、すでに説明したプロセス改善のための不足している方法とは相容れません。 SAFeを適切なコンテキストに「カスタマイズ」する権限は、機能していないものを認識するのに最適な位置にある実際のチームにはほとんど利用できません。
SAFeロードマップのどこにも、実際にはそのいずれかを参照していません。移行としてのコアプラクティス。移行フレームワークの場合、あらゆる種類の移行計画を提供するという非常に貧弱な仕事をします。
認証に重点を置くことも、フレームワークの柔軟性を損ないます。認定を受けるために何時間も費やすと、認定はあなた自身の価値の一部になります。SAFeに似ていないものへの移行は、その価値を脅かすように見えるかもしれません。認定を受けたことで誰も責めることはできません。雇用市場認定が重要な場合。しかし、これらの個人には、SAFeの欠点と、SAFeを改善または逸脱するための可能な方法に注意を払うという特別な責任があります。
これらの問題は広く経験されています
私だけではありません。これらの批判の多くを表現します—フレームワークの特定の慣行にそれらを結び付けることについてもう少し進んだことを願っていますが。裏付けとなる証言をお探しの場合は、以下をご覧ください。
スクラムの共同開発者であるケンシュウェイバーは、早くも2013年にSAFeについて深刻な懸念を表明しました。
ニコラスM.チャイラン、米国空軍のチーフソフトウェアオフィサーは、「Scaled Agile Framework（SAFe）などの厳格で規範的なフレームワークを使用すること」を思いとどまらせています。
Forbesの寄稿者であるSteveDenningは、SAFeを偽のアジャイルを見つける方法。
シリコンバレー製品グループのMartyCaganが、SAFeがシリコンバレー企業の考え方とは正反対であると説明しています。
安全を確保してください（SAFeではありません）
SAFeは確かに多くの批判を受けていますが、私の個人的な感覚は、この批判は特定のオンラインサークルを超えて多くの聴衆に届いていないかもしれないということです。これは、フレームワークを毎日採用する企業の数が増えていることと併せて考えると、特に可能性があります。
多くの人にとって、SAFeに何か問題がある、またはアジャイルの原則とまったく矛盾しているという考えは、完全に斬新です。
より多くの聴衆を対象とした議論の増加がおそらく役立つでしょう。将来的にはこのトピックにさらに触れ、他にどのような選択肢があるかを詳しく説明したいと思います。
今のところ、SAFe環境で作業していなくても、満足する言い訳にはなりません。 。ここで説明した懸念事項は、より広範な警告として捉える必要があります。細心の注意を払っていないと、最も賢明なアイデアでさえ、簡単に採用され、破損し、混乱する可能性があります。