Scrum@Scaleガイド

目次 表示

Scrum@Scaleガイドの序文

スクラムは、もともとスクラムガイドで説明されているように、単一のスクラムチームが、持続可能なペースを維持しつつ、最適な価値を提供できるようにすることを重視している。スクラムガイドの発行以降、スクラムの利用はプロダクト、プロセス、サービスなどの開発といった複数チームの協力が求められる領域まで広がりを見せている。

現場では、組織内のスクラムチーム数の増加に伴い、2つの重要な問題の発生が繰り返し見られた。

  • 複数のチームの間での依存関係や作業の重複、コミュニケーションのオーバーヘッドなどの問題により、チームごとのアウトプット(動作するプロダクト)の量、スピード、品質が低下し始めた。
  • 従来の組織構造はビジネスアジリティの実現に十分な効果を上げられなかった。優先順位の競合や、市場の変化に対応するようチームを素早く転換させることができないなどの問題が発生した。

こうした問題に対処するために、複数のスクラムチームを効果的に調整するフレームワークが明らかに必要だった。Scrum@Scaleフレームワークの目的は以下の通り。

  • リニアなスケーラビリティ: チーム数の増加に比例して、動作するプロダクトのデリバリーも増加する
  • ビジネスアジリティ: 初期の安定した構成を適応させることで、変化に素早く対応できる

Scrum@Scaleは、複数のスクラムチームのネットワークが、組織において優先順位付けされたゴールに集中するのに役立つ。Scrum@Scaleの目的は、単一のスクラムチームが機能するやり方を複数のチームのネットワーク全体へと自然に拡大し、管理機能が実用最小限の官僚機構(MVB)内にある、という構造を構築することである。

チームのネットワークの特性がそのサイズに依存しない場合、リニアなスケーラビリティを実現できる。このゴールのためにチームのネットワークを設計・調整することは、特定の方法で成長を制約するものではない。むしろ、ネットワークが独自のニーズに基づいて有機的に成長することを可能にし、関係者に受け入れられやすい持続的な変化のペースを実現する。

実用最小限の官僚機構とは、顧客に価値を届けるのを妨げることなく、組織を機能させるために必要な機関とプロセスが最小限であるものと定義される。意思決定の遅延を減らすことは、ビジネスアジリティの実現に役立つ。このことは、成功の主な原動力として知られている。Scrum@Scaleの導入を開始するには、アジャイルマニュフェストとスクラムガイド2020をよく理解することが不可欠である。アジリティの本質を理解しないと、それを達成することはできない。スクラムを実践できない組織は、スケールすることはできない。

Scrum@Scaleガイドの目的

このガイドは、Scrum@Scaleと、そのフレームワークのコンポーネントの定義を提供する。そして、スケールされた役割、スケールされたイベント、エンタープライズにおける作成物に対する責任と、それらを結び付けるルールについて説明する。

このガイドは次の4つのセクションに大きく分割されている。

  • Scrum@Scaleを始めるための基本
  • スクラムマスターサイクルの概要
  • プロダクトオーナーサイクルの概要
  • 2つのサイクルを結び付けるウォークスルー

スケーリングの成功には各コンポーネントが必要となる。それらの中核となる設計思想を変更したり、省略したりすると、あるいは、本ガイドに示す基本的なルールに従わないと、Scrum@Scaleのメリットを享受できない。

基本的な構造とルール以外の各コンポーネントを実装する具体的な戦術はさまざまであるため、本ガイドには記載していない。補足的なパターン、プロセス、インサイトは、その他の情報源で提供されている。

定義

スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、人々、チーム、組織が価値を生み出すための軽量級フレームワークである。

スクラムガイドでは、イノベーション、顧客満足、パフォーマンス、幸福を促進するチーム環境を生み出す要素の最小限のセットについて説明している。スクラムは、徹底的な透明性と一連の公式なイベントを使い、チームとそのプロダクトを検査・適応する機会を提供する。

Scrum@Scaleは、スクラムガイドに従って機能しているチームのネットワークが、複雑適応系の問題に対処しつつ、最高の価値のプロダクトを創造的にデリバリーすることを可能とする、軽量級の組織フレームワークである。これらの「プロダクト」としては、物理的、デジタル、または複雑な統合システム、プロセス、サービスなどがある。

