社内向けに言語化したのもをせっかくなのでこちらでも言語化しておく
LeSS
- 「LeSSはスクラムである」と公式サイトでも言われるように、通常のスクラムを拡張したシンプルなフレームワーク
- 8チームまでを想定しており、それ以上のチームになると「LeSS Huge」
- 1つのプロダクトバックログ、1人のプロダクトオーナー、複数の開発チーム
- リファインメントやレトロは、各チームごとと全体でそれぞれ実施
Scrum@Scale
- チームごとにプロダクトバックログ＆プロダクトオーナーを持つ
- 「単一のスクラムに、チーム間連携の仕組みを追加したもの」
- プロダクトオーナーをスケールする仕組みを持つことがLeSSとの大きな違い
- WHAT領域のプロダクトオーナーをスケールさせる仕組み（= プロダクトオーナーサイクル）と、HOW領域の開発をスケールさせる仕組み（= スクラムマスターサイクル）という概念がある
- イベントをチームごとと全体で実施するのはLeSSと一緒
発散的メモ
- LeSSの「1つのプロダクトバックログ」とはどういう状況なのだろうか。うちでは一応Jiraプロジェクトとしては1つだが、チームごとにフィルター分けて管理している。これは1つのプロダクトバックログというのだろうか
- ツール起点で考えるのは本質的ではないが、「1つのプロダクトバックログ＆チームごとにスプリントバックログを持つ」はJiraだとどう表現されるのか気になる。もしかしたら今がそうなのか
- 今はチームごとに独立して何を作るか決めている（他チームのイシューとは分けて優先度付けしている）ので、今のうちの状況はおそらくScrum@Scaleに近そう
- そうなると、チーム間の連携（プロダクトオーナーサイクル/ スクラムマスターサイクル）をうまく回す仕組みがないと全体として正しい方向に向かって最大出力出せない状態になってしまいそう
- その全体整合性を保つのが自分の仕事になりそう
- 先日の事業内でのプロダクト意思決定ライン整備のワークショップ（RACIで責任範囲を明確化）で、「複数チームにまたがるプロダクトのWHAT（何をいつ作るか）」領域は事業責任者がRACIでいうA（責任者）、自分がR（実行者）を担うことになった。このRに求められる役割を一言でいうと「開発組織全体のスクラムマスター」だという結論になった。各チームはそれぞれスクラムマスター＆POがいてその中で意思決定してもらい、全体の方向性づけや交通整理を自分がやるイメージ。このワークショップで全ての役割が抜け落ちず明確化されたかは分からないが、落ちていたらそれを拾いにいくのも、その後どうにかするのも全体のスクラムマスターの仕事。アラインメント体制決めのMTGを設けたことも、まさにその仕事の1つだった。
