「拡大」と「拡張」は同じではない
- Dominic Price 氏「次の 5 つの思い込みを学びほぐすことで、さらにイノベーティブになれます」
問題を解決せずに人を増やすだけでは、問題の解決は困難になるだけです。しかし、拡大とともに能力を高められれば、それは拡張になります。
数十年にわたり、スクラムガイドはチームや会社がこのようなニーズに対応するための基準となってきました。しかし、スクラムを個別のチームの枠を超えて拡張するには異なるアプローチが必要です。そのために、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 は代表者で構成される仮想チームで、代表者が属する元のデリバリーチームと相互に連携します。標準的な組織階層やプロジェクトベースのチームと比較すると、相互連携に基づくこのチーム構造ではコミュニケーションパスが減少します。目的は、独立した小規模なチームを連携させることです。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 のワーキングアグリーメントを設定する
- 全体および個別の「完了」の定義について合意し、共有する
- 拡張デイリースクラムの焦点を絞り込むため、ルーティンやアジェンダを決定する
- 障害によってブロックされた日数の追跡を開始する
- スケジュールどおりに開始および終了した拡張デイリースクラムの数を追跡する
- リスクを低減し、ほかのチームが参考にできるよう、最初に依存関係があるストーリーを伝えることを重視する
- デモミーティングまでの日数を追跡およびビジュアル化する
実のところ、アジャイルの拡張で正解と呼べるものはありません。しかし、多くの組織がアジャイル拡張のフレームワークを使ってプロセスやチーム、文化を進化させることに成功しています。現在用いられている主な拡張アジャイルフレームワークなどに関する詳細については、アジャイルコーチの大規模アジャイルセクションを参照してください。
