Scaled Agile Framework(SAFe)を使用する最も一般的な11の理由と、スケーリングされていないスクラムでこれに対処する方法

そして、これがSAFeを使用するよりも効果的である理由

複数のチームで作業する際の非効率性を修正するために、スケーリングフレームワークを導入することを提案する人がよくいます。 チームが増えると、あらゆる種類の問題が表面化します。 スケーリングフレームワークの導入は、完璧なソリューションのように思えます。 正しい?

そのようなフレームワークの最もよく知られている例は、Scaled Agile Framework(SAFe)です。 プログラムの増分レベルでは、SAFeは製品の増分を作成する方法の1つとしてスクラムを採用しています。 そのため、スクラムの適応バージョンは、多くの場合SAFeの一部です。

人々がSAFeを導入すると、追加のイベント、アーティファクト、役割、ルールが導入されます。 これにより、環境がさらに複雑になり、独自の課題や問題が発生する可能性があります。 多くの場合、SAFeを使用して導入するリスクは、SAFeで解決したい問題よりも大きなものです。

ただし、SAFeを使用する最も一般的な理由は、軽量であるスクラムを使用することで対処できます。 最も一般的なスケーリングの問題に対処するためにSAFeは必要ないことを示します。

cocoparisienneによるPixabay

1.チーム間の依存関係を管理して増分を提供する

複数のチームが同じ製品で作業する場合、これらのチームは互いに依存していることがよくあります。 チームAは、チームBからのアクションを必要とする場合があり、その逆も同様です。 SAFeを使用すると、プログラムのインクリメント計画中にこれらの種類の依存関係を識別できます。通常、複数のスプリントを確認します。

スクラムには、この問題を取り除くための優れた方法があります。

「開発チームは部門の枠を超えており、製品の増分を作成するために必要なチームとしてのすべてのスキルを備えています。」 —スクラムガイド2017

各開発チームは、製品の実用的な部分を提供できる必要があります。 チーム間に依存関係が存在する場合は、これを制限して、依存関係がなくなるようにチームを再構成する方法を検討します。 これで、SAFeを使用する最初の理由がなくなります。

2.ビジョンから製品へ/企業レベルとチームレベルの整合

多くの場合、製品のビジョンは、貴重な製品が構築されるスクラムチームから遠く離れて作成されます。 SAFeには、追加のレイヤー(ポートフォリオや大規模なソリューション、あるいはその両方)があり、ビジョンをチームのバックログに流し込むのに役立ちます。

これはスクラムでこれを解決する方法です:

「製品バックログは、製品に必要であることがわかっているすべての順序付けられたリストです。 製品に変更を加えるための要件の単一のソースです。」 —スクラムガイド2017

はい。プロダクトバックログでは、ビジョンから価値を生み出す方法を提案します。 多くの場合、次のいくつかのスプリントに必要であると認識されたアイテムのみがログに記録されます。 しかし、スクラムガイドは、必要であることがわかっているすべてのものがそこにあるべきであることを非常に明確にしています。 完全に具体化する必要はありません。大きな作業の塊を表す漠然としたアイテムを使用できます。

3.製品の意思決定者と製品所有者の調整

多くの場合、製品の方向に関する決定は、製品所有者の範囲外です。 SAFeは、ビジネスオーナーやエピックオーナーなどの役割でこれに対応します。

スクラムだけで問題を解決する方法は次のとおりです。

「製品所有者は、開発チームの作業から生じる製品の価値を最大化する責任があります。」 —スクラムガイド2017

製品オーナーが製品の価値を最大化する責任を負うようにする場合、SAFeで定義されている追加の役割は必要ありません。

現在、製品バックログの製品責任と責任が分離されている別の状況にいる可能性があります。 ただし、複数のチームが存在する製品環境でより効果的にするには、製品所有者の役割を拡張してこれを変更することを検討してください。

4.組織のトップレベルに制御メカニズムを提供する

組織の最上位層の人々は、貴重な製品の作成に向けてチームがどのように取り組んでいるかを正確に知らないことがよくあります。 彼らは自分たちが関与している、または支配しているとは感じていません。 SAFeには、このための多数のレイヤーとイベントがあります。 逆に、これは誤用されてトップダウン制御を強制する可能性があります。

スクラムは、現在の状態を評価し、次に何をすべきかについて議論するための完全で純粋な場所を提供します。

