アジャイル スケーリング: スクラム マスター向けの SAFe ベスト プラクティス

この記事は、Toptal のアジャイル スケーリング シリーズの第 2 部であり、プロジェクト マネージャーがチーム拡張の取り組みを行うためのガイドとなるように設計されています。 最初の記事「5 つのアジャイル スケーリング フレームワークの比較: どちらを使用すべきか?」をお読みください。 最も一般的なオプションの詳細な概要については、.

製品が成長し、より複雑になるにつれて、製品を生産するチームも成長します。 規模を拡大する時期になると、多くの企業がスクラムから、エンタープライズ レベルで実装されるシステムである Scaled Agile Framework (SAFe) に移行し、企業がチームのチームによる開発を必要とする複数の複雑な製品を管理できるようにします。

SAFe フレームワークに移行するスクラム マスターは、慣れ親しんだ新しい環境に足を踏み入れます。 成果物、役割、儀式はスクラムに基づいています。 しかし、大規模な運用には、特に一般的な軌道であるリリース トレイン エンジニア (RTE) の役割に移行することを選択したスクラム マスターにとって、いくつかの追加の責任が伴います。 RTE は、リリース トレイン全体のスクラム マスターとして機能します。 RTE は、9 ～ 11 人のスクラム チームを率いる代わりに、複数の部門にまたがるチームのサーバント リーダーになり、より大きな規模と範囲のイベントを組織します。

基本: スクラムから SAFe

SAFe を使用すると、企業はアジャイルのアプローチ、価値、および原則を複数のチームに適用できます。 結果として生じる「チームのチーム」は、アジャイル リリース トレイン (ART) として知られています。 個々のチームは引き続きスクラム マスターを採用して通常どおり業務を遂行しますが、ART でのスクラム マスターのような役割は RTE によって行われます。 RTE は、スクラムの一般的なメカニズムとガバナンスを適用しますが、チームではなく組織レベルで適用します。 それに応じて、他の従来のチーム レベルのスクラムの役割と成果物も変化します。 たとえば、ART の「プロダクト オーナー」はプロダクト マネージャーになります。 「製品のバックログ」はプログラムのバックログになります。 「スプリント バックログ」はイテレーション バックログです。 そして、「プロダクト インクリメント」は現在、プログラム インクリメント (PI) です。

SAFe には、Essential、Large Solution、Portfolio、および Full の 4 つの構成があり、どの構成を使用するかは、会社がフレームワークをどの程度広く採用しているかによって異なります。 この構成により、複数のチームが協力して作業することから、完全なポートフォリオ統合や企業全体のビジネスの俊敏性まで、複数のレベルでの実装が可能になります。 しかし、すべてのレベルで、目標はアジャイルとスクラムの実践を拡大することであり、それらを置き換えることではありません。

SAFe のスクラム マスター

チーム レベルで SAFe フレームワークで作業しているスクラム マスターは、自分の仕事がそれほど変わらないことに気付くでしょう。 彼らは、アジャイル チームのサーバント リーダーであり続け、コーチングと教育、障害の除去、チーム メンバーが安全に最善を尽くし、継続的に改善できる環境の育成に責任を負います。

ただし、いくつかの新しい責任が発生します。 SAFe スクラム マスターは、PI 計画イベントとプログラム実行で RTE をサポートし、ART 同期ミーティングでチームを代表します。 チームが取り除けない障害がある場合、スクラム マスターはそれらを RTE にエスカレーションします。

RTE になることを決定したスクラム マスターは、自分の役割には明らかに多くの考慮事項が伴うことに気付くでしょう。 ART には、ビジネス分析、ハードウェア、コンプライアンスなど、自分にとって初めてのチームやアジャイルに慣れていないチームが含まれる場合があります。 また、SAFe の上位構成にはプログラムまたはポートフォリオの運用が含まれるため、経営陣は、スクラムでは行われない方法で直接かつ定期的に関与し、すべてがエンタープライズおよび/またはポートフォリオ レベルの目標に沿っていることを確認します。

RTE は、1 つのチームの能力を超える障害を取り除く責任があります。 利害関係者とコミュニケーションを取り、ART レベルでの継続的な改善を推進します。 RTE はチームだけでなく、それらのチームのリーダーも指導し、ART のすべてのレベルが自己組織化と自己管理に移行するのを支援します。

SAFe イベント

スクラム マスターがチーム レベルのイベントを促進するように、RTE は ART レベルのイベント (PI 計画、ART 同期、システム デモ、検査と適応) を促進します。 RTE として、あなたはスクラム マスターとしてよりも幅広い利害関係者と関わり、利害が競合する複数のチームを扱うことになります。 どのイベントにも、より多くの、そしてより多様な参加者がいるため、優先順位を調整し、イニシアチブへの賛同を十分に前もって得る必要があります。

