はじめに
現在の担当案件ではLeSSというスクラムをスケールした手法を使って、複数チームでプロダクトをつくっています。前職時代にLeSSを使っていた時以来、2年ぶりに公式サイトを訪問したところ、2024年3月に（小さな）ルール変更がされていたことに気づきました。
LeSS is 何?
書籍から引用します。
LeSS（Large-Scale Scrum）は１つのプロダクトを複数チームで協働するために考えられたフレームワークです
引用：書籍「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」
LeSSは原理・原則、フレームワーク（少しのルール）、ガイド、実験から構成されていて、原理・原則の中に
Large-Scale Scrumはスクラムである
と記載されています。
スクラムの原理・原則、目的、要素を大規模開発の文脈に可能な限りシンプルに適用したものです。スクラムと同様、必要最低限のことしか決められておらず、継続的に学習しフレームワークの枠内でプロセスを改善していくものだと認識しています。
LeSS独自のルールの例として、いくつかのイベントが「全体」と「チーム毎」で定義されていたりします。
どんなルール変更？
公式サイトからルール変更についての言及を引用します。
※日本語ページは2024年7月中旬現在、まだ変更が反映されていないようです。（単純に漏れているのかもしれないので、あとでコンタクトしてみよう。）
LeSS Rules Changes
Changed from December 2020 to March 2024:
- Removed “or Team representatives” from the Sprint Planning One rule. The rule suggests that representatives is a good option whereas in practice it often causes some negative dynamics so removed from the rules.
- Removed “majority” from the feature teams rule. It is such an exception to not have all feature teams that the word majority gives the wrong impression.
日本語訳 ※このQiita記事筆者の翻訳なので何卒ご了承を
LeSSのルール変更
2020年12月から2024年3月に変更された点：
- スプリント計画1のルールから「又はチームの代表」を削除しました。このルールは代表が良い選択肢であることを示していますが、実際には、しばしば良くない相互作用（dynamics＝相互作用と訳してみた）を引き起こすため、ルールから削除しました。
- フィーチャーチームのルールから「大多数」を削除しました。すべてのフィーチャーチームが参加しないのは非常に例外であるため、「大多数」という言葉は誤解を与えるので削除しました。
ルール変更の2つ目（Removed “majority”...）については誤解を招く表記を修正した（だけ）と個人的に理解したので、ここからは１つ目（Removed “or Team representatives”...）について、書こうと思います。
以下は公式サイトの日本語ページ（2024年7月中旬時点）からのスプリント計画に関する引用で、変更に伴い太字の部分が削除されたことになります。
- スプリント計画は２つのパートに分かれる：スプリント計画１は全てのチームが一緒に行う。但し、スプリント計画２は各チームに分かれて別々で行う。ただし、関連性が強いアイテムを開発するチームは複数チームでの計画を同じ場所で協働して行う。
- スプリント計画１はプロダクトオーナーと全チーム
又はチームの代表にて行われる。各チームが次のスプリントで何をするかを選び、他チームと協働する機会がないかを検討したり、不明確な点があれば質問をして明確化をおこなう。- 各チームはチームごとのスプリントバックログを有する。
- スプリント計画２は各チームがどのようにアイテムを実現させるかを考える場なので、設計をしてスプリントバックログを作る事になる。
補足として・・・
- １つめの「全てのチーム」といっているのは、３チームあったとしたら単純に「チームAとチームBとチームC」のこと。２つめの「全チーム」といっているのは、「チームAのメンバー全員＋チームBのメンバー全員＋チームCのメンバー全員」のこと。（英語版を見ると"all teams"や"Teams"という区別がある）
- LeSSで「チーム（Team）」と出てきたら、スクラムガイドでいう開発者（Developers）を意味している。
- スクラムマスターはチームメンバーではない。（参考：書籍「大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法」）
スプリント計画１の参加者はPOとチーム代表だけでもオッケ～！としていたのを、やっぱり良くないのでPOとチームメンバー全員ね！ となりました。
変更に至った実践者たちの学びとは？
つまりsome negative dinamicsとは何なのか、です。
The LeSS CompanyのSNSアカウントの投稿に以下を見つけました。
～前略～
After a lot of experience with team representatives, we come to the conclusion that more often than not they lead to some negative dynamics. The most common one is that it leads to the individual teams to prepare for the SP1, which then makes it a much less collaborative event than it ought to be. Most Sprint Planning One eventually has all the teams anyways and it tends to be a short meeting, immediately followed with SP2. We feel the rules should reflect the common situation.
Now this rule reads: "Sprint Planning One is attended by the Product Owner and Teams. They together tentatively select the items that each team will work on that Sprint. The Teams identify opportunities to work together and final questions are clarified"
～後略～
要約すると、
（最もあるあるなのは）チーム代表を用いると、各チームがスプリント計画１のために個々に準備し、スプリント計画１自体は短く終わり、直ちにスプリント計画２に移る。イベント自体があるべき協働的なものにならなかった。
ということのようです。
各チームごとに事前準備した「次のスプリントで何をするかを選び、他チームと協働する機会がないか」の内容を、チーム代表が「共有すること」が目的になってしまったのかと想像します。そうなると、POや他チームと協力して議論や決定をすることが無くなって、多様な視点を活かすのが難しくなったのかな、と思いました。
大規模な場合に「チーム代表」が効率的に思えても、世界中の実践者たちの経験上その手段は全体最適にならなかった、ということでしょう。
個人的にはチームメンバーのオーナーシップが希薄化してしまう、ということもある気がします。スプリント計画はスプリントの起点になるイベントで、POとゴールを合意したりしますよね。その場にいないコンテキスト不足が、気が付いたら負債のようになっていた、過去そのような経験をしたことがあります。
おわりに
小さいけれど考えさせられるルール変更でした。
変更内容にただ従うのではなく、変更の背景に思いを巡らせることで、自分たちのやり方を検査するきっかけにもなると思いました。相互作用そのもの、イベントの目的、さらに、自分たちが置かれている環境（スクラムが適している複雑な領域に、そもそも今もいるのか？多様な視点を活用する必要性があるのか？）なども検査の対象になりえるかもしれません。
公式サイトの日本語ページのアップデートリクエスト、送信完了です。
参考