【読書メモ】スクラムの拡張による組織づくり（１）

スクラムの拡張による組織づくり──複数のスクラムチームをScrum@Scaleで運用する

組織開発の一環で積読していた本です。

パラパラとめくっているうちに面白くなって、スキミングした中で、印象に残ったことを書き残しておきます。

その前に、目次を概観しておきます。

第１章　スクラムのスケーリングと大規模の難しさ

第２章　スクラムのおさらい

第３章　とあるチームのScrum＠Scaleでの１スプリント

第４章　スクラムマスターサイクルとプロダクトオーナーサイクル

第５章　Scrum@Scaleを形成する１２のコンポーネント

第６章　現場へどのように導入していくか

第７章　Scrum@Scaleで運用される現場

この中でも、特に第４章～第６章で学んだことを書いていこうと思います。

第４章　スクラムマスターサイクルとプロダクトオーナーサイクル

まず、Scrum@Scaleの定義から。

Scrum@Scaleとは、通常の単一スクラムチームの活動にチーム間連携のしくみを追加したもの。

そして、このScrum@Scaleでは、開発者たちの活動とプロダクトオーナーの活動の２つの軸に分けて定義されています。

これをそれぞれ「スクラムマスターサイクル」と「プロダクトオーナーサイクル」と呼んでいます。

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

重要キーワード

• SoS：スクラムオブスクラム
  • SoSは１つのスクラムチームとして機能する
  • SoSとしてのゴールを持ち、通常のスクラムチームと同じようなイベントをこなしながら、チームが連携して、統合されたデリバリ可能なインクリメントを完成させる
  • SoSにもスクラムマスターがいる（スクラムオブスクラムマスター）
    • SoSの開催支援、ファシリテートを行う
    • SoS全体として障害物の除去、プロセスの改善を行う
    • SoSとして統合されたインクリメントを届けることに責任を持つ
    • SoSそのものの継続的な改善に責任を持つ
  • SoSの最適なチーム数は４～５チーム
  • SoSは共通の関心事どうしで作る
    • 自分たちの仕事をスムーズに早く終わらせるために、自分たちが設計した適切なアーキテクチャに沿って組織を編成する（逆コンウェイの法則）
    • チームどうしの依存関係の強さでSoSの組み合わせを考える
• チームトポロジー
  • チームトポロジーとは、ビジネスの速度と安定性を実現する技術組織の適応型設計モデルの１つ
  • ４つのチームタイプがある
    • ストリームアラインドチーム：ビジネス価値を生み出すメインチーム
    • プラットフォームチーム：ビジネス価値の提供を支える基盤チーム
    • イネイブリングチーム：チームに必要な知識を届ける学習支援チーム
    • コンプリケイテッド・サブシステムチーム：専門特化チーム
  • ３つのインタラクションモードがある
    • ４つのチームをどのように結合していくか、のバリエーション
      • コラボレーション：協働作業
      • X-as-a-Service：APIやサービスで提供
      • ファシリテーション
• EAT：Exective Action Team
  • SoSで解決できない障害物をこのチームで解決する（食べる＝イート）
  • かなり強い権限を持った人の参加が求められる
    • プロダクトの方針を決定できるリーダー（CEO、CTO）
    • 予算を握っている人（CFO）
    • 組織構造や人員配置に関する決定権を持っている人
    • スクラムのプラクティスに関する意思決定ができるアジャイルコーチ（EATのスクラムマスター）

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

スクラムチームは、スプリント期間を通してインクリメントを作る。

一方、プロダクトオーナーは、プロダクトの価値を高めるための活動をする。

重要キーワード

• メタスクラム：プロダクトに関する方向性を合わせるためのプロダクトオーナーによるチーム
• EMS：Exective Meta Scrum
  • 組織全体の戦略ビジョンを策定し、組織全体に浸透させる

まとめ

今回は第４章の学びをアウトプットしました。

現在の事業部構造と大変似ていることもあり、理解を深めるため、細かい部分まで書きました。

次回はスクラムマスターサイクル、プロダクトオーナーサイクルのもっと細かい中身について書かれている第５章を見ていきたいと思います。