スクラム・オブ・スクラムズ

スクラムの拡張方法

Jira のスクラム テンプレートで重要なことに優先順位を設定

実施すべき作業をすべて可視化することで、最大のインパクトを与える作業に集中できます。

重要ポイント

  • Scrum of Scrums は、共通のゴールに向けて取り組む複数のチームを調整するための大規模なアジャイル手法です。

  • この手法には各チームの代表者が関与し、定期的にミーティングを開いて、依存関係、リスク、統合の課題に対処します。

  • 主要な役割にはチーフ製品所有者と Scrum of Scrum マスターがあり、大規模な連携とデリバリーをサポートします。

  • Scrum of Scrums を利用して大規模プロジェクトを同期し、チーム間のブロッカーを解決し、統合されたソリューションを提供します。

「拡大」と「拡張」は同じではない

ただ人を増やすだけでは、問題の解決は困難になるだけです。しかし、拡大とともに能力を高められれば、それは拡張になります。

数十年にわたり、スクラムガイドはチームや会社がこのようなニーズに対応するための基準となってきました。しかし、スクラムを個別のチームの枠を超えて拡張するには異なるアプローチが必要です。そのために、SoS とも呼ばれる Scrum of Scrums 手法が生み出されました。

Scrum of Scrums の歴史

Scrum of Scrums 手法は、1996 年に、最初にスクラムフレームワークのパイオニアである Jeff Sutherland 氏と Ken Schwaber 氏の 2 人によって導入されました。Sutherland 氏と Schwaber 氏は、それぞれ複数の製品ラインを持つ 8 つのビジネスユニットを調整し、各チーム間を同期させる手段を必要としていました。そこで 2 人は、この目標を達成するためにスクラムチームを拡張する新たな方法を試してみました。Sutherland 氏は、この経験に基づいて 2001 年に「Agile Can Scale: Inventing and Reinventing SCRUM in Five Companies (アジャイルは拡張できる: 5 つの会社におけるスクラムの発明および改革)」という記事を発表し、Scrum of Scrums を初めて公に発表しました。

それ以来、Scrum of Scrums はアジャイルの拡張に密接に関連する手法として人気を高めてきました。Scrum@Scale ガイドに記載され、その他の拡張アジャイルフレームワークでも参照されているこの手法は、チームの拡張を支える基盤となっています。

個別のチームレベルでスクラムの実践に苦労している場合、この手法をより大きなチームに拡張しないでください。アンドンコードを引き、拡張を開始する前にチームの課題を解決しましょう。

Scrum of Scrums とは

Scrum of Scrums とは、複数のチームが協力して複雑なソリューションを実現する必要があるときに、その連携方法を提供する拡張アジャイル手法です。

この手法に従うことにより、チームは透明化、点検、適合により、複雑な製品を大規模に開発および提供できます。パフォーマンスの高いすべてのスクラムチームメンバーが共通の目標に向かって力を合わせ、信頼と尊敬に基づいて完全に連携することで、特に大きな成果を達成できます。

この手法を導入する場合、チームの規模が非常に重要です。Hackman 氏と Vidmar 氏の調査によると、理論的には 4.6 人が「最適なチームの規模」になります。小さすぎたり、大きすぎたりするチームは、複雑な製品の提供に苦労する可能性があります。

個別のチームレベルでスクラムの実践に苦労している場合、この手法をより大きなチームに拡張しないでください。アンドンコードを引き、拡張を開始する前にチームの課題を解決しましょう。

チームが大きくなるほどチームメンバー間のコミュニケーションパスが増えるため、信頼を構築し、目的を統一することが難しくなります。

コミュニケーションパスが増えることによる拡張スクラムチームへのデメリットを示す図

そのため、非常に大きなチームを 2 つか 3 つの小さなチームに分割することで個人間の関係を構築し、望ましい結果を維持できます。

個別のチームレベルでスクラムの実践に苦労している場合、この手法をより大きなチームに拡張しないでください。アンドンコードを引き、拡張を開始する前にチームの課題を解決しましょう。

共通の目的を達成するために複数のチームが編成される場合、調整が必要です。そこで Scrum of Scrums が必要になりました。

スクラムと Scrum of Scrums の違い

スクラムは、単一のアジャイル チーム内で作業を管理するためのフレームワークで、スプリントを通じて段階的な価値を提供することに焦点を当てています。一方、Scrum of Scrums とは、複数のスクラム チームが大規模なプロジェクトで共同作業する際に使用される調整手法で、チーム間のコラボレーションと調整を可能にします。

スクラムは 1 つのチームの毎日のスタンドアップ ミーティングとスプリント サイクルを中心に展開されるのに対し、Scrum of Scrums では各チームの代表者が集まり、依存関係、リスク、統合ポイントについて話し合います。このアプローチにより、組織はアジャイル プラクティスを拡張し、共通の目標を持つ複数のチーム全体で透明性を維持できるようになります。

