書評）スクラムの拡張による組織づくり

Management Agile

 

複数のスクラムチームがいるような規模の組織がうまく仕事をしていくためのフレームワークであるScrum@Scaleについてとてもわかりやすく簡潔に説明してくれた本。

今の組織に近い感じなのでこれを参考にいろいろ整理できそう。

サマリー

一つのサービスや事業の中でスクラムチームが複数、プロダクトオーナーもプロダクトバックログも複数あるような規模組織だとフィットしていて実践しやすそうなフレームワーク。LeSSのように1人のプロダクトオーナーによる一つのプロダクトバックログを複数のスクラムチームが、ではなく「分割統治」の考えを持っている。

各チームは普通にスクラムを実践、ただチームが複数にスケールして複雑化する相互のコミュニケーションにルールを設けるなど、チーム間連携の仕組みをもうけたもの。

開発者たちの活動をスクラムマスターサイクル、プロダクトオーナーたちの活動をプロダクトオーナーサイクルとして2軸で整理し、プロダクトインクリメントを作っていくための12のコンポーネントを定義。

複数のスクラムチームをまとめたSoS、複数のSoSをまとめたSoSoS、とフラクタルにスケール。（フラクタル構造といいつつ、単に階層ツリー構造でも理解できる）

SoSは共通の関心事同士でつくるので例えば新規フィーチャー、エピック、プロジェクト、サービスドメイン、モジュールなどで柔軟に括れそう。これによって密なコミュニケーションが必要な単位で括られる。逆に不要なコミュニケーション（あのチームのやってることうち関係ないな、、、と思いながら参加する会議など）を減らすのと、一度に同期を取るチームの数を小さく保つ。

状況によって人の異動ではなく、このSoSのチームの組み合わせを変えることで対応する。

 

スクラムマスターサイクル

EAT(Executive Action Team)を中心とした開発者のサイクル。

スクラムチームは、

  • DS (Daily Scrum)
  • SDS (Scaled Daily Scrum)
  • EAT (Executive Action Team)

で45分で毎日課題を解決。

スプリント

各チームのサイクルを合わせる。SoSを形成するチームのタイムボックスがバラバラだとコラボレーションが難しくなる。

EAT

チームでは解決できない問題を最終的に解決する。人やチームの配置、予算、外部要因など。その権限を持つ人が参加する。

EATもこの役割を果たすためのクロスファンクショナルなスクラムチームで人の配置などの裁量を持つ人で構成。

 

プロダクトオーナーサイクル

EMS (Executive MetaScrum) を中心としたプロダクトオーナーたちのサイクル。

プロダクトオーナーは、

  • メタスクラムで次に取り組むPBIを決め、EMSで最終意思決定、決まったPBIを各チームのPBIにブレイクダウン
  • 複数のチームを跨いだPBIはその単位のSoSでスケールしたスプリントレビューで統合したインクリメントをレビュー
メタスクラム

プロダクトオーナーたちのチーム。

配下のプロダクトを横断するプロダクトバックログを持ち、このPBをチーフプロダクトオーナーを中心に管理する。

EMS

自律した複数のスクラムチームが同じ方向を向いて仕事ができるように組織全体の戦略的ビジョンを策定し浸透させる。どのような価値を実現するかにおいての最終的な意思決定をする。

EMSもこの役割を果たすためのクロスファンクショナルなスクラムチーム。

 

スケールされたイベント

Scaled レトロスペクティブ

SoS各チームのスクラムマスターが参加しチームプロセスの障害を取り扱う。

Scaled スプリントプランニング

SoSのインクリメントの統合が必要な場合はプランニングも合同で。

Scaled スプリントレビュー

SoSのインクリメントの統合が必要な場合のレビュー。

 

12のコンポーネント

EATとEMSは上述。基本的には通常のスクラムと同じ。

共通

チームプロセス

最初に取り組むコンポーネント。スクラムガイドが規定しているスクラムを行う。スクラムチームが未熟なままでスケールしてしまうと組織全体が未成熟なまま大きくなってしまう。

守破離の破として、十分に成熟したチームどうしの組み合わせであれば、必ずしもスクラムに縛られる必要はない。

プロダクトリリースとフィードバック

リリースで得られたユーザー、市場、ステークホルダーからのフィードバックはプロダクトオーナーサイクルが解釈。ソフトウェアの稼働状況、負荷状況、リリース作業などへのフィードバックはスクラムマスターサイクルで解釈。

メトリクスと透明性

特別なことは無し。Four Keys、SLI/SLO、ビジネスKPIなど。

スクラムマスターサイクル

継続的改善と障害の除去

スクラムの基本と同じ。SoSやEATがImpediment Listを作ることもある。

チーム横断の調整

SoSを形成するチームのタイムボックスを合わせ、DS、SDSのタイミングを合わせてコラボレーションしやすくする。

関心事が近い・同じチームをSoSで組み合わせ、チーム間の依存関係を緩和しSoSをまたいだコミュニケーションやボトルネックを排除する。

デリバリ

チームが単独でリリースできることもあれば、複数のチームのインクリメントを統合してリリースすることもある。組織全体で一貫したデリバリのプロセスを保つために、デリバリの責任はSoSが持つ。

プロダクトオーナーサイクル

戦略的ビジョン

複数の自律したチームが、組織が何を目指し、どういう価値を提供するのか。各チームはこのビジョンを共有する独自のプロダクトゴールを定めてプロダクトバックログを管理する。

バックログの優先順位付け

メタスクラムなどで調整を密に行い、組織全体で一貫した順番に。

バックログの分割とリファインメント

メタスクラムが作るプロダクトバックログを、各チーム単位にブレークダウンする。

リリースプランニング

複数チームで依存する場合はリリースまでの長期的な計画が必要になることも。その場合はメタスクラムとしてリリースプランニング。

導入ステップ

機能しているスクラムチームを作る

機能しているとは？ 

www.ryuzee.com

SoSを立ち上げる

まずは１つのSoSから。

機能しているスクラムチームを分割することも。

参考）

www.heidihelfand.com

人がチームを横断しないように。コードベースの依存関係をなくすことも考える。

立ち上げたらSDS、Scaled retrospectiveなどのイベントを開始。

EATを立ち上げExecutiveメンバーを巻き込む。

メタスクラムを立ち上げる

チーフプロダクトオーナーを選出し、メタスクラムとしてのイベントを開始する。

EMSを立ち上げExecutiveメンバーを巻き込む。

改善サイクルを回す

各スクラムチームが独自に改善していくサイクルと、Scrum＠Scaleとして組織全体としての改善との２重構造。

12のコンポーネントそれぞれに対して自己採点し、優先順位をつけ、点数が低く優先順位の高い問題から取り組んでいく。これを変革バックログとしEATが取り組む。

既に組織が大きい場合

EATを一番最初に導入するパターン。パイロットチームと従来の組織を並行で運用する。