Scrum@Scaleガイドでは、スクラムを利用してスクラムをスケールするための最小限のコンポーネントセットと組織全体で生まれるビジネスアジリティーについて説明している。本ガイドは、産業界、政府、非営利団体、学界のあらゆるタイプの組織で活用できる。スクラムをまだ使っていない組織では、組織のオペレーティングシステムを変更する必要がある。

スクラムでは、”What”(プロダクト)と”How”(プロセス)の責任の分離に注意する必要がある。Scrum@Scaleでも、管轄と責任が明確に理解されるように、同じ注意が払われる。これにより、チームがその最適な生産性を達成するのを邪魔する、無駄な組織上の衝突が取り除かれる。Scrum@Scaleはコンポーネントで構成されているため、組織はその変革の戦略と実施をカスタマイズできる。これにより、組織は、最も価値がある、あるいは最も適応が必要であると考えられる分野に、段階的に優先順位をつけて変革の取り組みを行い、その後、他の分野に進むことができる。

Scrum@Scaleは、これらのコンポーネントを、スクラムマスターサイクル(“How”)とプロダクトオーナーサイクル(“What”)に分け、この2つのサイクルが2つのコンポーネントで交わり、3つ目のコンポーネントを共有する。まとめると、これらのサイクルは、一つの道筋に沿って複数のチームの取り組みを調整することを強力にサポートする構造を作り出す。

Scrum@Scaleのコンポーネント

価値駆動文化

Scrum@Scaleの目的は、経験的プロセス制御の柱とスクラムの価値基準を通じて健全な組織文化を構築することである。経験的プロセス制御の三本柱とは、透明性、検査、適応である。これらの柱は、公開(オープン性)、勇気、集中、尊敬、確約(コミットメント)というスクラムの価値基準によって現実のものとなる。

公開(オープン性)は、すべての作業とプロセスへの透明性を保証する。さもなくば誠実な検査と、より良いものに適合することはできない。勇気は、革新的な方法で、より迅速に価値を届けるために必要となる、大胆な飛躍をすることを示す。集中と確約(コミットメント)は、自分たちで自分たちの責務を全うする方法を見つけることを示し、顧客へ価値を届けることを最優先とするということである。最後に、これらすべては、他の誰も成しえない仕事に従事する個人への尊敬に支えられた環境なくしては成しえない。

Scrum@Scaleは、顧客価値の提供を最前線に置きつつ、持続可能なペースで仕事をする積極的なチームの学習環境をサポートする。これにより、組織の成長を支援する。

Scrum@Scaleの始め方: アジャイルオペレーティングシステムを導入する

チームのネットワークを導入する際は、スケールする前に、スケール可能なリファレンスモデルを開発することが不可欠である。リファレンスモデルは、スプリントごとにデリバリーを行うための調整を行う、小さなチームのセットである。これらのチームへのスクラムの導入が成功すると、機能する健全なスクラムの例ができ、組織の他のチームでも再現できるようになる。これは、チームの次のネットワークでスクラムをスケールするためのプロトタイプになる。多数のチームが同時に展開されると、スクラム導入における欠陥は拡大される。スケーリングの問題としては、パフォーマンスを阻んでチームに不満を抱かせるような組織の方針や手続き、開発手法などがある。

スケールされた状況では、完全に統合された一連のインクリメントを提供するために調整が必要なチームをグループ化して、スクラムオブスクラム(SoS)にすることで、リファレンスモデルが最も有効になる。スクラムオブスクラムを効果的に運用するためには、2つのリーダーシップグループで構成された、実用最小限の官僚機構によってサポートされる必要がある。実用最小限の官僚機構とは、スクラムオブスクラムによって何を生み出すべきかに焦点を当てたエグゼクティブメタスクラム(EMS)フォーラムと、どのようにスクラムオブスクムにより速く仕事を完了させるかに焦点を当てたエグゼクティブアクションチーム(EAT)である。エグゼクティブメタスクラムとエグゼクティブアクションチームは、各サイクルの回転のハブ(中心)となるコンポーネントである。

チームをスケールする

スクラムでは、スクラムチームが前工程なしに独立してプロダクトをリリースできるようになることが理想的な状態である。このためには、アイデア出しから実装まで、必要なすべてのスキルを持ったメンバーが必要である。スクラムオブスクラムは、スケーリングのこの理想を再現する、複数チームからなる大きなチームである。スクラムオブスクラム内の各チームが、チームプロセスコンポーネントを実践できなければならない。

チームプロセス

