Scrum@Scaleでスクラム開発をどのようにスケールするか

2022/4/10 7:142022/4/10 23:12

なぜスクラムをはじめたかではチームでどのようにスクラムが始まったか書きました。プロダクトが成長するとチームの人数が増えます。やれることが増えるとともに複数のチームでどのように開発プロセスを回していくかがプロダクトの開発スピードに大きな影響をおよぼす事になります。

１つのスクラムチームをまわしたときには考慮しなくてもよかった事が複数になると以下の点で考慮する必要がでてきます。

バックログは複数チームでどのように管理するか

どのように複数チームに分けるのか。機能(商品、決済、クーポンなど）で分けるか。顧客ごとにわけるか。レイヤー(クライアント、サーバ、インフラ）で分けるか。

スクラムのイベント(リファインメント、プラニング、レビュー、レトロスペクティブ）はどのメンバでどのように行うか。チームごとのセレモニー、すべてのチームで代表者によりセレモニーなど段階にわけるのか。

各種決まったとしてツールはどのようなツールを使うか。

スクラムをスケールする１つの方法としてScrum@Scaleがあります。この記事ではScrum@Scaleの紹介と、どのように実際に１つのスクラムをScrum@Scaleでスケールするかを考えてみます。

１つのスクラムがScrum@Scaleにより複数のスクラムチームに変化するときに知るべきこと

詳細はScrum@Scaleガイドや参考に記載した資料を見るとわかりやすいのでここでは１つのスクラムチームが複数のスクラムチームになるとき知る必要があることを説明します。

Scrum@Scaleでは以下のようにプロダクトの何を開発するか(What)の部分をPO(Product Owner)サイクル、開発するものをどのようにして開発するか(How)の部分をSM(Scrum Master)サイクルとして分離しています。

これはGitLabのプロダクト開発プロセスでGitLabが行っていたWhatとHowを分離したプロダクト開発サイクルと似ています。各々の役割にそってやるべきことに集中するためにこのように分離されていると考えられます。プロダクト開発で人数が少ないうちは１人がいろいろなことをしてなんとかPMFに近づけている段階ですがPMF後に人数が増えた場合はWhatの部分を一貫性のあるやり方で決めてHowを別に実施するというのは一貫性のある優先順位にそってスケールしながら開発する上で理にかなっていると思います。これは必ずしもWhatを担当するメンバがHowに参加できないというわけではなく単純にプロセスが別だと考えるといいと思います。Howに参加したくなった場合はそれ相応の方法(提案できるなど)も用意すべきだと思います。

先程の図にEMSとEATとありました。エグゼクティブメタスクラム(EMS: Executive Meta Scrum)はスクラム全体によって何を生み出すかに焦点を当てる、つまりWhatの改善をする機構です。エグゼクティブアクションチーム(EAT: Executive Action Team)はどのようにスクラム全体で早く仕事を完了するかに焦点を当てる、つまりHowの改善をする機構です。

実際にどのように組織をスケールするかは以下の図で表せます。

1つのスクラムチームと、複数のスクラムチームの規模はScrum@Scaleの記事によると、以下だそうです。

スクラムガイドでは最適なチームの規模を10人以下と定義しているが、ハーバードの研究では、最適なチームの規模は平均で4.6人とされた。よって、スクラムオブスクラムのチームの最適なチーム数は4または5チームである。

スクラムオブスクラムで行われるイベント

ここではSoSoS(Scrum of Scrum of Scrum)の大きなチームを考えます。

スクラムオブスクラムが統合されたスクラムチームとして機能するためには、１つのスクラムチームのイベントと、スクラムオブスクラムとしてのイベントが必要です。さらにそのスクラムオブスクラムをまとめるスクラムオブスクラムオブスクラムのイベントが必要です。Scrum@Scaleガイドなどから必要なイベントをひもとき一例を示します。以下がイベント一覧です(なおSoS(Scrum of Scrum)で一回り小さいチームの場合は赤と青の部分を統合すれば同じように考えれます)。