目次
- はじめに
- 目次
第1章：スクラムのスケーリングと大規模の難しさ
スクラムをスケールするとはどういうことか
- 1つのスクラムチームから増やしていく場合
- チームを増やしたくなる動機
- 人が増えることでコストは大きくなる
- スクラムをスケールしない方法を考える
- 疎結合なスケールを検討する
- 大規模な組織に新しくスクラムを適用する場合
- 大規模組織であっても最初は小さく始める
- スクラムのスケールは安易に選択すべきではない
さまざまなスケーリングスクラムのやり方
- LeSS──1人のプロダクトオーナーと1つのプロダクトバックログ
- Nexus──統合チームが統合の責任を持つ
- SAFe──エンタープライズ向けビジネスフレームワーク
- Scrum@Scale──プロダクトオーナーをスケールする
大規模スクラムの導入と組織文化
- 大規模スクラムの導入は組織的な支援が必要
- 大規模スクラムを成功させる「動機付け」
まとめ
第2章：スクラムのおさらい
スクラムとは
- 経験主義の三本柱
- 透明性
- 検査
- 適応
- スクラムの価値基準
- 3つの作成物，スクラムチーム，5つのイベント
スクラムにおける3つの作成物
- プロダクトバックログ
- プロダクトバックログリファインメント
- スプリントバックログ
- インクリメント
スクラムチーム
- 開発者
- プロダクトオーナー
- スクラムマスター
- スクラムチームの人数
スクラムにおける5つのイベント
- スプリント
- スプリントプランニング
- このスプリントはなぜ価値があるのか？
- このスプリントで何ができるのか？
- 選択した作業をどのように成し遂げるのか？
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
まとめ
第3章：とあるチームのScrum@Scaleでの1スプリント
チームの紹介
とあるチームのデイリースクラム
さまざまなデイリースクラム
- [Column]モブワーク／モブプログラミング
- SDS
- EATのデイリースクラム
- 毎日45分で問題が解決する
プロダクトオーナーの活動
- 複数のプロダクトオーナーとその仕事
- チーフプロダクトオーナーの活動とメタスクラム
- メタスクラムでの議論
- スケールされたプロダクトバックログリファインメント
- スケールされたスプリントレビュー
まとめ
第4章：スクラムマスターサイクルとプロダクトオーナーサイクル
Scrum@Scaleの特徴
スクラムマスターサイクル
- スクラムチームとSoS
- スクラムオブスクラムマスター
- SoSのサイズとスケール
- SoSは共通の関心事どうしで作る
- 関心事をどのように分離するか
- コンウェイの法則と逆コンウェイ作戦
- Scrum@Scaleと『チームトポロジー』
- チームタイプ
- インタラクションモード
- SoSのイベント
- SDS
- スケールドレトロスペクティブ
- SoSのスプリント
- Executive Action Team（EAT）
- EATの役割
- EATに誰が参加するか
- [Column]アジャイルプラクティス
- EATも1つのスクラムチームになる
- EATのメンバーは外部のステークホルダーのようにならない
- 組織構造の継続的な改善
- 人が異動することによるコスト
- 人ではなくチームの組み合わせを変えていく
- どのように組織を変更するか
- EATだけで人の配置を決定できるようにする
プロダクトオーナーサイクル
- なぜプロダクトオーナーは開発チームから独立してスケールするのか
- チーフプロダクトオーナーとメタスクラム
- EMS
- EMSの役割
- EMSに誰が参加するか
- プロダクトオーナーの活動を支援するイベント
- プロダクトバックログリファインメント
- スケールされたスプリントレビューとスケールされたスプリントプランニング
まとめ
第5章：Scrum@Scaleを形成する12のコンポーネント
習熟度を確認するために12のコンポーネントを使う
最初に行うコンポーネント
- チームプロセス──2つのサイクルの交差点
- [Column]守破離
- Scrum@Scaleでの守破離の「破」
スクラムマスターサイクルのコンポーネント
- 継続的改善と障害の除去──開発の障害を迅速に取り除く
- チーム横断の調整──コラボレーションの合理化
- [Column]レベル2のスクラムマスター
- デリバリ──完成したプロダクトを届ける
プロダクトオーナーサイクルのコンポーネント
- 戦略的ビジョン──組織全体の方向性を作る
- [Column]EBM
- バックログの優先順位付け──価値の提供の最適化
- バックログの分割とリファインメント──チームの理解を深める
- リリースプランニング──長期的な計画を作る
- すべての機能がそろう時期の範囲を伝える
- ある時期までに完成する機能の量の範囲を伝える
- 期限に確実に終わらせるためにやることを減らす
共通のコンポーネント
- プロダクトリリースとフィードバック──プロダクトバックログの更新
- メトリクスと透明性──検査・適応のための手段
- チームのパフォーマンス
- SLI（サービスレベル指標）／SLO（サービスレベル目標）
- ビジネスを測る指標
- メトリクスは単独では意味がない
まとめ
第6章：現場へどのように導入していくか
ステップ0：機能しているスクラムチームを作る
- スクラムチームが機能しているとはどういう状態か
- [Column]スクラムチームの成熟度
ステップ1：SoSを立ち上げる
- 単一のチームを複数に拡張する
- チーム分割の落とし穴
- 人がチームを横断する
- 分割後の依存関係
- SoSのスクラムイベントをスタートする
- SoSの作成物
- EATを立ち上げ，エグゼクティブメンバーを巻き込む
ステップ2：メタスクラムを立ち上げる
- チーフプロダクトオーナーを選出する
- メタスクラムとしてのイベントを立ち上げる
- EMSを立ち上げ，エグゼクティブメンバーを巻き込む
ステップ3：改善サイクルを回す
- 12のコンポーネントと変革バックログ
- [Column]EATを一番初めに導入するパターン
まとめ
第7章：Scrum@Scaleで運用される現場 ──チャットサービスの開発現場の場合
なぜScrum@Scaleを選択したのか
- 逆コンウェイ作戦
- プロダクトオーナーチームの利点
Scrum@Scaleの組織構造とイベントの運用
- 3つのスクラムチーム
- SoSとEAT
- メタスクラム
- アジャイルプラクティス
Scrum@Scaleのイベント
- スクラムマスターサイクルとしてのイベント
- SDS
- スケールドレトロスペクティブ
- EATとしてのイベント
- [Column]むきなおり
- プロダクトオーナーサイクルとしてのイベント
- メタスクラムのデイリースクラム
- メタスクラムのプロダクトバックログリファインメント
- 1週間のカレンダーまとめ
組織構造の変遷
- 初期状態
- 2チームで開始したアーキテクチャ上の理由
- CQRS
- チームをコマンドとクエリに分離
- 4ヵ月目──認証・認可基盤チームが立ち上がり3チーム体制へ
- 6ヵ月目──開発スコープの変更によるチーム再編
- 8ヵ月目から現在──SoSの再編とEAT
- SoSの再編
- EMSからEATへ
12のコンポーネントの自己採点と変革バックログ
まとめ
- 参考文献
- 索引