チームプロセスは、スクラムガイドで規定されているスクラムを行うことである。各スクラムチームにはプロダクトオーナーとスクラムマスターがいるため、チームプロセスは、プロダクトオーナーサイクルとスクラムマスターサイクルの最初の交差点となる。チームプロセスのゴールは以下の通り。

  • 完成の定義を満たす作業のフローを最大化する
  • チームのパフォーマンスを時間の経過とともに向上させる
  • 持続可能で、チームをより豊かにする方法で運営する
  • 顧客フィードバックループを加速させる

スクラムオブスクラム(SoS)

スクラムオブスクラムは、スクラムチームのように機能し、スクラムからスケールされたそれ自身の責任、イベント、作成物を持ち、チームプロセスコンポーネントの要求を満たす。スクラムガイドでは最適なチームの規模を10人以下と定義しているが、ハーバードの研究4では、最適なチームの規模は平均で4.6人とされた。よって、スクラムオブスクラムのチームの最適なチーム数は4または5チームである。

スクラムオブスクラムを構成するチームは、ダイナミックなグループとして、各スプリントの終わりに、完全に統合され、出荷可能な一連のプロダクトインクリメントを完成させることに責任を持つ。最も望ましいのは、価値を顧客に直接リリースするために必要な全機能を完成させることである。

注意: 上図およびこの後の図では、薄い灰色で囲まれた五角形がチームを表す。状況に応じて、SMとPOをこれより小さい五角形で表すことにした。組織図は組織によって大きく異なる可能性があるため、これらの図は例示のみを目的としている。

大規模組織でのスケーリング

実装の規模に応じて、複雑なプロダクトの提供には複数のスクラムオブスクラムが必要な場合がある。そのような場合には、複数のスクラムオブスクラムからスクラムオブスクラムオブスクラム(SoSoS)を編成できる。それぞれが、各スクラムオブスクラムからスケールされたそれ自身の役割、作成物、イベントを持つことになる。

スクラムオブスクラムをスケールすることで、組織内のコミュニケーション経路の数が削減されるので、コミュニケーションの経路の複雑さや、オーバーヘッドが軽減される。SoSoSは、スクラムオブスクラムが単一のスクラムチームとインタフェースするのとまったく同様の方法でスクラムオブスクラムとインタフェースするため、リニアなスケーラビリティが実現する。

注意: 簡潔にするために、例の図に含まれるチームとグループの数は対称的にしている。組織図は組織によって大きく異なる可能性があるため、これらの図は例示のみを目的としている。

イベントと役割のスケーリング

スクラムオブスクラム(SoS)がスクラムチームとして機能する場合は、スクラムイベントと、チームの対応する責任をスケールする必要がある。各スプリントの“How”を調整するために、SoSは、スケールされたデイリースクラムとスプリントレトロスペクティブを行う必要がある。各スプリントの“What”を調整するために、SoSは、スケールされたスプリントプランニングとスプリントレビューを行う必要がある。継続的な活動として、バックログリファインメントもスケールされる必要がある。

スケールされたデイリースクラムとレトロスペクティブは、グループのスクラムマスター(スクラムオブスクラムマスター、SoSMと呼ばれる)がファシリテートする。スケールされたスプリントレビューとバックログリファインメントは、チーフプロダクトオーナー(CPO)が率いるプロダクトオーナーチームがファシリテートする。スケールされたスプリントプランニングは、プロダクトオーナーチームとスクラムマスターが行う。プロダクトオーナーチームは、現在のスプリントで何が提供されるかの洞察を得て、スクラムマスターは、キャパシティと技術的な能力の洞察を得る。スクラムオブスクラムマスターとチーフプロダクトオーナーの役割はリーダーシップグループにスケールされ、スクラムマスターサイクルとプロダクトオーナーサイクルをそれぞれ促進し、Scrum@Scaleのコンポーネントの要求を満たす。

イベント: スケールドデイリースクラム(SDS)

デイリースクラムの主なトピックは、スプリントゴールに向けた進捗と、確約(コミットメント)を果たすうえでの障害物である。スケールされた状況では、スクラムオブスクラムは、全体の進捗を理解し、参加チームが提起した障害物に対応する必要がある。よって、各チームから少なくとも1人の代表者がスケールドデイリースクラム(SDS)に参加する。必要に応じて、参加チームのだれでも、何人でも参加することができる。

