大規模スクラム開発のコミュニケーション設計

スクラムガイド に書かれているように、スクラムチームは10人以下が推奨されています。
スクラム開発を採用するしないにかかわらず、チームは成長につれて得てして大きくなるものです。気がつくと、大規模な組織になっていることもあるでしょう。

10人を超える組織にもスクラム開発を適用することは可能ですが、スクラムのフレームワークは大きな組織のために設計されていません。そのため、Scrum of Scrums や LeSS (Large-Scale Scrum)、LeSS Huge、Scrum@Scale、Nexus、SAFe など、スクラムを拡張する手法やフレームワークがいくつも提案されています。

この記事では、「LeSS」、「Scrum@Scale」のそれぞれで、プロダクトオーナーや開発チームやステークホルダーなどの間のコミュニケーションがどのように設計されているかをまとめてみます。
ざっくりこの2つは、プロダクトオーナー (PO) とスクラムマスター (ScM) と開発チームで構成されるスクラムチームが複数ある状況下で、複数のチームを取りまとめる責任者のもと、一つの目的に向けて効率的に仕事をするための組織設計のフレームワークです。
なお詳細については自分なんかではとても解説できないのでリンクに留めておきます。

• LeSS
  • https://less.works/
• Scrum@Scale
  • https://scruminc.jp/scrum-at-scale/guide/

コミュニケーション設計まとめ

スクラムチームが複数あって複数チームの指揮命令をおこなう「えらいひと」が必要なとき、私見ですがコミュニケーションパスとして以下の5つは最低限必要だと思います。

• ① えらいひと ⇔ 各チームの PO
  • 複数チームの指揮命令権をもつえらいひとと、各チームのやることや順序を決める PO とのコミュニケーション
• ② 各チームの PO ⇔ 各チームの PO
  • チーム間のやること調整のためのコミュニケーション
• ③ 各チームの PO ⇔ 開発チーム
  • PO と開発チームでやることや具体的な実現方法のすり合わせなどのコミュニケーション
• ④ 開発チーム ⇔ 開発チーム
  • よこの知識共有や課題解決のコミュニケーション
• ⑤ ステークホルダー ⇔ えらいひと
  • ステークホルダーとの利害調整などのコミュニケーション
    

これらのコミュニケーションについてまとめていきます。

① えらいひと ⇔ 各チームの PO

LeSS

LeSS で PO というと組織全体で一人の全体のPOを指し示します。すべてのチームのやることを決めるえらいひとの役割です。
各スクラムチームの代表者がいわゆる1チームスクラムでいう PO ...といった決まりはないというふうに理解していますが、そうであることが多いのではないかと思っています。

全体のPOは、オーバーオールプロダクトリファインメントというイベントで、各チームの代表者と一緒にプロダクト視点でのバックログ整理をおこないます。

これら以外にも、全体のPOはスプリント計画にも同席し各チームでのバックログ実現のための交通整理の役割を担ったり、各チームのイベントに偵察にいったりとさまざまに情報収集・共有をおこないます。

Scrum@Scale

Scrum@Scale ではチーフプロダクトオーナー (CPO)が PO を取りまとめるえらいひとの役割を担います。

CPO は PO と緊密に連携をとることが期待されています。イベントとしては

• チームを跨ぐ スケールドバックログリファインメント
• CPO・PO・主要ステークホルダーで開催するエグゼクティブメタスクラム（EMS） の会合 (週一回程度)

があり、施策や優先順位を調整していきます。

② 各チームの PO ⇔ 各チームの PO

LeSS

以下3つのイベントで協働が行われます。

• プロダクトバックログリファインメント(全体)
• プロダクトバックログリファインメント(複数チーム)
• 2段階でおこなうスプリントプランニングのうちの1段階目

全体・複数チームが参加するプロダクトバックログリファインメントでプロダクトバックログアイテムへの理解を深め、スプリントプランニングで各チームが主導しプロダクトバックログアイテムを割り振ります。

Scrum@Scale

チームを跨ぐ スケールドバックログリファインメント で理解を深め、 スケールドスプリントプランニング で CPO、PO、ScM でバックログアイテムの割り振りをおこないます。

③ 各チームの PO ⇔ 開発チーム

LeSS / Scrum@Scale

どちらも通常のスクラムのサイクルにそってプロダクトバックログリファインメントやスプリント計画などのイベントでコミュニケーションが行われます。

④ 開発チーム ⇔ 開発チーム

チームの生産性をより高めることが目的のコミュニケーションをここでは取り扱います。

LeSS

各チームのレトロスペクティブで明らかになった問題を共有して改善のためのアクションに繋げるオーバーオールレトロスペクティブをチームを跨いで実施します。
オーバーオールレトロスペクティブの参加者は、上がった課題に対するアクションをチームを跨いでおこないます。

Scrum@Scale

スケールドデイリースクラム で各チームの代表者がスプリントゴール達成のための情報共有と課題解決を行います。
また、スケールドレトロスペクティブ で各チーム同士の ScM を中心にチーム間の課題を共有し、解決します。
これらのアクティビティで得られた課題は各チームの ScM で構成されるエグゼクティブアクションチーム（EAT）が主導して解決に向けてのアクションを行なっていきます。

⑤ ステークホルダー ⇔ えらいひと

LeSS

スプリントレビューに全体のPO、各チームの代表者とステークホルダーが参加し、プロダクトの改善に向けたアイデアを共有します。

Scrum@Scale

スプリントレビュー に加えて、エグゼクティブメタスクラム（EMS） という会合を週一回程度実施します。
この場では、予算・チーム編成・プロダクトビジョンなど他では扱わない話題も取り扱います。

まとめ

今年は自分の関わっているチームで LeSS を意識した大規模スクラムにチャレンジした一年でした。
まだまだ手応えを感じるほどには至っていないのですが、改めて見ると LeSS は比較的自律性を重んじた設計で、勘所を掴んで実践するためには自分もチームも学びを深める必要がありそうだと感じました。

なお、本記事の内容には全く自信が持てませんのでご自身で調べることを強くお勧めいたします！