こんにちはこんばんは。スクラムマスターの いのもえ です。
9/11 に「相互依存最大化のすすめ」という LeSS の講演を聴講してきました。

講演内容ざっくりまとめ

コンポーネントチームとフィーチャーチームを比較して、フィーチャーチームのほうが LeSS には向いている、という話だと理解しました。

• プロダクト開発における「依存」とは 2 種類ある

  • (1) チームで作業の進め方を選択できない。作業の順番が他チームに依存している状態。この依存は要注意。チーム間が険悪になることもある。

  • (2) 同じコードやリポジトリを他チームと共有している。作業を進める方法が他チームに依存している状態。この依存はチーム同士の協働の機会や学びを提供してくれる。

• (1) の依存を解消するためにフィーチャーチームを組成するのが良いが、フィーチャーチームになるにはメンバーのマインドセットを大きく変える必要がある（プログラマー→プロダクト開発者へ）

• フィーチャーチームとマイクロサービスアーキテクチャは相性が悪いことがあるので注意（モノリポジトリがおすすめ）

関連情報

書籍の場合は 4.1.2 章が該当してると思います。

特に印象に残ったこと

複数チームでのリファインメントやプランニングの「良い例」がイメージできた

当日はレゴブロックによるスクラムイベントの写真を見ながら、チーム間の依存についてイメージを膨らませました。中でも以下の要素についてはかなり印象に残りました。

• スプリントプランニング 1 で自分たちの得意な PBI をとるのではなく、 PBL から今後のことを想像して「LeSS チーム全体でスムーズに進めるには」という立場で発言しているチーム代表者

• 同じ部屋で各チーム代表を集めたミックスグループを複数作り、ミックスグループでリファインメントを実施している様子（これにより、チームで PBI について 1 人は知っている状態にする。また、プランニングでも発言できるようになっていく）

また、架空のチームを想定して写真を提示してのストーリーテリングによる説明が非常に強力で、自分でワークショップをやるときにも取り入れてみたいと感じました。

実際の資料も是非見ていただきたいですがこの記事を執筆している時点では未公開なので後ほど追記するかもしれません。

軸があると良さそう

全編を通して、「他者との協働は楽しいという」メッセージがよく伝わりました。 Bas さんはコロナ禍中いちエンジニアとして開発業務にあたっていたそうなのですが、これは御本人が他者との協働を非常に気に入っていらっしゃるからなのではと容易に想像できました。

このような「軸」を持つのは非常に有用そうだと感じました。他人に物事を伝えるときには強力なメッセージになってくれますし、自分の機嫌をとるときやキャリアの方向を決めるときにも自分を支えてくれそうだなと。まさに軸！

自分のレベルアップを感じた

スクラムマスターにキャリアチェンジしてから 1 年未満なこともあり、「自分はまだまだだ」と落ち込むことも多かったのですが、 LeSS やスクラムの前提がほとんどスキップされている講演でもスイスイ聞けるようになっていたところにかなり成長を感じました。こういうのはシンプルに嬉しい。

キャリアチェンジした話 ↓

〆

総じて楽しい 2 時間を過ごせたので行ってよかったです！
原則を知って解釈を意見交換するの楽しいのでもっとやりたいな〜