コラボレーションとパフォーマンスを最適化するために、スケールドデイリースクラムイベントは、以下の通り、デイリースクラムとまったく同じやり方で行う。

  • 15分以下のタイムボックス
  • 各チームの代表者が参加しなければならない
  • チームが、どうすればチームが協力してより効果的に働けるか、何が完成したか、何をこれから完成するか、何が上手くいっていないかとその理由、それに関してグループがこれから何をするかを議論するフォーラム

回答される質問の例は以下の通り。

  • チームのスプリントゴールの達成を妨げる、あるいはデリバリー計画に影響を与える障害物は何か?
  • チームは、他のチームのスプリントゴールの達成を妨げる、あるいはデリバリー計画に影響を与えることをしているか?
  • チーム間の新たな依存関係を発見したか、または既存の依存関係を解決する方法を発見したか?

イベント: スケールドレトロスペクティブ

スプリントごとに、スクラムオブスクラムは、スケールされたスプリントレトロスペクティブを行う。このレトロスペクティブでは、各チームのスクラムマスターが集まり、継続的な改善を促すために行った実験とその結果を話し合う。さらに、次回の実験や、成功した改善をチームのグループ全体、あるいはそれ以外にも活用できる方法も話し合うべきである。

スクラムマスターサイクル: “How”を調整する

役割: スクラムオブスクラムマスター(SoSM)

スクラムオブスクラムのスクラムマスターをスクラムオブスクラムマスター(SoSM)と呼ぶ。スクラムオブスクラムマスターは、スケールされたイベントが確実に行われ、生産的でポジティブであり、タイムボックスが守られるようにする責任を負う。スクラムオブスクラムマスターは、チームのスクラムマスターがなる場合もあれば、この役割に特化した個人の場合もある。SoSMは、共同チームの努力の結果であるプロダクトのリリースと、スクラムオブスクラムの有効性を継続的に改善する責任を負う。これには、チームのスループットの向上、コストの削減、品質の向上が含まれる。これらのゴールを達成するために、SoSMは次のようにしなければならない。

  • チーフプロダクトオーナーと緊密に連携し、少なくとも各スプリントでリリース判断可能なプロダクトインクリメントを届ける
  • チームのデリバリーをプロダクトオーナーチームのリリースプランに応じて調整する
  • 組織に対して障害物、プロセス改善、進捗を見える化する
  • チーム横断的な依存関係に特に注意を払いつつ、障害物の優先順位付けと除去を促す

スクラムオブスクラムマスターは、チームと組織に奉仕する真のリーダーであり、スクラムオブスクラムの外部も含めて、チーム横断的な依存関係を理解し、チーム横断的な調整とコミュニケーションを可能にする。SoSMは、プロダクト開発の進捗、障害物の除去状況、その他のメトリクスの情報を発信することで、チーフプロダクトオーナー、ステークホルダーさらには組織全体に情報を提供し続けることに責任を負う。スクラムオブスクラムマスターは、組織全体でスクラムの有効性と導入を高めるよう他者をメンタリングすることなどで、リーダーシップを発揮する。

複数のスクラムオブスクラムが1つのスクラムオブスクラムオブスクラムにグループ化された場合、より広い観点から調整を行うために、スクラムオブスクラムオブスクラムマスター(SoSoSM)が必要になる。

SMサイクルのハブ: エグゼクティブアクションチーム(EAT)

エグゼクティブアクションチーム(EAT)は、アジャイル組織全体に対してスクラムマスターの責任を果たす。このリーダーシップチームは、以下を行うことで、リファレンスモデルが最適に機能するアジャイルエコシステムを生み出す。

  • スクラムの価値基準を導入する
  • スクラムの役割が確実に作成・支援されるようにする
  • スクラムイベントが実施・出席されるようにする
  • 各スプリントで、スクラムの作成物とそれに関連する確約(コミットメント)が作り出され、透明性が保たれ、各スプリントで更新されるようにする
  • リファレンスモデルと組織内の非アジャイル部分との間の変換層として機能するガイドラインと手続きを策定する

エグゼクティブアクションチームは、スクラムオブスクラム(または、より広範なネットワーク)のメンバーで取り除くことができない障害物を除去する責任を負う。したがって、それを除去するために政治的、財務的に権限を与えられた個人で構成されなければならない。エグゼクティブアクションチームの機能は、複数のスクラムオブスクラム(または、より広範なネットワーク)を調整することと、組織内の非アジャイル部分とインタフェースすることである。スクラムチームと同様に、プロダクトオーナー、スクラムマスター、透明性のあるバックログが必要である。

