スクラム・オブ・スクラムは、複数のチームが関係しているときにデイリー・スタンドアップ・ミーティングをスケールするために用いられる。その目的は、チーム間で協同し作業を連携するアジャイルチームを支えることだ。何人かの執筆者が、スクラム・オブ・スクラムを用いた経験をもとに、それに対する見解を述べている。
Charles Bradley氏は悪く言われすぎなスクラム・オブ・スクラムの復興についてブログ記事を投稿した。記事の中で彼は、スクラム・オブ・スクラムが、同じプロダクトのために共に働き計画（再計画）したり開発作業を連携したりする複数のチームにとってどのように役に立つかを説明し、こう述べている。
開発チームにフォーカスしたやり方は、スクラムの背後にある原則を守り、チームレベルでのデイリースクラムのプラクティスの原則を守りながら、結果的に顧客により多くの価値をもっと早く届けられるものだと私は信じているし、実際にそれを経験してきました。私の経験では、開発チームによる開発チームのための効果的なスクラム・オブ・スクラムは、結果的に開発チームの自己組織化スキルの大きな押し上げにつながり、障害物はより素早く取り除かれ、プロダクトはより品質が高くなり、より価値のあるプロダクトがより早く届けられるようになります。
Charles氏は彼のブログ記事の中で、Ken Schwaber氏、Mike Cohn氏、Craig Larman氏、Bas Vodde氏、Jesse Houwing氏のスクラム・オブ・スクラムに対する見解をまとめました。スクラム・オブ・スクラムは開発チームのメンバーが自己組織的なやり方で連携し協力しあえるようにすることに焦点を合わせるべき、つまり、スクラムマスターの状況ミーティングにしてはいけないと、彼は結論づけています。
私がスクラムチームをコーチする場合、スケールさせるときには、スクラムの根底をなす原則を遵守することに非常に重点を置きます。スクラムマスターがスクラム・オブ・スクラムに出席するのがまったく初めてという場合は、開発チームのメンバーの「輪の外に」立つようにさせ、メンバーが協力しあっている間は彼らと目線を合わせることを避けるようにさせます。私はスクラムの原則に基づくスケーリングというものが正しいと思っているので、個々の開発チームのデイリースクラムにおいても、同じテクニックでスクラムマスターをコーチすると言ってもおそらくあなたは驚かないでしょう。私は、開発チームのメンバーがお互いに連携し協力することを目指して、真の自己組織化をする権限を与えられることを望んでいます。もちろん私はスクラムマスターがサーバントリーダーになるように、また、求めや必要に応じファシリテートできるように指導します。しかし同時に、開発チーム自身が彼らなりの効果的なスクラム・オブ・スクラムというものを獲得でき次第、スクラムマスターには影を薄くするように促すのです。
Robert Galen氏は効果的なスクラムによる生産組織の組織パターンパート2というブログ記事の中で、大規模な製品開発組織がチームのスクラム・オブ・スクラムと生産組織を連携させるための解決法を提供している。彼は連携を完了するまでは3つの段階があると述べる。
- 最も低レベルな段階では、チームごとにプロダクトオーナーがいます。複数のチームの能力に合わせて1つのプロダクトバックログをやっつけています。
- スクラム・オブ・スクラムの段階では、プロダクトオーナー同士が協同する必要があります。そこには「リードPO」の役割があることが多く、プロダクトオーナーのうちの1人がいくつかのバックログをまたぐ集合ビューの舵取りをしています。
- スクラム・オブ・スクラム・オブ・スクラムの段階では、チーフまたはスーパープロダクトオーナーがいることが典型的で、その人が経営レベルのビジネスロードマップと納期のコミットメントをチームが実行するレベルにまで連携させています。スクラムデリバリーチーム（複数の場合も）の認識したコミットメントと、実際のベロシティの差分を追跡し、その均衡を維持することが多いです。
どんな段階であれ、スクラムチームとプロダクトオーナーの間の連携を確立することは、大規模組織へのアジャイルの導入の支えになる。
このパターンの本質はやはり組織的変革なのです。効果的な生産組織は、その組織構造と技術チームがプロダクトを届け続けている方法とを再連携させます。その途中で、スクラムチームを通して仕事を進めるためには、どのようにバックログを組み立て分解しまた組み立て直すのかを知るのです。
Giuseppe De Simone氏はスクラム・オブ・スクラムの神話という記事の中で、アジャイルのスケーリングについての神話に触れている。たとえばこんなものだ。
スクラムをもっと多くのチームに広げるときは、スクラム・オブ・スクラムでチーム間の依存関係と対等関係を管理しましょう。
氏は、チーム間の連携の必要性を軽減するためにスクラムチームが行うことをいくつか挙げている。
実は依存性はスクラムで対処でき、実際に無くすか少なくとも最小限にすることができます。これはいろいろな次元で行われますが、ここに鍵となる必須のものを5つ挙げます。
- まず始めに、開発チームは機能横断的でなければなりません。つまり、1つのプロダクトバックログアイテムを出荷判断可能なインクリメントにするために必要とされるすべての能力を、持っているということです。これはコードの共同所有のプラクティスを取り入れることで補われます。スプリントの終わりにプロダクトのインクリメントを届けるために必要なことであれば、誰もがコードのどこを触ってもいいのです。つまり、さもなければ、チームを外部からのたくさんの依存性で制約してしまうことになります。
- バックログアイテムはエンドツーエンドのユーザーストーリー形式にしてあげましょう。フロントエンドからバックエンドに至るすべてのレイヤにまたがってシステムを切り取り、出荷判断可能な機能の断片を作るためです。つまり、コンポーネントベースの開発はものすごい依存性を生じます。
- ユーザーストーリーはINVESTにしてあげましょう。IはIndependent（独立）のIです。これで仕事がやりやすくなります。
- 大規模スクラムのやり方では、プロダクトオーナーチームが唯一のプロダクトバックログを展開してすべての開発チームに与え、可能な限りその独立性を確保します。そうすると、チーム間の連携がほとんど必要なく、もっと早く前に進めるようになります。
- スクラムチームは一緒になって計画します。それによって残りの依存性が可能な限り早く検出されるのです。
スクラムチームにこれらのことをさせることで、スクラム・オブ・スクラムをやる必要性やその目的は変わってくる。
それは何らかの状況を報告するためのスクラムマスターのミーティングではなく、問題を抱えた人にとって、その手を挙げて他のチームからの早急な援助を得るための可能性なのです。
（スクラム・オブ・スクラムは）もう何度目かもわからないような調整機構ではなく、それよりもむしろ、あるチームが他のチームに助けを借りるとき、または借りようとするときに取る緊急手順なのです。
Morgan Ahlström氏はスクラム・オブ・スクラム – コミュニケーションの温度計というブログ記事の中で、スクラム・オブ・スクラムを使って得られた経験を記した。彼の説明によるとそのプロジェクトは、3カ国にまたがる7チームで定期的にスクラム・オブ・スクラムをおこなっている。
すべてのスクラムマスターとプロジェクトマネージャーは週3回のテレビ会議をおこない、そこではスクラムマスターが代わる代わる状況報告をして（！）彼らの抱える問題について不平を申し立てていました。一部のスクラムマスターが私に歩み寄り、「とくに新しい話題が出るわけではない。同じ問題が毎回のミーティングで持ちだされるだけ」なのだから、ミーティングの頻度を減らしてはダメかと尋ねてきたことがあります。
チームはミーティングの間に問題を解決できていなかったように思われた。Morgan氏は、スクラムマスターはスクラム・オブ・スクラムで不平を申し立てるのではなく、課題を書き留めそれに取り組むことを始めよと提案した。彼はまた、スクラムマスターたちが直接集まってお互いのことを理解できるような機会を用意した。
私はスクラムマスター全員を自分の元に呼び寄せるために何とか資金調達をし、レトロスペクティブとその他いくつかのワークショップをおこないました。これは人々がお互いのことを理解する素晴らしい日となりましたが、それでもまだ十分ではありませんでした。ある日も終わりに近づいた頃、誰かこの部屋の中でここにいる他の誰かを短縮ダイヤルに登録している人はいないかと聞いたのですが、ゾッとしたのは、誰一人として他の人の電話番号を知っている人がいないという回答でした。この問題を解決するのは簡単です。問題は、全員に電話番号を使わせるようにすることなのです。
話すべき課題があるかどうかに関わらず、少なくとも他のスクラムマスターを訪問して、彼らがどんな風にやっているのかを見るべきだったのです。これはすぐに実現できるものではありません。たとえば、ほとんどの人は電話をかけずに逃げおおせると思っていたようです。しかし私は彼らとマンツーマンの時に、そうするように求め続けたのでした。
Morgan氏は、スクラムマスターがお互いの関係を確立してからは、さらに多くの課題が解決されていたと言っている。
（中略）スクラム・オブ・スクラムに持ち込まれる問題は日に日に少なくなりました。代わりに人々は社会的な議論をし、問題について過去形で語っていました。（中略）まだかなりの課題も残っていましたが、今やスクラム・オブ・スクラムの外で解決されていました。チーム（もしくは少なくともスクラムマスターたち）は、お互いを気遣い始めました。あるチームは、別のあるチームが勇気を出して外部に助けを求めるよりも前に、海外にいるそのチームに開発者を何人か送って手伝うことを提案さえしたのです。
1ヶ月あまりの間に私たちは、課題の連携や問題の解決に何の役にも立たなかったミーティングをおこなっていた状態から、連携する課題もなく解決する問題もないというミーティングを開催する状態に変貌を遂げたのです。これによって私は、デイリー・スタンドアップやスクラム・オブ・スクラムそれ自体はあまり解決手法にはならないかもしれないが、むしろチーム間のコミュニケーション、つまりミーティング以外の部分がどれだけうまくいっているかの指標にはなるかもしれない、とつくづく思いました。
あなたはスクラム・オブ・スクラムを使いますか？ あなたのところのチームが互いに連携し協同するために、それはどのように役立つでしょう？