スクラムは、もともとスクラムガイドで説明されているように、単一のスクラムチームが、持続可能なペースを維持しつつ、最適な価値を提供できるようにすることを重視している。スクラムガイドの発行以降、スクラムの利用はプロダクト、プロセス、サービスなどの開発といった複数チームの協力が求められる領域まで広がりを見せている。
現場では、組織内のスクラムチーム数の増加に伴い、2つの重要な問題の発生が繰り返し見られた。
こうした問題に対処するために、複数のスクラムチームを効果的に調整するフレームワークが明らかに必要だった。Scrum@Scaleフレームワークの目的は以下の通り。
Scrum@Scaleは、複数のスクラムチームのネットワークが、組織において優先順位付けされたゴールに集中するのに役立つ。Scrum@Scaleの目的は、単一のスクラムチームが機能するやり方を複数のチームのネットワーク全体へと自然に拡大し、管理機能が実用最小限の官僚機構（MVB）内にある、という構造を構築することである。
チームのネットワークの特性がそのサイズに依存しない場合、リニアなスケーラビリティを実現できる。このゴールのためにチームのネットワークを設計・調整することは、特定の方法で成長を制約するものではない。むしろ、ネットワークが独自のニーズに基づいて有機的に成長することを可能にし、関係者に受け入れられやすい持続的な変化のペースを実現する。
実用最小限の官僚機構とは、顧客に価値を届けるのを妨げることなく、組織を機能させるために必要な機関とプロセスが最小限であるものと定義される。意思決定の遅延を減らすことは、ビジネスアジリティの実現に役立つ。このことは、成功の主な原動力として知られている。Scrum@Scaleの導入を開始するには、アジャイルマニュフェストとスクラムガイド2020をよく理解することが不可欠である。アジリティの本質を理解しないと、それを達成することはできない。スクラムを実践できない組織は、スケールすることはできない。
このガイドは、Scrum@Scaleと、そのフレームワークのコンポーネントの定義を提供する。そして、スケールされた役割、スケールされたイベント、エンタープライズにおける作成物に対する責任と、それらを結び付けるルールについて説明する。
このガイドは次の4つのセクションに大きく分割されている。
スケーリングの成功には各コンポーネントが必要となる。それらの中核となる設計思想を変更したり、省略したりすると、あるいは、本ガイドに示す基本的なルールに従わないと、Scrum@Scaleのメリットを享受できない。
基本的な構造とルール以外の各コンポーネントを実装する具体的な戦術はさまざまであるため、本ガイドには記載していない。補足的なパターン、プロセス、インサイトは、その他の情報源で提供されている。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。
スクラムガイドでは、イノベーション、顧客満足、パフォーマンス、幸福を促進するチーム環境を生み出す要素の最小限のセットについて説明している。スクラムは、徹底的な透明性と一連の公式なイベントを使い、チームとそのプロダクトを検査・適応する機会を提供する。
Scrum@Scaleは、スクラムガイドに従って機能しているチームのネットワークが、複雑適応系の問題に対処しつつ、最高の価値のプロダクトを創造的にデリバリーすることを可能とする、軽量級の組織フレームワークである。これらの「プロダクト」としては、物理的、デジタル、または複雑な統合システム、プロセス、サービスなどがある。
Scrum@Scaleガイドでは、スクラムを利用してスクラムをスケールするための最小限のコンポーネントセットと組織全体で生まれるビジネスアジリティーについて説明している。本ガイドは、産業界、政府、非営利団体、学界のあらゆるタイプの組織で活用できる。スクラムをまだ使っていない組織では、組織のオペレーティングシステムを変更する必要がある。
スクラムでは、”What”（プロダクト）と”How”（プロセス）の責任の分離に注意する必要がある。Scrum@Scaleでも、管轄と責任が明確に理解されるように、同じ注意が払われる。これにより、チームがその最適な生産性を達成するのを邪魔する、無駄な組織上の衝突が取り除かれる。Scrum@Scaleはコンポーネントで構成されているため、組織はその変革の戦略と実施をカスタマイズできる。これにより、組織は、最も価値がある、あるいは最も適応が必要であると考えられる分野に、段階的に優先順位をつけて変革の取り組みを行い、その後、他の分野に進むことができる。
Scrum@Scaleは、これらのコンポーネントを、スクラムマスターサイクル（“How”）とプロダクトオーナーサイクル（“What”）に分け、この2つのサイクルが2つのコンポーネントで交わり、3つ目のコンポーネントを共有する。まとめると、これらのサイクルは、一つの道筋に沿って複数のチームの取り組みを調整することを強力にサポートする構造を作り出す。
Scrum@Scaleの目的は、経験的プロセス制御の柱とスクラムの価値基準を通じて健全な組織文化を構築することである。経験的プロセス制御の三本柱とは、透明性、検査、適応である。これらの柱は、公開（オープン性）、勇気、集中、尊敬、確約（コミットメント）というスクラムの価値基準によって現実のものとなる。
公開（オープン性）は、すべての作業とプロセスへの透明性を保証する。さもなくば誠実な検査と、より良いものに適合することはできない。勇気は、革新的な方法で、より迅速に価値を届けるために必要となる、大胆な飛躍をすることを示す。集中と確約（コミットメント）は、自分たちで自分たちの責務を全うする方法を見つけることを示し、顧客へ価値を届けることを最優先とするということである。最後に、これらすべては、他の誰も成しえない仕事に従事する個人への尊敬に支えられた環境なくしては成しえない。
Scrum@Scaleは、顧客価値の提供を最前線に置きつつ、持続可能なペースで仕事をする積極的なチームの学習環境をサポートする。これにより、組織の成長を支援する。
チームのネットワークを導入する際は、スケールする前に、スケール可能なリファレンスモデルを開発することが不可欠である。リファレンスモデルは、スプリントごとにデリバリーを行うための調整を行う、小さなチームのセットである。これらのチームへのスクラムの導入が成功すると、機能する健全なスクラムの例ができ、組織の他のチームでも再現できるようになる。これは、チームの次のネットワークでスクラムをスケールするためのプロトタイプになる。多数のチームが同時に展開されると、スクラム導入における欠陥は拡大される。スケーリングの問題としては、パフォーマンスを阻んでチームに不満を抱かせるような組織の方針や手続き、開発手法などがある。
スケールされた状況では、完全に統合された一連のインクリメントを提供するために調整が必要なチームをグループ化して、スクラムオブスクラム（SoS）にすることで、リファレンスモデルが最も有効になる。スクラムオブスクラムを効果的に運用するためには、2つのリーダーシップグループで構成された、実用最小限の官僚機構によってサポートされる必要がある。実用最小限の官僚機構とは、スクラムオブスクラムによって何を生み出すべきかに焦点を当てたエグゼクティブメタスクラム（EMS）フォーラムと、どのようにスクラムオブスクラムにより速く仕事を完了させるかに焦点を当てたエグゼクティブアクションチーム（EAT）である。エグゼクティブメタスクラムとエグゼクティブアクションチームは、各サイクルの回転のハブ（中心）となるコンポーネントである。
スクラムでは、スクラムチームが前工程なしに独立してプロダクトをリリースできるようになることが理想的な状態である。このためには、アイデア出しから実装まで、必要なすべてのスキルを持ったメンバーが必要である。スクラムオブスクラムは、スケーリングのこの理想を再現する、複数チームからなる大きなチームである。スクラムオブスクラム内の各チームが、チームプロセスコンポーネントを実践できなければならない。
チームプロセスは、スクラムガイドで規定されているスクラムを行うことである。各スクラムチームにはプロダクトオーナーとスクラムマスターがいるため、チームプロセスは、プロダクトオーナーサイクルとスクラムマスターサイクルの最初の交差点となる。チームプロセスのゴールは以下の通り。
スクラムオブスクラムは、スクラムチームのように機能し、スクラムからスケールされたそれ自身の責任、イベント、作成物を持ち、チームプロセスコンポーネントの要求を満たす。スクラムガイドでは最適なチームの規模を10人以下と定義しているが、ハーバードの研究4では、最適なチームの規模は平均で4.6人とされた。よって、スクラムオブスクラムのチームの最適なチーム数は4または5チームである。
スクラムオブスクラムを構成するチームは、ダイナミックなグループとして、各スプリントの終わりに、完全に統合され、出荷可能な一連のプロダクトインクリメントを完成させることに責任を持つ。最も望ましいのは、価値を顧客に直接リリースするために必要な全機能を完成させることである。
注意: 上図およびこの後の図では、薄い灰色で囲まれた五角形がチームを表す。状況に応じて、SMとPOをこれより小さい五角形で表すことにした。組織図は組織によって大きく異なる可能性があるため、これらの図は例示のみを目的としている。実装の規模に応じて、複雑なプロダクトの提供には複数のスクラムオブスクラムが必要な場合がある。そのような場合には、複数のスクラムオブスクラムからスクラムオブスクラムオブスクラム（SoSoS）を編成できる。それぞれが、各スクラムオブスクラムからスケールされたそれ自身の役割、作成物、イベントを持つことになる。
スクラムオブスクラムをスケールすることで、組織内のコミュニケーション経路の数が削減されるので、コミュニケーションの経路の複雑さや、オーバーヘッドが軽減される。SoSoSは、スクラムオブスクラムが単一のスクラムチームとインタフェースするのとまったく同様の方法でスクラムオブスクラムとインタフェースするため、リニアなスケーラビリティが実現する。
注意: 簡潔にするために、例の図に含まれるチームとグループの数は対称的にしている。組織図は組織によって大きく異なる可能性があるため、これらの図は例示のみを目的としている。
スクラムオブスクラム（SoS）がスクラムチームとして機能する場合は、スクラムイベントと、チームの対応する責任をスケールする必要がある。各スプリントの“How”を調整するために、SoSは、スケールされたデイリースクラムとスプリントレトロスペクティブを行う必要がある。各スプリントの“What”を調整するために、SoSは、スケールされたスプリントプランニングとスプリントレビューを行う必要がある。継続的な活動として、バックログリファインメントもスケールされる必要がある。
スケールされたデイリースクラムとレトロスペクティブは、グループのスクラムマスター（スクラムオブスクラムマスター、SoSMと呼ばれる）がファシリテートする。スケールされたスプリントレビューとバックログリファインメントは、チーフプロダクトオーナー（CPO）が率いるプロダクトオーナーチームがファシリテートする。スケールされたスプリントプランニングは、プロダクトオーナーチームとスクラムマスターが行う。プロダクトオーナーチームは、現在のスプリントで何が提供されるかの洞察を得て、スクラムマスターは、キャパシティと技術的な能力の洞察を得る。スクラムオブスクラムマスターとチーフプロダクトオーナーの役割はリーダーシップグループにスケールされ、スクラムマスターサイクルとプロダクトオーナーサイクルをそれぞれ促進し、Scrum@Scaleのコンポーネントの要求を満たす。
デイリースクラムの主なトピックは、スプリントゴールに向けた進捗と、確約（コミットメント）を果たすうえでの障害物である。スケールされた状況では、スクラムオブスクラムは、全体の進捗を理解し、参加チームが提起した障害物に対応する必要がある。よって、各チームから少なくとも1人の代表者がスケールドデイリースクラム（SDS）に参加する。必要に応じて、参加チームのだれでも、何人でも参加することができる。
コラボレーションとパフォーマンスを最適化するために、スケールドデイリースクラムイベントは、以下の通り、デイリースクラムとまったく同じやり方で行う。
回答される質問の例は以下の通り。
スプリントごとに、スクラムオブスクラムは、スケールされたスプリントレトロスペクティブを行う。このレトロスペクティブでは、各チームのスクラムマスターが集まり、継続的な改善を促すために行った実験とその結果を話し合う。さらに、次回の実験や、成功した改善をチームのグループ全体、あるいはそれ以外にも活用できる方法も話し合うべきである。
スクラムオブスクラムのスクラムマスターをスクラムオブスクラムマスター（SoSM）と呼ぶ。スクラムオブスクラムマスターは、スケールされたイベントが確実に行われ、生産的でポジティブであり、タイムボックスが守られるようにする責任を負う。スクラムオブスクラムマスターは、チームのスクラムマスターがなる場合もあれば、この役割に特化した個人の場合もある。SoSMは、共同チームの努力の結果であるプロダクトのリリースと、スクラムオブスクラムの有効性を継続的に改善する責任を負う。これには、チームのスループットの向上、コストの削減、品質の向上が含まれる。これらのゴールを達成するために、SoSMは次のようにしなければならない。
スクラムオブスクラムマスターは、チームと組織に奉仕する真のリーダーであり、スクラムオブスクラムの外部も含めて、チーム横断的な依存関係を理解し、チーム横断的な調整とコミュニケーションを可能にする。SoSMは、プロダクト開発の進捗、障害物の除去状況、その他のメトリクスの情報を発信することで、チーフプロダクトオーナー、ステークホルダーさらには組織全体に情報を提供し続けることに責任を負う。スクラムオブスクラムマスターは、組織全体でスクラムの有効性と導入を高めるよう他者をメンタリングすることなどで、リーダーシップを発揮する。
複数のスクラムオブスクラムが1つのスクラムオブスクラムオブスクラムにグループ化された場合、より広い観点から調整を行うために、スクラムオブスクラムオブスクラムマスター（SoSoSM）が必要になる。
エグゼクティブアクションチーム（EAT）は、アジャイル組織全体に対してスクラムマスターの責任を果たす。このリーダーシップチームは、以下を行うことで、リファレンスモデルが最適に機能するアジャイルエコシステムを生み出す。
エグゼクティブアクションチームは、スクラムオブスクラム（または、より広範なネットワーク）のメンバーで取り除くことができない障害物を除去する責任を負う。したがって、それを除去するために政治的、財務的に権限を与えられた個人で構成されなければならない。エグゼクティブアクションチームの機能は、複数のスクラムオブスクラム（または、より広範なネットワーク）を調整することと、組織内の非アジャイル部分とインタフェースすることである。スクラムチームと同様に、プロダクトオーナー、スクラムマスター、透明性のあるバックログが必要である。
25チームの5つのグループを調整するEATを示す参考図
エグゼクティブアクションチーム（EAT）の成果は、組織のアジャイルオペレーティングシステムの構築である。EATは、ビジネスアジリティの向上という目標を達成するために、組織の継続的な変革に向けた取り組みをプロダクトバックログとして整理選択し、提示する。このバックログには、障害物を除去するプロセス改善と、標準化が必要なプロセス改善も含まれる。
エグゼクティブアクションチームの責務には以下を含まれるが、これらに限定されない。
エグゼクティブアクションチームの役割は、このバックログが実行されていることを確認することである。これをEAT自体で行うことも、別のグループに権限を与えて行わせることもできる。エグゼクティブアクションチームは組織内のスクラムの品質に責任を負うため、スクラムマスター組織全体がEATに報告する。
スクラムマスター組織（スクラムマスター、スクラムオブスクラムマスター、エグゼクティブアクションチーム）は、スクラムマスターサイクルのコンポーネントを実装するために全体として機能する。固有のコンポーネントは以下の通り。
障害物の除去は、できる限り迅速に除去されるのが理想的である。これは、障害物自体が組織に拡散することを回避し、未解決の障害物によって生産性を低下させないために不可欠である。よって、継続的改善と障害物の除去のゴールは以下の通り。
共通のプロダクトの作成に複数のチームが必要な場合、成功するにはコラボレーションの合理化が必要である。よって、チーム横断の調整のゴールは以下の通り。
スクラムオブスクラムのゴールは、単一のユニットとして機能し、一緒にリリースすることなので、プロダクトをどのようにデリバリーするかは、スクラムオブスクラムのグループとしての範囲に含まれる。プロダクトオーナーチームは、リリースの内容と、インクリメントを顧客に届ける最適なタイミングの両方を決定する。よって、スクラムオブスクラムのデリバリーのゴールは以下の通り。
スクラムオブスクラムごとに、チームのネットワークに供給する共通のバックログがある。そして、スクラムオブスクラムのプロダクトオーナーとして責任を負う、チーフプロダクトオーナーを含むプロダクトオーナーチーム（POチーム）が必要である。POチームが主に重視するのは、個々のチームの優先順位を一列に並べることである。これによって、個々のチームのバックログの調整と、ステークホルダーと顧客ニーズの整合性の確立が可能になる。
各チームのプロダクトオーナーは、自チームのスプリントバックログの構成と優先順位付けに責任を持ち、ビジネス目標の達成に必要な場合は、自身の裁量で、共通バックログからアイテムを引き出したり、独立したバックログアイテムを生成することができる。
プロダクトオーナーチームの主な役割は以下の通り。
チーフプロダクトオーナーは、プロダクトオーナーチームと一緒に優先順位を調整する。共同でバックログの優先順位をステークホルダーと顧客のニーズに合わせる。CPOは、この役割を兼任する個別チームのプロダクトオーナーである場合もあれば、この役割に専任した個人の場合もある。主な責務は通常のプロダクトオーナーと同じであるが、スケールされて以下のようになる。
チーフプロダクトオーナーは、関連するスクラムオブスクラムマスターとともに、リリースプランに従ったプロダクトインクリメントの効率的なデリバリーに責任を負う。
プロダクトオーナーチームを設けることで、関連するスクラムオブスクラムとともにスケールするプロダクトオーナーのネットワークデザインが可能になる。これらの拡張ユニットには特定の用語はなく、チーフプロダクトオーナーの特定の拡張された肩書もない。プロダクトオーナーチームやチーフプロダクトオーナー向けの用語や肩書は、各組織で独自に設定することを奨励する。
アジャイル組織全体に対してプロダクトオーナーの役割を果たすために、チーフプロダクトオーナーは、エグゼクティブメタスクラムイベントでエグゼクティブや主要なステークホルダーと会合する。
このイベントは、メタスクラムパターン5から派生している。これは、リーダーシップとその他のステークホルダーが、自らの好みをPOチームに伝え、優先順位を交渉し、予算を変更し、チームを再編成して価値の提供を最大化するためのフォーラムである。スプリント中の他のタイミングでは、こうした決定を行うべきではない。
エグゼクティブメタスクラムでは、リーダーの動的グループが、組織のビジョンと戦略的な優先順位を設定し、共通のゴールに沿って全チームの方向性を揃える。効果的に行うために、チーフプロダクトオーナーがファシリテートし、各チームのプロダクトオーナー（またはその代理）が出席しなければならない。このイベントは、スクラムオブスクラム内でバックログの方向性を揃えるために、必要な頻度で行う（少なくとも各スプリントで1回）。理想は、このリーダーのグループがスクラムチームとして活動することである。
複数のスクラムオブスクラムが存在する大規模な実装の場合、エグゼクティブメタスクラムで戦略的バックログの作成と優先順位付けがされた、複数のメタスクラムが存在する可能性がある。
プロダクトオーナー組織（プロダクトオーナー、チーフプロダクトオーナー、エグゼクティブメタスクラム）は、プロダクトオーナーサイクルの以下の固有コンポーネントの要求を満たすために全体として機能する。
魅力的なビジョンは顧客と優秀な社員の両方を引きつける。よって、社内外の両方に伝達される戦略的ビジョンは、以下のゴールで策定する。
チームが調整された方法で機能して価値の提供を最適化するためには、バックログに適切な優先順位を付けることが不可欠である。優先順位の相反は、チームを反対の方向に進ませるため、無駄を生み出す。バックログの優先順位付けのゴールは以下の通り。
チーフプロダクトオーナーのバックログには、個々のチームのバックログより範囲の広いアイテムが含まれる。優先順位付けされたアイテムを個々のチームに引き込むには、分割して理解を深めることが必要な場合がある。バックログの分割とリファインメントのゴールは以下の通り。
リリースプランニングには、顧客へプロダクトを一度ではなく、複数回リリースする場合も含まれ、計画期間は単一のスプリントより長期的である。リリースプランニングのゴールは以下の通り。
この2つのサイクルの最初の交差点は、チームプロセスコンポーネントである。この点から、“What”と“How”の責任は、完成したプロダクトがデリバリーされるまで分離される。これらのサイクルは、プロダクトに対する顧客の反応が解釈されるフィードバックコンポーネントで再度交差する。次のデリバリーサイクルへの適応に関する経験に基づく決定を行うには、ここでメトリクスが必要になる。プロダクトオーナー組織とスクラムマスター組織は、協力して、これらのコンポーネントの要求を満たす。
プロダクトのフィードバックは、プロダクトオーナー組織によって解釈され、プロダクトバックログを更新することでプロダクトの継続的改善を促す。リリースのフィードバックは、スクラムマスター組織によって解釈され、デリバリーの仕組みの継続的改善を促す。フィードバックの取得と分析のゴールは以下の通り。
メトリクスは、特定組織だけでなく、それらの組織内の特定機能にも固有となる場合がある。Scrum@Scaleは特定のメトリクスセットを必要としていないが、最低限のものについて示す。組織が計測すべきものは以下である。
徹底的な透明性は、スクラムが最適に機能するために不可欠であり、組織にその進捗を誠実に評価し、そのプロダクトとプロセスを検査・適応させる能力を与える。
メトリクスと透明性を持つことのゴールは以下の通り。
Scrum@Scaleによる組織デザインのゴールは、フレームワーク自体と同様に、組織をコンポーネントベースで設計できるようにすることである。これにより、マーケットに応じてチームのリバランスやリファクタリングが可能となる。
参考図:
カスタマーリレーションズ、法務/コンプライアンス、人事がこの図に含まれているのは、組織の必要な部分であり、他の全チームが頼る独立したスクラムチームとして存在するためである。
エグゼクティブアクションチームとエグゼクティブメタスクラムの表現に関する注記: この図では、一部のメンバーが両方のチームに在席しているため、重複して表現している。非常に小規模な組織や実装では、エグゼクティブアクションチームとエグゼクティブメタスクラムはまったく同じチームメンバーで構成されている場合がある。
この組織図では、ナレッジチームとインフラストラクチャチームは、各チームにスタッフを配置するには少なすぎる専門家の仮想チームを表している。仮想チームが、共通サービスを提供するチームとして機能する場合、グループとして周りのスクラムチームと調整する。周りのスクラムチームからの要求は各専門分野の仮想チームのプロダクトオーナーを経由して、透明性のある優先順位付けされたバックログとして管理される。重要な点は、仮想チームは、隣同士に座っている個人のサイロではないということである（白抜き五角形で表現されている理由）。仮想チームのチームメンバーは実際のスクラムチームに席を持っており、スプリント中はスクラムチームの一員となる。一方、バックログの配布とプロセスの改善のために、この仮想スクラムを独自に構成する。
Scrum@Scaleは、生産性を向上させ、組織全体が半分のコストで2倍の価値を提供できるように設計されている。合理化されたワークフローを、持続可能なペースで実装し、優れた意思決定を行うと、作業環境が改善され、ビジネスのアジリティが高まり、すべてのステークホルダーにより高い利益がもたらされる。
Scrum@Scaleは、組織にスクラムを浸透させるように設計されている。スクラムをうまく実装すると、Scrum@Scaleをオペレーティングシステムとして使い、組織全体を運営することができる。
ジェフ・サザーランド博士は、スクラムの背後にある原則、複雑系適応システム理論、ゲーム理論、および生物学における彼の研究に基づきScrum@Scaleを開発した。本ガイドの原版は、Jessica Larsen、Avi Schneier、Alex Sutherlandの協力により作成された。以降の版は、多くの経験豊かなスクラムの実践者のフィールドワークの結果に基づいて改良されている。
我々は、IDX社において、スクラムを何百ものチームに広げることを最初に許してくれたことで、スクラムオブスクラムが生まれたと認識している6。PentientKeeper社ではメタスクラムが生まれ7、革新的な製品の高速開発を可能にし、OpenView Venture Partners社はスクラムを組織全体に拡大した8。Intel社は、スケールフリーアーキテクチャ無しには “何もスケールしない”ことを私たちに教え、最大のスクラムチーム製品部門を持つSAP社は、2,000を超えるスクラムチームがともに働くためには、メタスクラムにおけるマネジメントの関与が必須であるということを教えてくれた。
Amazon、GE、3M、トヨタ、Spotify、Maersk、Comcast、AT&Tなどの多くの企業でScrum@Scaleのコンセプトを導入しているアジャイルコーチとトレーナーたちは、異なるドメインの幅広い企業にまたがり、Scrum@Scaleのコンセプトをテストすることに協力し続けてくれている。