25チームの5つのグループを調整するEATを示す参考図

EATのバックログと責務

エグゼクティブアクションチーム(EAT)の成果は、組織のアジャイルオペレーティングシステムの構築である。EATは、ビジネスアジリティの向上という目標を達成するために、組織の継続的な変革に向けた取り組みをプロダクトバックログとして整理選択し、提示する。このバックログには、障害物を除去するプロセス改善と、標準化が必要なプロセス改善も含まれる。

エグゼクティブアクションチームの責務には以下を含まれるが、これらに限定されない。

  • 組織でスケール可能なリファレンスモデルのためのアジャイルオペレーティングシステムを作成する(アジリティを得るための企業の運営ルール、手続き、ガイドラインを含む)
  • プロダクトオーナー組織が作成され、資金提供され、支援されることを保証する
  • 組織でスクラムの品質を測定し改善する
  • ビジネスアジリティ実現に向けた組織内の能力を構築する
  • スクラムのプロフェッショナルのための継続的学習の拠点を作る
  • 新しい働き方の探求を支援する

エグゼクティブアクションチームの役割は、このバックログが実行されていることを確認することである。これをEAT自体で行うことも、別のグループに権限を与えて行わせることもできる。エグゼクティブアクションチームは組織内のスクラムの品質に責任を負うため、スクラムマスター組織全体がEATに報告する。

スクラムマスター組織(スクラムマスター、スクラムオブスクラムマスター、エグゼクティブアクションチーム)は、スクラムマスターサイクルのコンポーネントを実装するために全体として機能する。固有のコンポーネントは以下の通り。

  • 継続的改善と障害物の除去
  • チーム横断の調整
  • デリバリー

継続的改善と障害物除去

障害物の除去は、できる限り迅速に除去されるのが理想的である。これは、障害物自体が組織に拡散することを回避し、未解決の障害物によって生産性を低下させないために不可欠である。よって、継続的改善と障害物の除去のゴールは以下の通り。

  • 障害物を特定し、改善の機会としてそれを捉え直す
  • 変化を可能にする透明性と可視性を組織内に確保する
  • 障害物の優先順位付けと除去に効果的な環境を維持する
  • 改善がチーム/プロダクトのメトリクスにプラスの影響を与えていることを確認する

チーム横断の調整

共通のプロダクトの作成に複数のチームが必要な場合、成功するにはコラボレーションの合理化が必要である。よって、チーム横断の調整のゴールは以下の通り。

  • 関連する複数のチーム間で類似のプロセスを同期させる
  • チーム間の依存関係を緩和し、障害物とならないようにする
  • 一貫性のあるアウトプットのために、チームの規範とガイドラインの整合性を維持する

デリバリー

スクラムオブスクラムのゴールは、単一のユニットとして機能し、一緒にリリースすることなので、プロダクトをどのようにデリバリーするかは、スクラムオブスクラムのグループとしての範囲に含まれる。プロダクトオーナーチームは、リリースの内容と、インクリメントを顧客に届ける最適なタイミングの両方を決定する。よって、スクラムオブスクラムのデリバリーのゴールは以下の通り。

  • 顧客に一貫した流れで価値ある完成したプロダクトを届ける
  • 異なるチームの作業をシームレスな1つのプロダクトに統合する
  • 高品質な顧客体験を確保する

プロダクトオーナーサイクル: “What”を調整する

プロダクトオーナーのスケーリング – プロダクトオーナーサイクル

スクラムオブスクラムごとに、チームのネットワークに供給する共通のバックログがある。そして、スクラムオブスクラムのプロダクトオーナーとして責任を負う、チーフプロダクトオーナーを含むプロダクトオーナーチーム(POチーム)が必要である。POチームが主に重視するのは、個々のチームの優先順位を一列に並べることである。これによって、個々のチームのバックログの調整と、ステークホルダーと顧客ニーズの整合性の確立が可能になる。

各チームのプロダクトオーナーは、自チームのスプリントバックログの構成と優先順位付けに責任を持ち、ビジネス目標の達成に必要な場合は、自身の裁量で、共通バックログからアイテムを引き出したり、独立したバックログアイテムを生成することができる。

