スティーブ・オスターミラー（編）
優れたプロダクトオーナーは、スクラムチームが顧客にとって価値のある成果を達成するための鍵です。 効果的な製品所有者は、いくつかの一般的なパターンに従います。 最も苦労しているスクラムチームは、プロダクトオーナーの役割に関連する共通のアンチパターンに屈します。 これらのアンチパターンを繰り返す必要はないので、他の人の間違いから学ぶために読み続けてください。
組織、チーム、製品所有者が作成するアンチパターンと呼ばれる一般的な悪いプラクティスと、それらを完全に回避するための解決策(良いパターン)を学びます。
アンチパターンとソリューションに飛び込む前に、スクラムフレームワークとプロダクトオーナーの役割について簡単に見ていきましょう。
スクラムを一言で言えば
スクラム は、透明性、頻繁な検査、および複雑な製品を反復的かつ段階的に開発、提供、および維持するための即時適応を可能にするための経験的なプロセス制御フレームワークです。 また、 アジャイルフレームワークと呼ばれることが多いアジャイルの価値観と原則とも一致しています。
スクラムチーム内のロールには、プロダクトオーナー、スクラムマスター、開発チームメンバーが含まれます。 プロダクトオーナーは、製品の成功を左右する極めて重要で要求の厳しい役割を果たします。
プロダクトオーナーの役割
プロダクトオーナーの主な目標は、顧客、開発チーム、および利害関係者間の直接のコラボレーションを通じて製品価値を最大化することです。
製品所有者の主な責任は次のとおりです。
製品の目標を所有し、伝達します。
- 難しいビジネスの優先順位付けの決定を毎日行います。
- 開発チームと利害関係者にとって望ましい結果を明確にします。
- 要件を収集し、製品バックログを管理します。
- スクラムチームのピアメンバーとして、計画、改良、レビュー活動に参加します。
このような高い注文を達成するには、製品所有者はある程度のエンパワーメントを持っている必要があります。 組織は、彼らが決定的で、利用可能で、関与できるようにする必要があります。
さらに、その役割は優れたコミュニケーターでなければなりません。 さらに、ターゲット顧客のニーズ、製品開発ライフサイクル、およびビジネス戦略に関する鋭い知識を持っている必要があります。 製品所有者は、一般的なアンチパターンを回避する方法も知っている必要があります。
製品所有権のアンチパターン
アンチパターンは、製品所有者の繰り返し発生する問題に対する効果のない(場合によっては逆効果の)対応です。
このような悪いプラクティスを初めて防ぐには、プロダクトオーナーがスクラムチーム内での自分の役割を理解する必要があります。
製品所有者が直面する一般的なアンチパターンと、それらを回避するための効果的なソリューションを理解することも同様に重要です。
ここでは、最も一般的な製品所有者のアンチパターンとそれらを回避するための解決策を9つ紹介します。
アンチパターン 1 – 複数の製品所有者、1 つの製品
1 つの製品に対して複数の製品所有者が存在することは、よくあることです。 このシナリオは、従来の製品管理からの移行中に発生します。 多くの場合、リーダーシップが 1 人のプロダクト所有者にすべての利害関係者と協力する権限を与えていないことが原因です。 これらの利害関係者は、彼らが決定を下すべきだと主張するかもしれません。
委員会による製品の所有権は、方向性の欠如、利益相反、意思決定の遅れにつながり、製品の成功とチームの有効性を妨げます。
ソリューション: 各製品の意思決定者として 1 人の製品所有者を特定し、権限を与えます。 スクラムチーム(プロダクトオーナーを含む)と協力する方法について、他のすべての利害関係者に期待を設定します。 彼らに耳を傾ける方法を提供し、すべてのスプリントの進捗状況に関するフィードバックを提供します。
アンチパターン 2 – 1 人の製品所有者、複数の製品
1人の製品所有者が複数の製品の意思決定者である場合、彼らは薄く伸びていると感じるのが一般的です。 もちろん、これは意思決定とチームのパフォーマンスに悪影響を及ぼします。
このアンチパターンは、必要なリソースと適切な期待なしにチームのスケーリングが速すぎる場合によく発生します。
解決： 製品ごとに 1 人の担当者が、スクラム チーム、顧客、利害関係者の優先順位付けと共同作業において決定的に行えるようにします。 1つの製品に対してこれを行うのはフルタイムの仕事です。
アンチパターン3 – 可用性の欠如
製品間でプロダクトオーナーをスラッシングすることは、スクラムチームへの可用性を制限する1つの方法です。 アクセスできない、または利用できない製品所有者は、多くの場合、他のアンチパターンの副産物です。
「フライバイ」プロダクトオーナーは、十分な時間がないか、プロダクトオーナーよりも優先される他の責任が多すぎる結果です。 それは遅いフィードバックループ、ビジョンの欠如、そして方向の対立を引き起こします。 これは製品を不自由にし、チームメンバーからの極端な不信を引き起こす可能性があります。
解決策: スクラムチームの成功にはプロダクトオーナーの役割が不可欠であるという期待を組織全体で確立 (または再確立) します。 また、可用性の欠如を引き起こす製品所有者の他のすべての責任のインベントリを作成します。 責任ごとに、製品所有者ロールがそのアイテムを所有する必要があるかどうか、またはアイテムを停止、削減、または委任できるかどうかを尋ねます。 次に、それに応じてそれらの変更を進めます。
アンチパターン 4 – プロキシ製品の所有者
実際の製品所有者にアクセスできない場合、または利用できない場合、それらの役割と責任は「プロキシ」または「エージェント」の製品所有者の肩にかかっている可能性があります。
これは通常、脇役で行動する人であり、製品所有者が毎日必要とする厳しいビジネス上の決定を下す権限はありません。
代理製品所有者に依存した場合の結果は、製品所有者が利用できない場合と大差ありません。 これは優先順位付けを妨げ、意思決定を遅らせます。
解決： 製品には、完全に権限を与えられた製品所有者が 1 人いる必要があります。 製品所有者が本当に利用できず、製品の所有権を代理する必要がある場合は、プロキシが永続的に製品所有者ロールになるまでの一時的な解決策にする必要があります。
アンチパターン 5 – 重複する役割
役割の重複や役割の混乱は、スクラムチームの役割とアジャイルの原則についての理解の欠如に起因します。
このアンチパターンは、プロダクトオーナー、スクラムマスター、開発チームの役割と責任に明確な定義がない場合に発生します。 または、リーダーが 1 人のユーザーに複数の機能を入力させようとすると、コンテキストの切り替えにより生産性が低下します。
プロダクト所有者が開発チームのメンバーでもある場合、プロダクト所有者が顧客を効果的に代表する可能性は低くなります。 伝統的に、組織の「ビジネス側」の誰かが「技術側」に来て、何かを求めます。 技術チームがそれを作成し、ビジネスチームに引き渡します。 ビジネスチームは、「それは私たちが望んでいたものではありません…そしてそれはあなたのせいです。」
または、プロダクトオーナーとスクラムマスターが同一人物である場合、「要求を行う」人は「ルールを解釈する」人でもあります。 これは重大な利益相反です。
スクラムの役割は、独立した、個人、および仲間であり、可能な限り最高のコラボレーションのために互いに相殺する必要があります。
解決： 製品所有者は、顧客を直接代表し、顧客のニーズを綿密に認識し、望ましい結果を達成するためにビジネスに説明責任を負う必要があります。
アンチパターン 6 – スプリントの振り返りに関与していない
スプリントの振り返り会議は、チームの有効性を向上させるために重要です。 スプリントの振り返りに参加しないということは、スクラムチームが製品と顧客の問題に関連する改善の機会を逃していることを意味します。
このアンチパターンは、私たち(エンジニアリング)対彼ら(製品)の考え方を生み出す可能性があり、これは部門横断チームにとって有害で す。
解決： プロダクトオーナーは、スクラムチームのフルメンバーである必要があり、すべてのスプリントの振り返りに参加する必要があります。
アンチパターン 7 – 製品バックログの管理が不十分
プロダクト所有者は、開発チームの作業のバックログの作成と管理を担当します。
製品所有者が開発中に製品バックログを適切に維持できない場合、投資収益率と顧客の成果の両方が打撃を受ける可能性があります。
製品のバックログを詰まらせることも同様に逆効果です。
これは、製品所有者がアイデアや要件のリポジトリとして使用する場合に発生します。 製品所有者が利害関係者の要件をコピーし、それらを小さなチャンクで製品バックログに貼り付けると、詳細すぎるユーザー ストーリーが作成されます。 したがって、開発チームは、さらに改良する必要がないと感じないかもしれません。
プロダクトバックログは、開発チームに要件を渡すためのツールではありません。
解決： プロダクト所有者は、開発チームと定期的かつ一貫して作業して、プロダクトバックログを継続的に改善する必要があります。
アンチパターン 8 – 不適切なフィーチャ スライス
製品バックログ項目を適切に維持するには、機能のスライスが必要です。 このプロセスにより、小規模で価値のあるソリューションを段階的に開発および提供できます。
エンドツーエンドの機能に基づいて作業を分割しないと、リスクを軽減し、フィードバックを最大化することが困難になります。
解決： アイテムを垂直にスライスして、独立して価値があり、技術的にします。 そうすることで、開発チームは、部分的に価値のあるコンポーネントではなく、スプリントごとに有用で出荷可能な製品を提供できます。
アンチパターン 9 – 出力 > 結果の優先順位付け
アウトプットは私たちが生産するものです。 結果はプロセスの結果です。 出力、納期、リードタイムの短縮を優先することは、フィードバックサイクルには適しています。開発チームに損害を与える可能性があります。
この「より速く、より速く」アンチパターンは、プロダクトオーナーが利害関係者からの計り知れない外部圧力にさらされている場合、またはより従来のプロジェクト管理のバックグラウンドから来ている場合によく発生します。
プロダクトオーナーが質よりも量重視する場合、開発者は処理できる以上の責任を負う可能性があります。 また、長期的な製品の成功を妨げる誤解を招く指標をもたらす可能性もあります。
解決： 製品所有者は 、結果ベースのメトリックに焦点を当てる必要があります。 組織は、これらの成果を達成できるようにし、出力主導の指標を手放す必要があります。
アンチパターンのウサギの穴を避ける
プロダクトオーナーは、スクラムチームで厳しい立場にあります。 また、継続的な改善を促すものでもあります。 これらのアンチパターンを回避することで、効率、生産性、および結果が向上します。
これらのアンチパターンを回避するための最良の基盤を提供するために、製品所有者は認定スクラム製品所有者 (CSPO) トレーニングを追求する必要があります。 今日利用可能なクラスを表示します。