「スプリントレビューの間、スクラムチームと関係者は、スプリントで行われたことについて協力します。 それとスプリント中の製品バックログへの変更に基づいて、参加者は価値を最適化するために実行できる次のことについて協力します。」 —スクラムガイド2017

はい、スプリントレビューは、現在の製品や、次に何をするかについての決定に影響を与える可能性のある事項について話し合いたい場合のイベントです。 関係者全員がディスカッションに参加できるため、直接的で効果的です。

あなたの役割が何であるかは問題ではありません。 製品の方向性に影響を与えたい場合は、スプリントレビューに参加してください!

5.配信の同期/増分の統合

複数のチームがある製品環境では、SAFeのアジャイルリリーストレインを使用して、複数のチームのリリースに向けて配信を同期します。

スクラムを使用すると、チームは複数の方法で作業を同期できます。 この中枢は:

「複数のスクラムチームが同じ製品で一緒に作業することがよくあります。 1つの製品バックログは、製品の今後の作業を説明するために使用されます。」 —スクラムガイド2017

これは次のことを意味します。

1製品バックログ→1製品所有者→1製品増分→1スプリントレビュー。

これにより、1つのスプリントレビュー中に検査する製品インクリメントが1つあるため、同期は自動的に既に適切に行われています。 この種のリリース同期の問題のため、スクラムの経験的なプロセス制御アプローチは無効にすべきではありません。 フィードバックループが壊れます。

代わりに、チームは真のアジャイルな方法で統合を容易にする方法を積極的に模索する必要があります。

「彼らは、洗練された開発アーキテクチャとターゲットリリース環境を通じて、コラボレーションと相互運用を行っています。」 —スクラムガイド2017

6.生産性を向上させる

SAFeは、チームの生産性を高めるためにしばしば導入されます。 生産性の低下の原因は、前述の問題のいずれかの組み合わせである可能性があります。

  • インクリメントを提供するためのチーム間の依存関係の管理。
  • ビジョンから製品へ/企業レベルとチームレベルの整合;
  • 組織のトップレベルに制御メカニズムを提供します。
  • 配信の同期/増分の統合。

これらの領域の改善は生産性の向上につながります。 生産性の向上は、(ウォーターフォール領域での)従来のプロジェクト提供アプローチと比較されています。

これらの改善をスクラム内で効果的に行う方法についてはすでに説明しました。 その結果、スクラムはすでに生産の大幅な改善を支援しています。 このため、SAFeを使用する必要はありません。

7.価値の提供を増やす

SAFeは、従来の製品管理の代替として提示されます。 リーンとアジャイルの原則とスクラムのようなフレームワークを使用して、SAFeは正しいものを構築することに焦点を合わせています。 SAFeは、これを確実にするために、定期的に反省の瞬間を持っています。

ただし、これらの反射の瞬間のほとんどは、すでにスクラムに組み込まれています。 ヘック、SAFeはスクラムで定義された反射モーメント(Sprint ReviewやSprint Retrospectiveなど)を使用します。複雑さが増すため、追加の反射モーメントのみが必要です。

スクラムで際立っているのは、これらの反射の瞬間が(主な利害関係者とともに)発生する頻度が高くなるためです。 これにより、俊敏性が向上し、新しい洞察に適応するためのオプションが増えるため、結果として価値の提供を増やすチャンスが高まります。

8.品質を上げる

SAFeには「組み込みの品質」があります。 これは、提供される製品が会社の品質基準を満たしていることを確認する方法の1つです。 組み込み品質の一部は、チームの「完了」の定義です。

ただし、スクラムは、「完了」の定義と同じことを行うことを目指しています。 すでに会社の品質基準が含まれているはずです。 「完了」の定義は通常、開発組織レベルで定義されます。 チームレベルではありません。

SAFeは、ビルトイン品質がスクラムの「完了」の定義を超えることを提唱しています。 私はこれに同意しません。 「完了」の定義は、開発組織がそれを作成するものです。 SAFeの組み込み品質と同じものを含めることができます。

9.組織図—製品に取り組んでいるすべての人々をどうするか?

SAFeは、組織のすべての人々が「アジャイルで作業する」ときにどこに適しているかという質問に対する便利な回答を持っています。 多くの役割があるため、誰もがいつでも場所を見つけることができます(ビジネス管理、製品管理、システムアーキテクト、システムエンジニア、リリーストレインエンジニア、さらに大規模なソリューションの場合はさらに多く)。

