5 つのアジャイル スケーリング フレームワークの比較: どれを使うべきか?

これを想像してみてください: プロジェクトの開始時に、製品の目標を達成することに専念する、単一の効果的な機能横断型の個人チームを編成します。 パフォーマンスを改善するには、チームがアジャイルに習熟していることを確認します。 製品の需要が高まり、要件が増え、バックログが拡大します。 あなたと他の利害関係者は、チームを拡大する必要があることを認識しています。 おなじみですか？

スケーリングにより、複数のチームが連携してアジリティを維持できます。 チームが妥当な時間内に処理できる以上の作業が必要な場合は、スケールするときです。 ただし、そのためには適切なフレームワークを選択する必要があり、いくつかのフレームワークから選択できます。 選択を誤ると、実装が失敗し、生産性が損なわれ、重大な経済的影響が生じる可能性があります。

チームに最適なフレームワークは、利用可能な資金、組織のアプローチ、製品の複雑さなどの要因によって異なります。

いつスケーリングする必要がありますか?

スケーリングを検討する前に満たすべき重要な基準がいくつかあります。

1 つのチームだけで開発を管理できますか?

スケーリングされたアジャイル フレームワークの実装は複雑で時間がかかる可能性があるため、必要がない場合はスケーリングしないでください。 チームのワークロードがその能力を上回っている場合は、スケーリングが必要です。

あなたのチームはアジャイルですか?

おそらく最も重要な基準は、チームがアジャイル アプローチに習熟しているかどうかです。 チームがアジャイルの経験がない場合、スケーリングによってさらに多くの問題が発生します。

チームの開発プラクティスを改善する必要がありますか?

チームのエンジニアリング プラクティスが効率的でない場合、スケーリングによって望ましい結果が得られない可能性があります。 DevOps や CI/CD パイプラインの適切な実装などのプラクティスは、チーム間の一貫性にとって不可欠です。 また、標準化された品質保証がなければ、新しい機能をテストするのが難しい場合があります。

あなたのチームは統合された増分を提供していますか?

スケーリングには、同じ製品で共同作業している複数のチームを統合することが含まれます。各チームは、連携して機能する機能を作成します。 次の表は、チームと製品の 4 つの可能な構成の詳細を示しています。 スケーリングが必要なのは 1 つだけであることに注意してください。

スケーリング フレームワークの選択

選択できるアジャイル スケーリング フレームワークは数多くありますが、最も広く使用されている 5 つのソリューションに焦点を当てます: Scaled Agile Framework (SAFe)、Nexus、Large-Scale Scrum (LeSS)、Scrum@Scale、Disciplined Agile (DA) . これらは最も効果的なフレームワークであり、さまざまなシナリオや組織に適用できることがわかりました。 次のセクションでは、独自のスケーリング コンテキストに最適な選択を行うために必要な情報を提供します。

1. スケーリングされたアジャイル フレームワーク (SAFe)

SAFe は、アジャイル スケーリングの最も一般的なフレームワークです。 2021 年の調査では、アジャイル実践者の 37% がそれを使用していることがわかりました。これは主に、複数の構成が原因であり、そのすべてがバリュー ストリームに焦点を当てており、明確に定義されたガイドと手順があります。

SAFe は 50 人以上の人員を必要とする複雑なソリューションを提供するために使用されるため、チームをアジャイル リリース トレイン (ART) に編成します。 ART 内のチームを同期させるために、SAFe はスクラム スプリントに似たプログラムのインクリメント イテレーションを使用し、各イテレーションは通常 8 ～ 12 週間続きます。 このアプローチにより、製品マネージャーは全体的な目標に集中し、過度の変更を導入することなく、複雑な製品ロードマップを効率的に監督できます。

SAFe はスクラム フレームワークに基づいていますが、いくつかの重要な違いがあります。SAFe の採用は、チーム レベルではなくエンタープライズ レベルで行われます。 スクラムは、優先順位付けに関する唯一の権限をプロダクト オーナーに与えますが、SAFe はより民主的なアプローチを奨励します。

SAFe には 4 つのレベルの実装があります。

エッセンシャル SAFe

Essential SAFe は SAFe の基盤であり、後続の構成に進む前に習得する必要があります。 スクラム マスター、プロダクト マネージャー、プロダクト オーナーなどの確立されたスクラムの役割を利用し、リリース トレイン エンジニアという新しい役割も導入します。 この人物は、サーバント リーダーおよび ART コーチとして機能し、チームが目標を調整できるように導きます。 ART には 5 ～ 12 のチームがあり、各 ART は完全なソリューションを提供できます。

大規模なソリューション

この構成は、Essential SAFe の上に位置し、「ソリューション トレイン」と呼ばれる概念を導入します。 これは、複数の ART の調整を必要とする大規模で複雑なソリューションを構築する場合に使用されます。これには、数百人または数千人の人員が同じバリュー ストリームに取り組んでいる可能性があります。 たとえば、Microsoft で働いていて、Excel、Word、および PowerPoint をプログラミングする 3 つの別々のチームがある場合、それらはすべて同じ価値の流れである Microsoft Office に貢献しています。

ポートフォリオ

ポートフォリオは、さまざまなバリュー ストリームに取り組む複数の ART で構成されます。 Microsoft の例を続けます。会社の Office、Skype、または Xbox 製品に取り組んでいる別々のチームです。

フルSAFe

この構成は、すべてのレイヤー (Essential、Large Solution、および Portfolio) を組み合わせて、企業全体のチーム管理を調整します。

