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

Tags
開発プロセス
アジャイル
スクラム
公開日
2022/4/11
Company/Product
なぜスクラムをはじめたか ではチームでどのようにスクラムが始まったか書きました。プロダクトが成長するとチームの人数が増えます。やれることが増えるとともに複数のチームでどのように開発プロセスを回していくかがプロダクトの開発スピードに大きな影響をおよぼす事になります。
 
1つのスクラムチームをまわしたときには考慮しなくてもよかった事が複数になると以下の点で考慮する必要がでてきます。
  • バックログは複数チームでどのように管理するか
  • どのように複数チームに分けるのか。機能(商品、決済、クーポンなど)で分けるか。顧客ごとにわけるか。レイヤー(クライアント、サーバ、インフラ)で分けるか。
  • スクラムのイベント(リファインメント、プラニング、レビュー、レトロスペクティブ)はどのメンバでどのように行うか。チームごとのセレモニー、すべてのチームで代表者によりセレモニーなど段階にわけるのか。
  • 各種決まったとしてツールはどのようなツールを使うか。
 
スクラムをスケールする1つの方法としてScrum@Scaleがあります。この記事ではScrum@Scaleの紹介と、どのように実際に1つのスクラムをScrum@Scaleでスケールするかを考えてみます。

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

詳細はScrum@Scaleガイドや参考に記載した資料を見るとわかりやすいのでここでは1つのスクラムチームが複数のスクラムチームになるとき知る必要があることを説明します。
 
Scrum@Scaleでは以下のようにプロダクトの何を開発するか(What)の部分をPO(Product Owner)サイクル、開発するものをどのようにして開発するか(How)の部分をSM(Scrum Master)サイクルとして分離しています。
これはGitLabのプロダクト開発プロセスでGitLabが行っていたWhatとHowを分離したプロダクト開発サイクルと似ています。各々の役割にそってやるべきことに集中するためにこのように分離されていると考えられます。プロダクト開発で人数が少ないうちは1人がいろいろなことをしてなんとか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)の大きなチームを考えます。
スクラムオブスクラムが統合されたスクラムチームとして機能するためには、1つのスクラムチームのイベントと、スクラムオブスクラムとしてのイベントが必要です。さらにそのスクラムオブスクラムをまとめるスクラムオブスクラムオブスクラムのイベントが必要です。Scrum@Scaleガイドなどから必要なイベントをひもとき一例を示します。以下がイベント一覧です(なおSoS(Scrum of Scrum)で一回り小さいチームの場合は赤と青の部分を統合すれば同じように考えれます)。

何をすべきか決める

エグゼクティブメタスクラム

必要な場合に開催されます。スクラムのスプリント内に最低1度は定期開催するのがよさそうです。不定期にすると逆に集まるタイミングが難しくなります。
その中で以下を決定します。
  • 戦略的ビジョン
  • バックログの優先順位付け
  • バックログの分割とリファインメント
  • リリースプランニング
2スプリントの各チーム分のバックログの優先順位付け・分割・リファインメントができていると、その後の各チームのスクラムのスプリントがスムーズに回せそうです。その後に各チームでリファインメントするのでここでのリファインメントは優先順位付け・分割ができる程度でよさそうです。

メタデイリースクラム

エグゼクティブメタスクラムで分割されたバックログをさらに分割します。

リファインメント

各チームで直近のスプリントで実施するバックログを精査します。バックログをメンバが実行(Definition of Readyを満たしている状態)できる状態になるようにします。メンバが多すぎると時間xメンバの数だけ工数がとられるので必要なメンバのみのほうがいいと感じています。

どのようにするか決める

プラニング

各チームでそのスプリントに実施するバックログを決めスプリントバックログを作ります。

デイリースクラム/メタデイリースクラム/エグゼクティブメタデイリースクラム

通常のデイリースクラムと同じです。メタデイリースクラムの場合はデイリースクラムであがった課題を話し合い、エグゼクティブメタデイリースクラムの場合はメタデイリースクラムであがった課題を話し合います。このように階層にし、順に実施することで必要な情報をすぐ上位に伝える事ができます。

リリースと改善

スプリントレビュー

通常のスクラムと同じですが個人的には全体で各チームの成果を共有するのがいいのではと思っています。
ただ全体のみで開催するとチームからフィードバックが出しにくくなる場合は、チームで行ってから全体のスプリントレビューにするのもありかもしれません。

レトロスペクティブ/メタレトロスペクティブ/エグゼクティブメタレトロスペクティブ

振り返りを行います。メタ・エグゼクティブメタレトロスペクティブの場合は、成功した改善をその他のチームにも適用できるように共有します。

メトリクス

スクラムが増えると各スクラムが改善し続けているかを取るメトリックスが大事になってきます。最低限として以下が示されています。
  • 生産性
  • 価値提供
  • 品質
  • 持続可能性: チームの幸福度など
Four Keysを指標として取るとよいかもしれません。
エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud Blog
データがすべて BigQuery で集約、処理された後は、Four Keys ダッシュボードで可視化することができます。Four Keys セットアップ スクリプト はデータポータル コネクタを使用します。これにより、データを Four Keys ダッシュボード テンプレートに接続できます。ダッシュボードは、DORA の 4 つの主な指標に関する研究に基づく大まかな分類を示し、最近のパフォーマンスに関する実行ログを表示するように設計されています。これによりデベロッパー チームは早い段階でパフォーマンスの低下を把握でき、この低下を緩和する措置をとることができます。あるいはパフォーマンスが低い場合、バケットが更新される前に、チームが低下の兆候を早期に確認できます。 準備ができたら Four Keys プロジェクトをご覧になり、お試しください。セットアップ スクリプトを実行すると、アーキテクチャがセットアップされプロジェクトと統合されます。フィードバックや投稿をお待ちしております。 DevOps の手法を適用してソフトウェア デリバリーのパフォーマンスを改善する方法については、cloud.google.com/devops をご覧ください。全体が Google Cloud 上でホストされているアプリケーションの DORA 指標収集に関するフォローアップ投稿も予定しております。 1. 2019 年 Accelerate State of DevOps: エリート パフォーマンス、生産性、スケーリング -デベロッパー プログラム エンジニア Dina Graves Portman

まとめ

最初の疑問に筆者が答えるとすると以下のようになります。
  • バックログの管理: 各スクラムチームごと。メタスクラム・エグゼクティブメタスクラム自体もバックログを持つ
  • チームの分け方: スクラムチーム自体が完結して価値を届ける必要があるので機能または顧客ごと
  • スクラムのイベント: Scrum@Scaleのフレームワークで行う
  • ツール: いろんなツールでできそうだがJIRAでもできる

あとがき

どのようにチームにScrum@Scaleを導入したらいいかイメージがつきました。ただスクラム自体がやや複雑な上、さらに複雑になるのでメンバへの浸透を順次していく必要があります。その組織やビジネスにあった継続的な改善が必要です。
注意しなければいけない点として階層が増えるのでメンバから見ると上で何をやっているか見えなくなりそうです。実施した議事録などオープンにし各イベントは必要があれば誰でも参加できるようにするなどの工夫があると見え方もかわるのかなと思いました。

参考

Scrum@Scaleに関する資料

以下に説明があります。
導入事例として以下があります。