調整と統合

従来のプロジェクトマネージメントでは管理された調整が行われてきました。スクラムでは集中管理ではなく、分散と自己組織化された調整と統合に価値があると考えます。LeSSでは必要十分な境界線と構造を提供し、カオスな状態になるのを回避し、分散型で調整が可能な状態になることを重視しています。

ただ話す

チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。

コードでのコミュニケーション

LeSSを導入しているグループでは継続的インテグレーションが取り入れられており、全てのコードは１つのレポジトリにチェックインされています。ブランチは不必要な複雑性を生むので使わないことをオススメします。全員が日に数回はレポジトリと同期し、他の人が行った全ての変更を取り込むようにします。updateをした時に2分程度の時間を使って他の人の作業と自分の作業が被ってないか確認します。もし、作業が被っていそうであれば、ぜひ席を立って、「ただ話す」をしに行って同じ箇所を触っている人と作業の調整をしてください！

オブザーバーをデイリースクラムに送り込む

チーム間の簡単な調整の方法の１つがスクラムマスター以外の代表者を関係する仕事をしているチームのデイリースクラムに発言しないオブザーバーとして送り込むことです。そして、代表者が自分のチームに戻ってチームに内容を共有し、次のアクションにつなげます。

コンポーネントのコミュニティとメンター

同じコンポーネントを扱っている人達は質問したり、コードレビューを相互にする為に、お互いを知っておく必要があります。これはコンポーネントのコミュニティ・オブ・プラクティス(CoPs)を作ることで対応していきます。CoPsはメーリングリスト、チャット、ミーティングや、様々なリーモートでの協働方法を用います。

これらのコミュニティは殆どの場合、コンポーネントメンターにより組織されます。コンポーネントメンターはフィーチャーチーム内で次の様な役割を担うことがあります。（１）コンポーネントがどのように機能しているのかを教える先生役、（２）中長期的にコンポーネントの健全性が維持されるようにメンターとなる、（３）コンポーネントのコミュニティを主催する、（４）設計のワークショップを主催、（５）コードのレビュー。

コンポーネントメンターがコードレビューを行うのは、コミット前に承認をする為ではありません。彼らは先生であり、世話役なだけで、門番ではないのです。

１つのコンポーネントに複数のメンターがいる場合もあります。複数人いることにより、１人当たりの仕事量も減らせますし、キーマンに依存する状態も回避できます。

すごく重要な点ですが、調整をサポートする以外にもこれらの活動がコンポーネントのコードや設計などの品質を維持、改善し、学習を促進することに繋がります。

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

スクラム・オブ・スクラムズのミーティングはチーム間向けのミーティングで週に２～3回実施されます。

多くの場合はデイリースクラムのように下記の３つの質問がされます。

他のチームに関係あることで、どのようなことを私のチームは行ったか
他のチームに関係あることで、何を行うか
他のチームに知っておいて欲しい、又は助けて欲しい私のチームの課題は何か

これらの質問はグループにとって有用な質問に変わっていくことが多いです。

注意点：スクラム・オブ・スクラムズが必要だと感じるのは、コンポーネントチームやシングルファンクションのグループになってしまっているか、協働が出来てないか、協働しようと思わない環境になってしまっていることにより、不必要な依存や調整が発生してしまっている兆候かもしれません。

スクラム・オブ・スクラムズはLeSSの一部ではありません。どちらかというと、集中管理をする方法ですし、オススメもしませんが、スクラム・オブ・スクラムズで上手くいっているのであれば、やめる必要もありません。ただ、LeSS導入に必須ではないということです。

複数チームのミーティング

いくつかのチームが密接に連携する必要があるが、他のチームはそれほど密接に連携をする必要がないという状況がよくあります。密接に連携する必要があるチームが下記のようなミーティングを一緒におこなうことはよくあります。

複数チームプロダクトバックログリファインメント
複数チームスプリントプランニング２
複数チーム設計ワークショップ
デイリースクラムで相互にメンバーを送り合う

トラベラーを活用してボトルネックを解消し、スキルを伸ばす

プロダクトグループは数名の経験豊富な技術的なエキスパート達を頼みにしていることがよくあります。このように全てのチームから必要とされているが、十分な人数がいない時に、全てのチームが彼らの知識を使える状態にするにはどうしたら、良いのでしょうか？彼らにはトラベラーになってもらいます。毎スプリント彼らには別のチームのメンバーになってもらい、ペアを組んでコーチしてもらったり、ワークショップを開催してもらったり、技術的な教育をしてもらいます。

そして、よく勘違いされるのですが、トラベラーは直接的な調整役を担うわけではありません。彼らは複数のチームに入ることによって、入っているチームが他のチームとの幅広い関係性を作ったり、既存の関係性を強化することをにより、形式ばらない相互での調整を可能にしていきます。彼れらの活動を通じて、チームを横断して、知識や技術の習得を促進し、チーム間の調整も可能にしていきます。

リーディングチーム

いくつかの領域では、フィーチャーはすごく大きい場合があります。この巨大なフィーチャーを作るには多くのチームが協働しながら小さく分割されたプロダクトバックログアイテムを通じて巨大なフィーチャーを完成させていきます。

巨大なフィーチャーを作るもう１つの方法がリーディングチームです。リーディングチームは通常のフィーチャーチームですが、巨大なフィーチャーを先行する役割を担います。彼らは自分達の開発作業の他に、他チームの仕事内容を確認し、同期を支援する責任を持ちます。簡単にいうと、彼らは巨大フィーチャーを作る上で、自分達の仕事の他にチーム横断での調整を行います。

ときには複数チームが同時に巨大な開発を同時に始めることがあります。又は、リーディングチームが先行して進め、知識を伝え、設計をシンプルにします。数スプリント後にいくつかのチームが合流しますが、リーディングチームは後から合流したチームに彼らが既に知っていることを教えていくことに責任を持ちます。