プロダクトオーナーチームの主な役割は以下の通り。

  • プロダクトの包括的なビジョンを伝達し、組織内の全員に見える化する
  • 主要なステークホルダーとの連携を構築し、バックログの実行に対する支援を確保する
  • 単一の優先順位付けされたバックログを生成し、チーム間の作業の重複を回避する
  • スクラムオブスクラムマスターと協力して、全チームに適用される最小限で統一的な「完成の定義」を作成する
  • チームが提起した依存関係を排除する
  • 調整されたロードマップとリリースプランを生成する
  • プロダクトと市場に関する洞察力をもたらすメトリクスを測定する

役割: チーフプロダクトオーナー(CPO)

チーフプロダクトオーナーは、プロダクトオーナーチームと一緒に優先順位を調整する。共同でバックログの優先順位をステークホルダーと顧客のニーズに合わせる。CPOは、この役割を兼任する個別チームのプロダクトオーナーである場合もあれば、この役割に専任した個人の場合もある。主な責務は通常のプロダクトオーナーと同じであるが、スケールされて以下のようになる。

  • プロダクト全体の戦略的ビジョンを設定する
  • 全チームに配布される、優先順位付けされた単一のバックログを作成する
  • プロダクトオーナーチームが測定するメトリクスを決定する
  • 顧客からのプロダクトのフィードバックを評価し、それに応じて共通バックログを調整する
  • メタスクラムイベント(以下参照)をファシリテートする

チーフプロダクトオーナーは、関連するスクラムオブスクラムマスターとともに、リリースプランに従ったプロダクトインクリメントの効率的なデリバリーに責任を負う。

プロダクトオーナーチームのスケーリング

プロダクトオーナーチームを設けることで、関連するスクラムオブスクラムとともにスケールするプロダクトオーナーのネットワークデザインが可能になる。これらの拡張ユニットには特定の用語はなく、チーフプロダクトオーナーの特定の拡張された肩書もない。プロダクトオーナーチームやチーフプロダクトオーナー向けの用語や肩書は、各組織で独自に設定することを奨励する。

POサイクルのハブ: エグゼクティブメタスクラム(EMS)

アジャイル組織全体に対してプロダクトオーナーの役割を果たすために、チーフプロダクトオーナーは、エグゼクティブメタスクラムイベントでエグゼクティブや主要なステークホルダーと会合する。

このイベントは、メタスクラムパターン5から派生している。これは、リーダーシップとその他のステークホルダーが、自らの好みをPOチームに伝え、優先順位を交渉し、予算を変更し、チームを再編成して価値の提供を最大化するためのフォーラムである。スプリント中の他のタイミングでは、こうした決定を行うべきではない。

エグゼクティブメタスクラムでは、リーダーの動的グループが、組織のビジョンと戦略的な優先順位を設定し、共通のゴールに沿って全チームの方向性を揃える。効果的に行うために、チーフプロダクトオーナーがファシリテートし、各チームのプロダクトオーナー(またはその代理)が出席しなければならない。このイベントは、スクラムオブスクラム内でバックログの方向性を揃えるために、必要な頻度で行う(少なくとも各スプリントで1回)。理想は、このリーダーのグループがスクラムチームとして活動することである。

複数のスクラムオブスクラムが存在する大規模な実装の場合、エグゼクティブメタスクラムで戦略的バックログの作成と優先順位付けがされた、複数のメタスクラムが存在する可能性がある。

“What”を調整する – プロダクトオーナーサイクル

プロダクトオーナー組織(プロダクトオーナー、チーフプロダクトオーナー、エグゼクティブメタスクラム)は、プロダクトオーナーサイクルの以下の固有コンポーネントの要求を満たすために全体として機能する。

  • 戦略的ビジョン
  • バックログの優先順位付け
  • バックログの分割とリファインメント
  • リリースプランニング

戦略的ビジョン

魅力的なビジョンは顧客と優秀な社員の両方を引きつける。よって、社内外の両方に伝達される戦略的ビジョンは、以下のゴールで策定する。

  • 組織全体を共通の進むべき道に沿うように方向性を揃える
  • 組織とそのプロダクトの存在理由を魅力的にはっきり述べる
  • 明確さにより、具体的なプロダクトゴールの作成が可能になる
  • キーとなる資産を活用するために組織が何をするかを説明する
  • 急速に変化するマーケットの状況に対応できるようにする

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