2.ネクサス

Nexus フレームワークもスクラムに基づいていますが、SAFe より軽量であり、3 ～ 9 チーム間のコラボレーションを容易にする小さな調整のみが必要です。 Nexus の実装に追加の役割は必要ありません。 むしろ、各チームの 1 人の代表者が、1 つの目標に向かって作業を調整する中央統合チームに参加します。 スクラムと同様に、すべてのチームがスプリント計画セッションのために集まり、その結果が共有の製品バックログを形成します。 進捗状況を確認するために、各チームはスタンドアップに似たミーティングを毎日開催し、統合チームもチームの進捗状況を報告するために集まります。

スプリント中、チームは改良セッションに参加して、バックログの優先順位付けと見積もりを行います。 チームの数が増えるとバックログ管理の複雑さが増すため、Nexus は改良セッションを義務付けています。 チームは、各スプリントの後に、レビューとふりかえりのために集まります。

3. 大規模スクラム (LeSS)

LeSS は Nexus とほぼ同じですが、命名規則や追加のチーム固有のスプリント計画セッションなど、小さな違いがあります。 また、8 つ以上のチームのコラボレーションをサポートする 2 番目の構成である LeSS Huge で拡張できるという点でも異なります。

LeSS Huge は、開発の組織化に顧客中心のアプローチを採用しています。 作業を効果的に管理するために、プロダクト オーナーは高レベルのプロダクト バックログをより細かいアイテムの小さな「エリア バックログ」に分割し、さらにそれらを要件エリアに分類する必要があります。

これらの所要量エリアは、エリア プロダクト オーナー (APO) によって管理されます。 APO は各分野に関連する分野に特化しており、複数のチームと協力してその分野のソリューションに取り組んでいます。 バックログに格納されている各要件は 1 つの要件領域にのみ属し、各領域は 1 つの APO によってのみ管理されます。 プロダクト オーナーと APO は、プロダクト全体の視点で優先順位付けを担当するチームを形成します。

4. スクラム@スケール

Scrum@Scale は Scrum の拡張であり、習得と理解が最も簡単なフレームワークです。 1 つのチームからチームのチームまでスケールします。

フレームワークのコア コンポーネントは、スクラム オブ スクラム (SoS) です。 各チームは、SoS ミーティングで代表する個人を選びます。このミーティングは、通常、個々のチームのスタンドアップ後に毎日行われます。 毎日の SoS ミーティングの目的は、チーム間の調整とコミュニケーションを支援し、依存関係や重複を簡単に管理できるようにすることです。

このフレームワーク内の固有の役割には、本質的にはスクラム マスターの拡張バージョンである SoS マスターと、チームのプロダクト オーナーと協力して SoS の共同バックログを形成するチーフ プロダクト オーナーが含まれます。

Scrum@Scale は他のフレームワークよりも規範的ではないため、組織は独自のペースで拡張できます。 チームの数が増え続け、SoS ミーティングが大きくなりすぎた場合、組織はフレームワークをスクラム オブ スクラム オブ スクラム (SoSoS) にエスカレートできます。

5.規律あるアジャイル (DA)

DA が他のフレームワークと異なる点は、従わなければならないルールを持つ厳格なフレームワークではなく、最も適切なスケーリング戦略を選択できるツールボックスとして機能することです。 これは、スクラムやかんばんを含むさまざまなフレームワークのコンテキスト駆動型のハイブリッドであり、「選択は良いことです」という原則に基づいて、各プロジェクトのニーズに合わせて調整できます。 DA は、すべてのチームと組織はその規模、分布、およびドメインにおいて独自のものであり、各チーム メンバーも独自のスキルと経験を持つ独自のものであるという考えに基づいて構築されています。

これは、ソフトウェア開発チーム レベルまたは企業全体で適用できます。 後者の場合、DA ツールキットは、さまざまなビジネス機能 (財務、IT 運用、ベンダー管理など) が対処すべきものを特定し、そのためのさまざまなオプションを提示します。

DA は 3 つのプロジェクト フェーズ (開始、構築、および移行) を区別し、それぞれが提供指向のプロセス目標を構成します。 このフレームワークはビルドだけではなく、デリバリー ライフ サイクル全体に焦点を当てているため、他のフレームワークよりも多くの役割が導入されます。 すべての DA チームに見られる主な役割は、利害関係者、チーム メンバー、チーム リーダー、プロダクト オーナー、およびアーキテクチャ オーナーです。 スケーリングを支援するために一時的に使用されることが多い 5 つのサポート ロールもあります。スペシャリスト、ドメイン エキスパート、テクニカル エキスパート、独立テスター、およびインテグレーターです。

DA を他のフレームワークの上で使用して、さらに拡張することができます。

慎重に選択し、ゆっくりとスケーリングする

アジャイル チームをスケーリングし、その作業をシームレスに統合することは困難ですが、最適なフレームワークを選択することで簡単に行うことができます。 意思決定プロセスを導くための最初のステップとして、以下のフローチャートを使用してください。

ここで紹介したものの中から、組織の経験、アプローチ、予算、および製品に合ったスケーリング フレームワークが見つかると確信しています。 どのフレームワークを選択する場合でも、急がないことが重要です。段階的に拡張して混乱を最小限に抑え、事前に十分な変更を計画してください。

スケーリング活動でこれらのフレームワークを利用したことがありますか? コメント欄であなたの経験について教えてください。