PI計画

PI 計画イベントは、PI 計画を作成することにより、今後 8 ～ 12 週間の ART 内のすべてのチームの目標を調整するための巨大な 2 日間のセッションである SAFe にとって不可欠なセレモニーです。 これはスプリント計画イベントに似ていますが、複数のチームにまたがる複数のスプリントにまたがっています。

入力

• 事業ビジョン
• 実装される上位 10 から 15 の機能のリスト
• 各チームのキャパシティの詳細

出力

• PI 計画 (次の 5 ～ 6 スプリントの実施計画)
• PI の目的
• 潜在的なリスクのリスト

PI 計画イベントに関する一般的なヒント

• 利害関係者の同意を得る。 会議の前に、RTE は主要な利害関係者を特定し、彼らの情報をグループと共有する必要があります。
• 優先順位を調整します。 セッションの前に、製品管理チームとの終日の会議をスケジュールして、提供する必要がある機能の概要と将来の優先事項について合意します。 イベントでは、リスクや依存関係など、解決すべきことがたくさんあります。基本的な方向性について合意しておくことをお勧めします。
• リハーサル！ PI計画は一大イベントです。 丸 2 日間のリハーサルは役に立たないかもしれませんが、ART のチーム リーダーとの 2 ～ 4 時間のセッションは、可能な限り近い経験を生み出すため、非常に役立ちます。 イベントの議題の簡略版を作成し、リハーサルの前に共有して、十分な情報から練習を開始できるようにします。
• ミッションクリープに備えてください。 PI 計画の目標は、比較的短期間で長期計画を実現することです。 時には人々は、イベントの目的ではない、あらゆることについて詳細に説明したいと思うでしょう。 リハーサルとセッションでチームリーダーにこれを説明してください。 チームに、次の 3 か月のすべての分を計画するのではなく、高レベルの計画を提供して足並みをそろえることが目的であることを思い出してください。
• チーム定員情報を準備します。 スクラム マスターに、今後 8 ～ 12 週間のキャパシティの計算を提供するよう依頼します。 何らかの反論や質問があることを期待してください。 たとえば、スクラム マスターは、チームが今後 2 か月間で何回欠席するかを正確に把握していない場合があります。 そのような場合は、見積もりを依頼し、PI 自体の間の容量制限に対応するときに柔軟に対応してください。
• PI 計画の議題を共有します。 イベントの少なくとも 2 週間前にスケジュールを配布し、多くの質問に答える準備をしてください。 多くの参加者があり、SAFe があなたとあなたの会社にとって初めての場合は、おそらく他の多くのチーム メンバーにとっても初めてのことです。 私の経験では、2 番目または 3 番目の PI 計画イベントまでに、チームがイベントに慣れ、何を期待するかを理解するにつれて、ファシリテーターへのプレッシャーははるかに少なくなります。
• 管理者の出席を確保します。 マネージャーやシニア マネージャーが 2 日間のイベントに参加するのは難しい場合がよくありますが、ハイレベルな連携を確保するためには、マネージャーの出席が必須です。 PI 計画の少なくとも 2 週間前に出席を確認し、必要なサポートを手配します。 同じことが、PI 目標を承認する必要があるビジネス オーナーにも当てはまります。

アートシンク

ART 同期イベントは、RTE がチームの進捗状況を把握し、プログラムのリスクと障害を特定できる週次ミーティングです。 RTE が障害を評価し、エスカレーションが必要かどうかを判断する唯一の機会ではありませんが、これらの問題が提起される定期的な場を提供する重要なイベントです。

入力

• チームの進捗
• 障害ログ
• PI 計画 (計画と実際の進捗との間の大きな逸脱を特定するため)

出力

• エスカレーション（必要な場合）
• PI 計画の変更に関する決定

ART同期イベントの一般的なヒント

• 定期的なコミュニケーションを奨励します。 ART Sync はスクラムのスタンドアップのように毎日ではなく毎週行われるため、RTE は、チームが緊急の問題をすぐに提起できること、および次の ART Sync を待つべきではないことを明確にする必要があります。
• データで準備してください。 スクラム マスターとプロダクト オーナーに、進捗状況について情報に基づいた会話を行うために、バーンダウンや累積フローなどの定量化可能な進捗指標を提供するよう依頼します。
• 毎週のステータスレビューを超えてください。 ART 同期は、単純なチェックインではなく、優先順位が調整され、問題が解決されるイベントであることを意図しています。

システムデモ

システム デモは、前のイテレーション中に作成された作業の全範囲を紹介することを目的としています。 このイベントでは、プロダクト マネージャーとそのチームがビジネス オーナーやその他の利害関係者に、ART の統合された進行状況を現在の形で示します。