チームが調整された方法で機能して価値の提供を最適化するためには、バックログに適切な優先順位を付けることが不可欠である。優先順位の相反は、チームを反対の方向に進ませるため、無駄を生み出す。バックログの優先順位付けのゴールは以下の通り。

  • デリバリーするプロダクト、機能、サービスの順位を明確に特定する
  • 価値創造、リスク軽減、内部依存関係をバックログの順位付けに反映させる
  • バックログの分解とリファインメントに先立ち、アジャイル組織全体のハイレベルの取り組みを優先順位をつける

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

チーフプロダクトオーナーのバックログには、個々のチームのバックログより範囲の広いアイテムが含まれる。優先順位付けされたアイテムを個々のチームに引き込むには、分割して理解を深めることが必要な場合がある。バックログの分割とリファインメントのゴールは以下の通り。

  • ビジョンを実現するための複雑なプロダクト、プロジェクトおよび関連するプロダクトゴールを特定する
  • そうした複雑なプロダクトとプロジェクトを、独立した要素に分割する
  • すべてのバックログアイテムを、チームが1スプリントで完成させることができるアイテムへとさらにリファインできるようにする

リリースプランニング

リリースプランニングには、顧客へプロダクトを一度ではなく、複数回リリースする場合も含まれ、計画期間は単一のスプリントより長期的である。リリースプランニングのゴールは以下の通り。

  • 主要なプロダクトインクリメントと機能のデリバリー時期を予測する
  • ステークホルダーにデリバリー時期を伝える
  • デリバリーのスケジュールが財務に与える影響を伝える

プロダクトオーナーサイクルとスクラムマスターサイクルをつなぐ

この2つのサイクルの最初の交差点は、チームプロセスコンポーネントである。この点から、“What”と“How”の責任は、完成したプロダクトがデリバリーされるまで分離される。これらのサイクルは、プロダクトに対する顧客の反応が解釈されるフィードバックコンポーネントで再度交差する。次のデリバリーサイクルへの適応に関する経験に基づく決定を行うには、ここでメトリクスが必要になる。プロダクトオーナー組織とスクラムマスター組織は、協力して、これらのコンポーネントの要求を満たす。

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

プロダクトのフィードバックは、プロダクトオーナー組織によって解釈され、プロダクトバックログを更新することでプロダクトの継続的改善を促す。リリースのフィードバックは、スクラムマスター組織によって解釈され、デリバリーの仕組みの継続的改善を促す。フィードバックの取得と分析のゴールは以下の通り。

  • 仮説を検証する
  • 顧客がプロダクトをどのように使用し、相互作用するかを理解する
  • 新しいアイデアや、新しい機能性に対する創発的な要求を収集する

メトリクスと透明性

メトリクスは、特定組織だけでなく、それらの組織内の特定機能にも固有となる場合がある。Scrum@Scaleは特定のメトリクスセットを必要としていないが、最低限のものについて示す。組織が計測すべきものは以下である。

  • 生産性 – 例: スプリントごとにデリバリーされる動作するプロダクトの量の変化
  • 価値提供 – 例: チームの労力あたりのビジネス価値
  • 品質 – 例: 不具合発生率、サービス停止時間
  • 持続可能性 – 例: チームの幸福度

徹底的な透明性は、スクラムが最適に機能するために不可欠であり、組織にその進捗を誠実に評価し、そのプロダクトとプロセスを検査・適応させる能力を与える。

メトリクスと透明性を持つことのゴールは以下の通り。

  • データに基づく意思決定を行うための適切なコンテキストを提供する
  • 意思決定の遅延を減らす
  • チーム、ステークホルダー、リーダーシップが必要とする作業を効率化する

組織デザインにおける考慮点

Scrum@Scaleによる組織デザインのゴールは、フレームワーク自体と同様に、組織をコンポーネントベースで設計できるようにすることである。これにより、マーケットに応じてチームのリバランスやリファクタリングが可能となる。

参考図:

カスタマーリレーションズ、法務/コンプライアンス、人事がこの図に含まれているのは、組織の必要な部分であり、他の全チームが頼る独立したスクラムチームとして存在するためである。

エグゼクティブアクションチームとエグゼクティブメタスクラムの表現に関する注記: この図では、一部のメンバーが両方のチームに在席しているため、重複して表現している。非常に小規模な組織や実装では、エグゼクティブアクションチームとエグゼクティブメタスクラムはまったく同じチームメンバーで構成されている場合がある。

