Agile Estimating and Planningの著者のMike Cohn氏(リンク)が「スクラムを大きなプロジェクトチームに適用させるのに重要な技術」と説明しているのが、スクラムのスクラムミーティング(the Scrum of Scrums: 以下SoS)である。これらのミーティングをすることで、いくつかに別れたチームが仕事について議論したり、チーム間で統合が必要な箇所や、オーバーラップしている箇所にフォーカスすることができるようになるのである。
Allan Shalloway氏(リンク)は"Lean Software Development: Scaling Agile to the Enterprise"(リンク)という書籍を執筆している。彼は「チーム間の調整にスクラムのスクラム(成功経験あり)と、スクラムをエンタープライズにスケーリング(これに関しては、何人かの人がいくつかの理由をあげてできないということを述べている)の２つの方法について、人々の経験を知りたいと思っていた。 Allan氏は巨大なグループ(とある例では350人)がスクラムを実施する場合に発生しうる問題を発見している。共有の共通コンポーネントを使用している、いくつかの異なる製品があるという状況の事例について、彼は発生している問題の中から３つの例について言及した。
- 技術レベル：繰り返し型の開発をしていると、チームは統一された設計原則からはどんどん離れて、突発での設計をしたくなってきます。これは品質の高いコードを書いているが、望んでいるレベルまで機能性や、設計構造を追加することができていないということを表しています。もしかしたらAチームは、自分のコードからしか使わないという理由から、インタフェースを使用せずに暗号化の機能を追加してしまうかもしれません。BチームはAチームと微妙に異なる暗号化の機能を必要とするかもしれません。この組織にとってベストな方法は、Aチームが暗号化のインタフェース(最初は必要とされていなかった)を使用しながら改修を行っていく、というものになります。チームBはこれについて最初から知っているということはありえません。しかし、これをやってしまうと、Aチームは、コード改修をして他のチームを助けたことによるインセンティブを得ることはありません。
- チームをまたぐレベル ：様々なチームのために異なるプロダクトオーナーとスクラムマスターがいる場合、どのようにチームが活動していくかというのは常に明確になるとは限りません。この場合は全体像の理解がチーム間の活動の手助けをします。他のチームのためを手助けする仕事をしているコンポーネントのチームがある場合、特にこの効果は大きくなります。ビジネス価値からこのことを実践していくには、プロダクトオーナー全員と話をしていくことが必要になります。これらのチームは協調するかもしれませんが、協調しないとは言えません。
- チーム構造のレベル ： 多くのスクラムチームが一緒に活動している場合、複数のチームが関わっている末端の機能をリリースする時に難しい問題を抱えることになります。私はUI, 中間層, データベースの３つのチームに分かれている状況に出会ったことがあります。チームを機能で分割することにより、より効果的に働けることを目的としていました。組織されたチームは、それぞれの担当の機能の中では独立してなんとか仕事をすることができていました。しかし、それぞれのレイヤーをまたがるような機能に対してはうまく進めることができませんでした。結果としてこれにより末端の機能のビルドは早く進むようになった反面、チームをまたがるような統合の問題をいくつか引き起こすことになりました。この問題に関してはBas Vodde氏とCraig Larman氏の「コンポーネントチームをまたぐ機能チームを選択しよう(参考記事・英語).」という記事もお勧めします。
Mike Dwyer氏(リンク)はSoSとメタスクラムについても同様のことが言えると述べている。「ストーリーを機能ごとに分割して協調して開発を進めるということは、複数のチームが同じ物を開発するのとは違う話です。これらの課題はすべての層における、日々の会話などの頻繁な情報交換によって解決されるものです。」 Dwyer氏の経験によると、きちんと指導されたチームほど、インフラやデータ、アーキテクチャに焦点を合わせるとのことである。その結果として、共有コードを成長させるのに良い仕事をするのである。結論として(リンク)、Dwyer氏は、各リリースのテーマを決めるために、マネージャとプロダクトオーナーが協調して仕事を進めることが重要なカギだと結論づけている。そうすることで、チームを同じベクトルに向けることができ、必要なものをサポートすることができるようになるのである。
Ilja Preuß氏(リンク)はSoSが彼のチームにとって価値があったと述べた。「SoSは、他のチームがシステムに対して行っていることを感覚的に感じるのに役立ちました。一日に一度、すべてのチームから最低一人ずつメンバーが出てきて他のすべてのチームを見るということをしてきました。このSoSによって、お互いにどのチームの手助けができるのか、という状況確認ができました。また、どのチームと一緒に協働する必要があるのか、という状況も確認できました。そして、チームを超えた人のつながりを維持して、我々が同じボートに乗る一員である、という感覚を持ち続けることができました。」
Christophe Louvion氏(リンク)も製品ごとのチームをまたいだ、毎日の統合を管理するのにSoSを使用してきた。サブのプロジェクトのシニアエンジニアによってこのメタチームが結成されていた。このチームは以下のような責務を持っていた。
- 基準の設定(API, サービスレベルの合意(SLA), エラーのログ、コードリポ児鳥の構成、自動ビルドプロセス、すべてのチームで使用される自動デプロイスクリプトなど)
- 自動化されている、毎日の統合テスト
- サブプロダクトをまたいたいだ、コードレビューとアーキテクチャのレビュー
- 大きなリリースにおける初期検討。各チームで未決定の部分に対して、基本となる設計のテストを行わせる。
SoS は実際に動き始めた最初のチームでした。ここを起点にしてスケーリングしていきました。チームは上位の管理チームであった。時間が過ぎると、SoSの各メンバーはサブプロダクトのリーダーとなり、SoSとそれぞれのプロダクトの両方で働くようになり、最後はサブプロダクトに吸収されていきました。
最後に、Walter Bodwell氏(リンク)はSoS成功のためのレシピを公開した。「最大でも15分以内を維持するようにしましょう。そしてテーマを絞りましょう。他のチームが聞きたい/必要としていることは何でしょうか？SoSで最初に参加者が答える2つの質問によって、自分がどのような仕事に取り組んでいるのかというのをお互いに気づくことができます。他のメンバーは提案をすることもできますし、何かに気づかせてくれるでしょう。SoSを短くして焦点をぼけさせないために、ディスカッションは個別にしましょう。何かの障害があれば、解決されるまでSoSの場での議題にしましょう。障害を認識し、緊急度を決めるというのも SoSの大きな利益の一つです」前もってメールで共有しておくと、時差や訛りを超えてSoSを開催する場合に手助けになるということも、彼の気づきの一つである。