入力

• 前のイテレーションの過程でのすべてのアジャイル チーム メンバーの出力に基づく作業の現在の状態

出力

• システムの目的への適合性に関するフィードバック
• バックログの変更 (必要な場合)

システム デモ イベントに関する一般的なヒント

• リハーサル！ 隔週で 30 ～ 45 分をプレゼンターと協力してセグメントを決定します。
• スライドを捨てます。 実際の統合作業を提示します。 ソフトウェア製品に取り組んでいる場合は、プレゼンターにスライド デッキではなく、作業中の製品の増分を関係者に見せてもらいます。 可能であれば、ステージング環境で製品のデモンストレーションを行います。 デモがエンド ユーザー エクスペリエンスに正確に似ている必要があります。 統合システムを 2 週間ごとに提示できない場合は、デリバリー パイプラインを確認し、CI/CD と DevOps 文化をどのように採用できるかについてチームとブレインストーミングを行います。
• ビジネス価値に焦点を当てます。 あなたのプレゼンテーションは、事業主と利害関係者を対象としています。 彼らにとって最も重要なことを共有します。
• フィードバックに焦点を当ててください。 利害関係者からのフィードバックは重要ですが、このイベントは製品のビジョンやロードマップを大幅に変更するときではありません。 チームが後でアクション項目に変えることができる高レベルのフィードバックに会話を戻す準備をしてください。
• 短くしてください。 利害関係者は多忙な人々です。 45 分から 60 分の会議では、より頻繁に熱心に出席することができます。
• 質疑応答の時間を設けます。 回答は透明にしてください。 「わかりませんが、調べることができます」が最良の答えである場合があることを忘れないでください。

検査と適応

検査と適応は、PI の最後に行われるメガ レトロスペクティブ セッションです。 セッションは3部構成で、

• PI システムのデモ: PI の統合された出力全体のショーケース。 これはメイン システムのデモに似ていますが、1 回の反復ではなく、このイベントは PI 全体にわたる統合された作業を紹介します。
• 定量的および定性的な測定: RTE が PI の過程で収集された指標を提示する機会。 これらのメトリクスには、チームのベロシティ、受け入れられたユーザー ストーリー、単体テストのカバレッジ、未解決の欠陥が含まれます (ただし、これらに限定されません)。
• ふりかえりと問題解決のワークショップ:参加者が PI を振り返り、うまくいったこととうまくいかなかったことを振り返り、体系的な問題を特定し、それらを解決する方法を提案する機会。

入力

• チームの進捗
• すべてのプログラムインクリメントの出力を含む、ART の統合作業の現在の状態

出力

• 潜在的な改善のリスト

Inspect and Adapt イベントに関する一般的なヒント

• 事業主に事前に通知します。 イベントの少なくとも 2 週間前に通知してください。 セッションの前に、参加しているプロダクト マネージャーやビジネス オーナーとミーティングを行い、定性的な結果のプレゼンテーションについて調整します。
• 上級利害関係者の出席を確保する。 チームの作業と進化する製品を紹介する PI システムのデモでは、彼らの存在が最も重要です。 通常のシステム デモのポイントの多くがここに当てはまります。事前にリハーサルを行い、プレゼンテーション スライドを避け、実際の成果物を紹介します。
• 非難を避ける。 セッション全体を通して、提示されたデータやふりかえりで特定された問題によって誰も脅威を感じないようにしてください。 一部のチームは、別のチームの数値が高いと嫉妬したり防御したりしたり、自分のチームに問題が発生した場合に選ばれたと感じたりする場合があります. このような問題を先取りするために、チーム全体の文化を受け入れます。
• 体系的な問題に焦点を当てます。 散発的な問題にあまり注意を向けないようにし、ブレインストーミングに必要なスペースをチームに提供し、提案された解決策に対して自由に想像力を働かせてください。
• 実行可能な提案を作成します。 イベントの最後には、チームが実装するバックログ アイテムが必要です。 問題を特定しても、問題を解決するための措置を講じなければ役に立ちません。

以下の表は、SAFe イベントとそれに相当するスクラム イベントを比較し、エンタープライズ レベルでのセレモニーの頻度と実行を示しています。

ステップアップとスケールアップ

スクラムから SAFe への移行は、威圧的なものになる可能性があります。 より大規模な運用では、最も慣れ親しんだ慣行でさえ、常に新しい課題と新しい考え方が提示されます。 RTEになることを選択した場合、仕事はあなたがすでに持っているスキルに最も依存していることに気付くでしょう. RTE は、スクラム マスターと同じように、チェンジ エージェントであり、サーバント リーダーです。この仕事は、企業レベルでこの役割を果たし、製品とともにスキルを向上させる機会を与えてくれます。