SAFeにおけるこれらすべての役割の存在は、「既存の組織に非常に簡単に適合する」というスタンスを可能にします。 これにより、組織に実際の変更を加える必要がなくなります。 それにより、組織は「アジャイル」のように見えても、実際には「アジャイル」ではなく、アジャイルな方法で作業することのすべてのメリットを失う可能性があります。

スクラムでは、そのような簡単な答えはありません。 スクラムは、3つの役割(プロダクトオーナー、スクラムマスター、開発チームメンバー)と関係者しか知りません。 これらはスクラム内の役割であることを理解することが不可欠です。 これは、会社の機能と同じである必要はありません。

スクラムはフレームワークです。 それはあなたにキャンバスを与え、あなたがあなたの絵をどのように作成しているかはあなた次第です。 しかし、これは誰がどこに行くのかという問題を解決するためのいくつかの例です:

  • プロダクトマネージャーは、スクラムプロダクトオーナーまたは主要な利害関係者である可能性があります。
  • システムエンジニアは、開発チームまたは主要な利害関係者の一部である可能性があります。
  • システムアーキテクトは、開発チームまたは主要な利害関係者の一部である可能性があります。
  • SAFeによって定義された(チームバックログで作業する)製品所有者は、製品エキスパートとして開発チームの一部になるか、製品所有者になることができます。

スクラムはあなたが最も有益だと思うようにそれを実装する自由を与えます。 これに対応するために追加のロールやイベントは必要ありません。 誰もがスクラムフレームワークを使用するためのアプローチにスポットを当てることができます。

10.複数の製品でプログラムを管理する

SAFeを導入するもう1つの理由は、多くの依存関係を持つ複数の製品でプログラムを管理するためです。

依存関係についてはすでに説明しました(トピック1と5が頭に浮かびます)。 ただし、この複数の製品の例を具体的に取り上げたいと思います。

まず、これはプロジェクト管理と製品管理を混同していませんか?

SAFeとスクラムは、どちらも貴重な製品を提供するためのソリューションです。 どちらもプロジェクト管理フレームワークではありません。

多くの依存関係を持つさまざまな製品がある場合は、製品として何を定義するかを再検討する必要があります。 製品の定義の再評価、その結果、製品ポートフォリオの再評価が必要になる場合があります。 これにより、透明性が高まり(プロダクトオーナーとしての責任者など)、SAFeを使用する必要性が明らかになくなります。

11.製品の方向性について複数の製品所有者を調整する

SAFeは、製品を担当する複数の製品所有者を調整するためのソリューションと見なされることもよくあります。 その後、作業は、プログラムまたはポートフォリオのバックログからチームのバックログに、製品所有者ごとに分割されて細かくなります。

この問題は、製品には1人の製品所有者のみが必要であることです(1つの製品バックログ→1人の製品所有者)。 したがって、1つの製品に複数の製品所有者がいることはアンチパターンです。 この問題を取り除くと、SAFeを使用する理由の1つであるこのタイプの配置の必要性もなくなります。

ボトムライン

Scaled Agile Framework(SAFe)には、より俊敏性のある作業に移行したい場合に、多くの一般的な問題のソリューションが含まれています。 ただし、問題を解決したい場合は、SAFeのすべての機能が必要なわけではありません。 本当に軽量なフレームワークであるスクラムでも同じ問題を解決できます。 スクラムを単独で使用することにより、不必要な複雑さとオーバーヘッドを回避できます。

私の助言は常にあなたの本当のニーズが何であるかを決定し、小さなものから始めることです。

複雑さを追加する方が、削除するより簡単です。 したがって、同時に多くの複雑さを追加する場合は常に注意が必要です。 徐々に追加して、本当に必要かどうか、そして本当に問題を解決できるかどうかを判断してください。 いったんそこから取り除くのは難しいです。

スクラムは、小さなものから始める方法の1つです。 スクラムを十分にマスターしても、何かが足りないと感じた場合は、いつでもスケーリングの方法を探すことができます。 ここでSAFeはオプションの1つですが、LeSS、Nexus、Scrum @ Scaleなどもあります。

あなたはスクラムの力に快く驚かれることでしょう。 スクラムだけで拡張できます。

スケーリングされたスクラムは依然としてスクラムです。 シンプルでパワフル。
あなたはシリアススクラムのために書いて、真剣にスクラムについて話し合いたいですか?