複数チームでのスクラムを改善するために、Nexusガイドを読んでみました

背景

現在、スクラムで開発をしているのですが、諸般の事情によりスクラム2チーム体制になっているため、ところどころスクラムガイドから外れた内容になっていることが気になっていました。

そんな中、スクラムの規模を大きくしていくための手法として、LeSSやNexusなどがあることを知り、知見を得るために、Nexusの内容をまとめたNexus Guideを読んでみました。

知りたかったこと

いきなりNexusを導入する、というよりは、現在2チーム体制で試行錯誤している内容に対して、改善のヒントがないかな、というイメージで読みました。主に知りたかったこととしては以下となります。

チーム間の情報共有
- チームごとにプロダクトバックログを分けるのか
- スクラムイベントは別々に行うのか、一緒に行うのか
プロダクトオーナーの人数／役割
- チームごとにプロダクトオーナーが必要か
- 全体で1人だった場合、チームとのコミュニケーションに問題がないのか
スクラムで定義されていないチームがないか（基盤チームのような、全体統括のチームが必要にならないか）

Nexus Guideを読んでみての所感

チーム間の情報共有

チームごとにプロダクトバックログを分けるのか

Nexusガイドによると、

複数のスクラムチームが、ゴールを達成する統合インク
リメントを構築するために、1 つのプロダクトバックログに取り組んでいる

とありましたので、プロダクトバックログは1つで良いみたいです。

あくまでも、1つのプロダクトバックログで優先順位を考え、それをどう実現するかを複数のスクラムチームで考えて実施する、ということかなと思います。エリアプロダクトオーナーみたいな考えでは、エリアプロダクトオーナーはプロダクトバックログを分けて持つ、みたいなことを聞いたことがあった気がしたので（違うかもしれないですが）、どっちなのかなと思っていましたが、やはり1つで良いのだなという気持ちです。

ただし、実施する際には各スクラムチームの担当ストーリーを決める必要があるとは思いますので、そういう意味では、一時的に分割されたプロダクトバックログは持つようになるのかもしれないです。

スクラムイベントは別々に行うのか、一緒に行うのか

必要に応じて全員集まったり、代表者が集まったりする、というイメージかなと認識しています。全体で調整が必要なものは代表者が集まり、そうでないもの（例えば、スプリントレビュー）は、全員集まるという形みたいです。まあ、いつも全員集まったら色々なコストがすごいことになるので、代表者が集まる、というのも分かる気はします。逆に言うと、全員集まれるぐらいの人数なら、代表者を集まる必要もないのかな・・・・

私のそもそもの疑問としては、全く交わらずに別々でイベントを実施する、という可能性もあるかなと思っていたので、そういう意味では、相互の影響を気にしながらイベントを実施していく、という考えのようです。（そりゃそうだよな、という気持ち）

プロダクトオーナーの人数／役割

チームごとにプロダクトオーナーが必要か

これは、はっきりは書いてなかったと思うのですが、Nexusガイドの表紙にも書かれている図を見る限り、各スクラムチーム内にもプロダクトオーナーが書かれているので、各チームごとにプロダクトオーナーが置かれるように定義されているのかなと思います。（もしかしたら兼任という可能性もあるかもしれないですが）

ただ、仮に各チームにプロダクトオーナーがいるとした場合に、その役割がよく分からないんですよね。プロダクトバックログが複数に分かれるなら、（プロダクト全体ではなくて）スコープ限定した範囲での価値の最大化を考える人、みたいに捉えられるかもしれないですが、1つのプロダクトバックログだとすると、その持ち主の代わりに何が出来るんだろうかと思います。。。

全体で1人だった場合、チームとのコミュニケーションに問題がないのか

これは、良く分からなかったですね・・・

1人だと情報伝達や問い合わせへの回答が大変になりすぎないのかな、と思います。

プロダクトオーナーには、複数のスクラムチームで統合され
たプロダクトや作業の価値を最大化する実行責任がある。

プロダクトオーナーは、Nexus で作成する統合インクリメントの価値を最大化するために
、プロダクトバックログの順番とリファインメントに最終的な責任を持つ。そのやり方は、
組織・Nexus・スクラムチーム・個人によって大きく異なる。

などど書かれていましたので、プロダクトオーナーは引き続き、開発チームとうまくやらないといけないけど、具体的にどうするかはケースバイケースだから自分で考えて、ということかなと思います。

スクラムで定義されていないチームがないか（基盤チームのような、全体統括のチームが必要にならないか）

これはNexus 統合チームとして、思いっきり定義されていました。スクラムチームに共通する課題解決や仕組み作りについて、牽引していくチームなのかなと思います。

私のところでは、何となく開発チーム以外（プロダクトオーナーとスクラムマスター）で、こうした課題に取り組むか、プロダクトバックログに追加して、開発チームで対応するか、いずれかでしたので、Nexus統合チームのような存在を改めて定義していくのは良いな、と感じました。

ちなみに、Nexus統合チームに所属するのは、スクラムチームの人で良くて、かつ、通常のスクラムチームの作業よりもNexus統合チームの作業の方が優先される、と明確に定義してあるのが良かったです。（全体に関わるところだから、という理由のようです）

別の疑問（残件）

上記のこと以外にも、気になることが出てきましたが、まだ未消化です。

作業がプランニングよりも順調でなかった場合の考え方
- あるチームだけがNGだった場合、より優先順位の高いものがNGになる可能性もある。これをどう考えるか（仕方ない or 改善する必要あり？）
- スプリントの途中で、あるチームが別のチームを手伝うようなことが発生するのか（あくまでも、チーム内で作業は閉じる？）

複数チームいると、どうしても責任分界点みたいな話になりがちな気がするのですが、考え方としては、チーム力を合わせてプロダクトを成長させる、というのが健全かなと。そのために、より優先順位が高い案件を実施中のチームがNGになりそうな際、自チームの達成を犠牲にしてサポートするべきか、あくまでも役割分担の中でのベストを尽くすべきか（駄目なら駄目で改善していけばよいので、変に複雑にしない）、みたいなことが気になりました。

まあはっきり書いてないということは、ケースバイケースで、どちらもで良いってことなのかな〜