この組織図では、ナレッジチームとインフラストラクチャチームは、各チームにスタッフを配置するには少なすぎる専門家の仮想チームを表している。仮想チームが、共通サービスを提供するチームとして機能する場合、グループとして周りのスクラムチームと調整する。周りのスクラムチームからの要求は各専門分野の仮想チームのプロダクトオーナーを経由して、透明性のある優先順位付けされたバックログとして管理される。重要な点は、仮想チームは、隣同士に座っている個人のサイロではないということである(白抜き五角形で表現されている理由)。仮想チームのチームメンバーは実際のスクラムチームに席を持っており、スプリント中はスクラムチームの一員となる。一方、バックログの配布とプロセスの改善のために、この仮想スクラムを独自に構成する。

後書

Scrum@Scaleは、生産性を向上させ、組織全体が半分のコストで2倍の価値を提供できるように設計されている。合理化されたワークフローを、持続可能なペースで実装し、優れた意思決定を行うと、作業環境が改善され、ビジネスのアジリティが高まり、すべてのステークホルダーにより高い利益がもたらされる。

Scrum@Scaleは、組織にスクラムを浸透させるように設計されている。スクラムをうまく実装すると、Scrum@Scaleをオペレーティングシステムとして使い、組織全体を運営することができる。

謝辞

歴史

ジェフ・サザーランド博士は、スクラムの背後にある原則、複雑系適応システム理論、ゲーム理論、および生物学における彼の研究に基づきScrum@Scaleを開発した。本ガイドの原版は、Jessica Larsen、Avi Schneier、Alex Sutherlandの協力により作成された。以降の版は、多くの経験豊かなスクラムの実践者のフィールドワークの結果に基づいて改良されている。

人と組織

我々は、IDX社において、スクラムを何百ものチームに広げることを最初に許してくれたことで、スクラムオブスクラムが生まれたと認識している6。PentientKeeper社ではメタスクラムが生まれ7、革新的な製品の高速開発を可能にし、OpenView Venture Partners社はスクラムを組織全体に拡大した8。Intel社は、スケールフリーアーキテクチャ無しには “何もスケールしない”ことを私たちに教え、最大のスクラムチーム製品部門を持つSAP社は、2,000を超えるスクラムチームがともに働くためには、メタスクラムにおけるマネジメントの関与が必須であるということを教えてくれた。

Amazon、GE、3M、トヨタ、Spotify、Maersk、Comcast、AT&Tなどの多くの企業でScrum@Scaleのコンセプトを導入しているアジャイルコーチとトレーナーたちは、異なるドメインの幅広い企業にまたがり、Scrum@Scaleのコンセプトをテストすることに協力し続けてくれている。

  1. “Business agility(ビジネスのアジリティ)”、Wikipedia、最終変更2020年2月27日。
    https://en.wikipedia.org/wiki/Business_agility
  2. Johnson, Jim、新カオスレポート、The Standish Group、2018年。
  3. Ogunnaike, Babatunde A.、Ray, W. Harmon、Process Dynamics, Modeling and Control(プロセスのダイナミクス、モデル、制御)、Oxford University Press、1994年。
  4. Hackman, J Richard、Leading Teams: Setting the Stage for Great Performances(チームをリードする: パフォーマンスを高めるステージの設定)、Harvard Business Press、2002年。
  5. Sutherland, Jeff、Coplien, James O.、The Scrum Patterns Group、A Scrum Book: The Spirit of the Game(スクラムブック: ゲームのスピリット)、Pragmatic Bookshelf、2019年。
  6. Sutherland, Jeff、“Inventing and Reinventing SCRUM in five Companies(5社におけるスクラムの発明と再発明)”、Sur le site officiel de l’alliance agile、2001年。
  7. Sutherland, Jeff、“Future of Scrum: Parallel Pipelining of Sprints in Complex Projects(スクラムの未来: 複雑なプロジェクトにおけるスプリントの並行パイプライン化)”、Proceedings of the Agile Development Conference(アジャイル開発会議の内容)、IEEE Computer Society 90-102、2005年。
  8. Sutherland, Jeff、Altman, Igor、“Take No Prisoners: How a Venture Capital Group Does Scrum(やってみよう: ベンチャーキャピタルグループでスクラムを実践する方法)”、Agile Conference(アジャイル会議)、2009年。AGILE’09, IEEE 350-355、2009年。