Scrum of Scrums の目的

Scrum of Scrums は代表者で構成される仮想チームで、代表者が属する元のデリバリーチームと相互に連携します。標準的な組織階層やプロジェクトベースのチームと比較すると、相互連携に基づくこのチーム構造ではコミュニケーションパスが減少します。目的は、独立した小規模なチームを連携させることです。Scrum of Scrums を実践するチームはデリバリーを調整するだけでなく、各スプリントの終了時に完全に統合された製品を提供します。つまり、Scrum of Scrums は顧客に価値を提供するリリースチームとして機能します。

多くの組織は、アジャイルを拡張し、大規模で複雑な製品を提供するための最初のステップとしてこのアプローチを採用します。

代表者を中央、デリバリーチームを周辺に配置した Scrum of Scrums チームの構造を示す図。

Scrum of Scrums への参加者

Scrum of Scrums の参加者は通常、スクラム チームの利益を代表し、情報をグループに持ち帰ることができる、指定されたチーム メンバーで構成されます。これらのメンバーは連絡役としてチーム間の情報伝達を円滑にするとともに、チーム間の依存関係を効果的に管理します。

大規模な組織では、複数のチームを統括するプログラム マネージャー、プロジェクト マネージャー、プロダクト マネージャー、またはエンジニアリング マネージャーが参加者として含まれることもあります。 効果的なコミュニケーションと問題解決には、適切な参加者を選ぶことが極めて重要です。代表者は、チームを代表して発言するに足る背景知識を有し、意思決定や問題をエスカレーションに関する権限を持っている必要があります。この役割をローテーションすることで、チームのスキルをより幅広く向上させ、プロジェクトのマイルストーンと成果に対する共有意識を促進することもできます。

Scrum of Scrums - 拡張構造

新たに編成された Scrum of Scrums チームは、スクラムチームとほぼ同じプラクティスを採用し、同じイベントに参加し、同じ役割を担います。統合され、場合によっては出荷可能な製品を各スプリントの終了時に提供するため、アーキテクトや品質保証リーダーなど、追加の役割が必要になる場合があります。

たとえば、チーフプロダクト所有者という役割があります。チーフプロダクト所有者は、プロダクト所有者チームを監督し、総合的な製品ビジョンの策定をガイドします。

この役割に専任者を付ける必要はなく、より幅広い責任をプロダクト所有者に割り当てるだけでかまいません。

もう 1 つの新しい役割が、Scrum of Scrum マスターです。Scrum of Scrum マスターは、ほかのチームに表示される進捗および障害バックログを重視し、障害の優先順位付けと排除、および Scrum of Scrums の継続的な有効性向上を担当します。

これらの新しい役割は、15 分規模のデイリー スクラムを主な話し合いの場として調整、改善、障害への対応を行います。各チームの代表者や製品所有者が、チームにとっての障害、スプリントの目標達成に対するリスク、または他のチームとの依存関係について話し合った後、他のチームでも参考にできる特定された改善事項について話し合う必要があります。

結論と考慮事項

Scrum of Scrums は広く用いられ、スクラムを拡張する主要な手段となっています。拡張の重要な前提条件となるのが、適切なチーム構成と、タックマンの集団発達モデルのフェーズである形成、混乱、統一、機能を通じてチームが成長するために十分な時間とスペースを与えることです。

チームの準備ができたら、以下の事項を考慮することをお勧めします。

  • 拡張デイリースクラムは 15 分以内にし、チームデイリースクラムと同じ形式で行う

  • 拡張デイリースクラムは、最後のチームデイリースクラムの終了後に 15 分間実施する

  • Scrum of Scrums のワーキングアグリーメントを設定する

  • 全体および個別の「完了」の定義について合意し、共有する

  • 拡張デイリースクラムの焦点を絞り込むため、ルーティンやアジェンダを決定する

  • 障害によってブロックされた日数の追跡を開始する

  • スケジュールどおりに開始および終了した拡張デイリースクラムの数を追跡する

  • リスクを低減し、ほかのチームが参考にできるよう、最初に依存関係があるストーリーを伝えることを重視する

  • デモミーティングまでの日数を追跡およびビジュアル化する

実のところ、アジャイルの拡張で正解と呼べるものはありません。しかし、多くの組織がアジャイル拡張のフレームワークを使ってプロセスやチーム、文化を進化させることに成功しています。現在用いられている主な拡張アジャイルフレームワークなどに関する詳細については、アジャイルコーチの大規模アジャイルセクションを参照してください。

推奨

すぐに使える Jira テンプレート

さまざまなチーム、部門、ワークフロー向けのカスタム Jira テンプレートのライブラリをご覧ください。

Jira の全体的な概要

この段階的なガイドで重要な機能やベスト プラクティスを確認し、生産性を最大化しましょう。

Git の基本を理解する

初心者から上級者まで、この Git ガイドを活用して、役立つチュートリアルやヒントで基本を学ぶことができます。