スクラムは、開発チームのメンバ間のコミュニケーション促進において効果的であることを証明してきた。この高帯域のコミュニケーションを、特に大きな組織において、どのようにしてチームを越えてスケールするかという問題は、活発に調査・議論される領域に残っている。Will Read氏(リンク)は、この目標を達成するため、ポピュラーなスクラムのスクラムミーティング(参考記事・英語)の直感的な代替案であるメッシュ型のネットワークを提案した (リンク)。
Will 氏は、スクラムのスクラムは階層的なツリー状のコミュニケーション・ネットワークを作り出す、と指摘した。人々はシステム内の情報の作り手かつ利用者であり、そしてツリーのリーフ・ノードである。この構造は、中央のコントロール・ポイントに情報を引き寄せたり、そこから情報を広めたりする場合は適切に機能する。しかしながら、開発者の作業を調整する方法としては、これは最善ではないだろう。個々の開発者が知っておくべき情報の類は、ツリーの上下に効果的に伝わりそうにない。
Jim は自分のものを書き直さなくてすむように、新しいロギングAPIのことを知っておく必要がある。NULLが許容されることを想定していなかったために Sueが作った関数に渡されるパラメータで問題が発生している、ということをBobは知る必要がある。Daveは、Markが見つけたバグを直すために、 Linuxサーバ群を最新のJava VMに更新する必要があることを知っておく必要がある。そして新しく雇われたMindyは、どこからサードパーティのDLLをダウンロードするのか知る必要がある。
この種の情報は、個人やチームがアドホックに、必要に応じて相互につながるメッシュ・ネットワーク上のほうが流れやすい。次に問題となるのは、この種の情報の流れを促進するメッシュ・ネットワークを企業はどのようにすれば作れるか、ということである。デイリー・スタンドアップ・ミーティングに混ざって参加することは一つのアプローチである。２つ以上のチームが同じコードに対する作業をすることがよくある場合や、あるいは相互に依存しそうな場合は、関係のあるチームのスタンドアップ・ミーティングへのメンバの参加を許可することは理にかなっている。Will氏はいくつかの追加的なアプローチを提案している。
- ネットワークの自己管理を奨励、促進する。
- メッシュのつながりを促進するような方法で、関連する機能のセットをチームに割り当てる。
- あまり一緒に働くことの無いチームのために、オフサイトを予定に入れる。
- 自然とハブとなるものを確認し、ハブを越えたコミュニケーションを促進する。
- 強いつながりのあるチームの間で、人を移動させることを検討する。
Will氏はこの種のコミュニケーション・ネットワークのメリットについて、次のように説明している。
このメッシュ・ネットワークを通して、企業はもっと適応的なコミュニケーション構造をたくさん作ることができるが、それはより確実に知識を広め、コミュニケーション失敗のリスクは最小限で、どんな規模の企業でもスケールする方法で限られた帯域の問題に取り組む。特に、これは自己組織化のアジャイルの原則に合っており、あなたのビジネスをさらに良くする方法で無駄を省く。
説明されているように、メッシュ・ネットワークは開発者間の情報の流れを促進するために設計されたものであり、管理のための状況報告のためではない。後者のためであれば、ツリーはまだ望ましいアプローチかもしれない。もしもコミュニケーションの中心が状況や進捗、優先度の周辺にあれば、必要とされる帯域の総量は大きく減るだろうが。
あなたの組織のスクラムチームでは、お互いにどのようにコミュニケーションをとっているだろうか？それはどのくらいうまく機能しているだろうか？どうすればもっと良くなるだろうか？コメントを残してコミュニティと共有して欲しい。
原文はこちらです：http://www.infoq.com/news/2008/12/scrum-of-scrums-alternative