大きな試合に向けてトレーニングをするラグビーチームのように、スクラム手法ではチームワークをより効果的に高めて共通の目標を達成することができます。組織でスクラムの規模を拡大したくなった場合はどうすればよいのでしょうか。スクラムでは単一のチームによる複雑な製品の開発、デリバリー、維持のためのフレームワークが用意されています。一方、Scrum@Scale (S@S) では組織全体の文化を変革するためチームのエコシステム全体に焦点を当てています。
Scrum@Scale とは何か
Scrum@Scale は、スクラムの共同制作者でアジャイルマニフェストの共著者の 1 人である Jeff Sutherland 博士監修のもと、Scrum Inc. と Scrum Alliance のジョイントベンチャーによって開発されました。
Scrum@Scale はスクラムの基礎と、複雑な適応システム手法を採り入れています。Scrum@Scale ではすべてのメンバーがスクラム チーム内で交代可能で、目標に応じてスクラム チームが集まってエコシステムを形成します。Scrum@Scale は大企業での展開を念頭に設計されており、トレーニングと認定がオプションとして用意されています。
寛容さ、勇気、集中、敬意、コミットメント。
Scrum@Scale における Sutherland 博士の目標は、アーキテクチャの規模に囚われずにレベルを落とさず拡張することです。最小限の官僚主義 (MVB) を組み合わせることでこの目標の達成を目指しています。MVB は、創造性を損なうことなく、最小限のプロセスによって効率性と一貫性を維持している Mozilla と Spotify によって実用化されたアジャイルアプローチです。
これにより、従来の階層型グループが形成されるのを回避できるため、Scrum@Scale ではチームが追加されても複雑さが増すことはありません。チームからチームオブチーム、チームネットワークなどへの拡張というコンセプトが使われています。
その結果、Scrum@Scale の最優先事項によって、多くの組織が直面している次のような主要な課題を解決できます。
- 限られたリソースで効果的に優先順位を付ける
- 限られた時間の中で、問題なく機能する高品質なソフトウェアを提供する
- ソフトウェアの可能性をリファクタリングする
- 組織と製品の両方の観点から変化に適応する
Scrum@Scale の内容
Scrum@Scale の核となるコンセプト
Scrum@Scale には 3 つの核となるコンセプトがあります。
- 小規模チーム
- 組織全体で拡張する
- 最小限の官僚主義を適用する
スモールチームはスクラムの核となるコンセプトであり、チームオブチームに拡張する際に重要になります。チームのメンバーは通常、3 ～ 9 人になるようにするか、「ピザ 2 枚」ルールに従います (チームの人数はピザ 2 枚で足りる程でよいという意味です)。
うまく機能するスクラムチームを作ることが、組織全体にアジャイルプラクティスを拡張する Scrum@Scale の基礎となります。
この場合における最小限の官僚主義は、決定と実行までと定義されます。組織内におけるスモールチームでは、このアプローチによって障害を切り抜けることができます。
Scrum@Scale の構成要素
Scrum@Scale の構成要素は、組織が変革のバックログとアプローチを推進して独自のものにするのに役立ちます。
このフレームワークには、スクラムマスターサイクルとプロダクト所有者サイクルという 2 つのサイクルがあります。スクラムマスターサイクルでは「どうやるか」、プロダクト所有者サイクルでは「何をやるか」が明確になっていて、2 つのサイクルが重なる部分もわかります。
スクラムオブスクラムのコンセプトを使用することで拡張性のある構造を実現することができます。スクラムオブスクラムでは、各スプリントの最後にある製品のいつでも出荷可能な増分が完全に統合されたセットを、複数のチームがデリバリーします。
タイムボクシングとスプリントの境界線は大規模に緩和されることはありません。これらは組織の機敏性を実現するうえで重要な要素です。設定したスプリント目標の達成にチームが苦労している場合は、拡張を行う前に立ち止まって問題を修正します。チームのパフォーマンスの確認が必要な場合は、Jira スプリントレポートを使用して問題を特定しましょう。
Scrum@Scale の役割
Scrum@Scale ではスクラムの基礎を取り入れているため、プロダクト所有者とスクラムマスターの 2 つの役割があります。これらのコンピテンシーはスクラムガイドで定義されています。チームオブチームのコンセプトでは、新しい役割が導入されています。
- 最高プロダクト所有者 (CPO) は、各チームおよびプロダクト所有者と共同で、すべての関係者間のバックログ優先順位の整合性を取り、スクラムオブスクラムの戦略的ビジョンを設定します。CPO はスクラムオブスクラム内のすべてに対して 1 つのバックログを生成することに責任を負っています。
- スクラムオブスクラムマスター (SoSM) はスクラムマスターの役割を拡張したものであり、協力してリリースすることに責任を持ちます。
Scrum@Scale のイベント
スクラムでの主な成功要因は、これらのシンプルかつ強力なスクラムイベントです:
- スプリント
- スプリント計画
- デイリースクラム
- スプリント レビュー
- ふりかえり
スクラムを拡張する際は、チームは通常どおりスクラムを続けますが、1 つだけ追加のイベントがあります。拡張版デイリースクラムと呼ばれるこのイベントには、各チームの代表者の出席が必須です。
その内容はデイリースクラムとほぼ同じです。毎日 15 分かけて、スプリント目標におけるチーム内の障害、他のチームのリスク、チーム間の依存関係、改善方法、他のチームと共有できる知識について話し合います。
アジャイル組織におけるスクラムマスター – エグゼクティブアクションチーム (EAT)
スクラムを拡張すると組織の問題が何倍にも増幅されるため、Scrum@Scale ではエグゼクティブアクションチーム (EAT) が必要となります。このチームは変革戦略に責任を負い、スクラムの価値、ロールを実装するとともに意思決定をサポートし、障害を取り除きます。組織を変革する権限を上級管理職から得ることが EAT の前提条件になります。
EAT では通常、次の領域に焦点を当てます。
- すべてを重要としてマークせず、適切な優先順位付けが行われるようにする
- チームにすべてのスプリントを達成できる能力と環境が整うようにする
- 組織を継続的に改善し、分断をなくす
アジャイル組織におけるプロダクト所有者 – エグゼクティブメタスクラムチーム (EMT)
エグゼクティブメタスクラムチーム (EMT) は組織としてのビジョンを持ち、組織の戦略的な優先順位を設定します。このチームは組織の方向性を変えたり、どの製品やサービスを再編成または廃止したりするかを決定します。また、ロードマップにおける企業の意思統一を行い、定期的に、または必要に応じて編成されます。
このチームには CPO とビジネスオーナーが参加して、資金面、人材面、顧客へのコミットメントに対応します。EMT と CPO は緊密に連携して戦略、資金、リソースの配置などの必要な変更に取り組みます。
チームオブチームのやり方では組織に合わなくなってきた場合には、Scrum@Scale でさらなる拡張を目指します。スクラムオブスクラムと同じアプローチを使ってスクラムを拡張することで、スクラムオブスクラムをスクラムオブスクラムオブスクラム (SoSoS) に拡張することができます。
結論
Scrum@Scale によって組織は自分のペースで有機的に成長し、「スケールフリー」アーキテクチャによってスクラムチームを無制限かつ効果的に統合できます。このフレームワークのコンセプトは入念に文書化されていて、他のフレームワークに比べて指示の必要性が少なくなっています。これによって、スクラムがチームレベルでうまく使われている場合でも組織全体に Scrum@Scale を適用することができます
Scrum@Scale を導入する際は、優れたスクラムプラクティスに焦点を当ててから拡張し、変革を進め障害を取り除く権限のある EAT を確立することが重要です。現在のスクラムチームのパフォーマンスを把握するのに使える評価手法をオンラインで多数見つけることができます。チームのベロシティ、満足度、収益ポイントについては Jeff Sutherland 氏の提案から始めることをお勧めします。
次のステップ
Scrum@Scale のようなフレームワークは、企業が組織でアジャイルを効果的に拡張し、目標とするビジネスの成果の達成を支援する実用的な選択肢です。しかし、現行のプラクティスを拡大し、そうしたプラクティスのメリットを完全に実現できるツールを選択することも同様に重要です。アトラシアンの Jira Align はエンタープライズアジャイル計画プラットフォームです。Jira Align を使用すれば、可視性、戦略的整合性、企業の適応性を向上してデジタル変革を加速できます。
