In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?
まず第一に、スクラムではこれに対する客観的な答えがないことを理解する必要があります。検査して適応させる必要があります。スクラム ガイド (スクラムの発明者によって書かれた) のどこにも、PO が 2 つ以上の製品を扱うべきではないとは言及されていませんが、PO が成功するためには製品の全責任を負わなければならないとは言及されています。組織は PO の決定を尊重する必要があります。PO は、1 つまたは 2 つ以上の製品の製品バックログの「豚」です。PO と利害関係者がこれを処理できる場合、私はそれを試し、検査し、適応させます。 . また、製品の複雑さ、製品所有者の専門性、PO が複数の製品の PO の職務を遂行するために必要な帯域幅など、さまざまな要因もあります。試してみる前に、それらすべてを考慮してください。
Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?
繰り返しますが、それが「良い」かどうかを知るために、組織で試してみる必要があります。PO またはサブ PO を任命するときは、正しいスクラム ガイドラインに従ってください。私は自分の組織でそれを試してみましたが、驚くほどうまくいきました! チーフ PO と、サブ PO と呼ばれるその他の PO が何人かいますが、悪用するとプロジェクトが台無しになるコマンド アンド コントロールの動作を避けるために、全員を同じレベルに保つことを好みます。チーフ PO の仕事は、PO が自分の仕事で成功していることを確認し、必要に応じて PO を支援することです。また、PO の任命は、チーフ SM または SM とともにチーフ PO によって行うことができます。少し話が逸れますが、SMも同じ構造でした。チーフ SM の仕事は、SM が自分の仕事を成功させるのを助けることです。
Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.
すでに上で述べたように。私たちのエンタープライズ環境には、チーフ PO と他のいくつかの PO がいました。また、利害関係者を含む運営委員会もありました。各 PO には、管理する独自の製品バックログがありました。2週間のスプリントがありました。月に 2 回、すべての利害関係者とチーフ PO および PO が集まる「運営委員会会議」と呼ばれる会議を開催し、エンタープライズ製品を正しい方向に導き、各 PO が作業をスクラム用語 (潜在的に出荷可能なユーザー) に翻訳しました。各製品について、チーフ PO は、スクラム フレームワークについてほとんど知識のない利害関係者やメンバーから PO を教育し、保護するという重要な役割を果たしました. 彼らは、PO がハイジャックされるのを防ぎました. 各 PO には独自のスクラム チームがありましたSMとチームメンバーと。チーフ PO は、組織の高い地位にあるアジャイル コーチにすることをお勧めします。また、PO を同じ場所に配置します。特に、チーム間の依存関係や問題を解決するのに役立ちます。
注: 私たちにとってうまくいかなかったのは、1 つのチームに 1 つの製品バックログがある 2 つの PO でした。PO 間の競合が多すぎました!
お役に立てれば。
製品所有者は、サイズに応じて、複数の製品に対してこのロールになることができます。一方、大規模なエンタープライズ アプリケーションのサブ コンポーネントに対して複数の製品所有者を持つことができます。次に、「チーフ プロダクト オーナー」がいます。
それは完全に有効であり、お勧めです。
これらの概念はすべて、 Roman Pichler著の『スクラムを使用したアジャイル製品管理: 顧客が気に入る製品の作成』という本で詳しく説明されています。
スクラム ギャザリングで、こんにちはのスピーチを何度も見たり、話したりしました。彼の専門はプロダクトオーナーです。
スクラムまたはアジャイル チームでは、プロダクト オーナーが複数のプロダクトに関与することをお勧めしますか?
PO が各スプリントの前にプロダクト バックログに取り組み、一連の優先プロダクト バックログ アイテムを取得し、ROI を最大化し、スプリント中にチームが利用できる限り (つまり、 、POが仕事をしている限り）、問題ありません。そうでない場合、大きな障害がすぐに発生します。
エンタープライズ システムのプロダクト オーナーと、そのシステムのコンポーネントの「サブ」プロダクト オーナーを持つことは良いことですか?
これは実際、Scrum of Scrumsを使用してスクラムをスケーリングする場合の典型的なパターンです。また、スクラムを会社全体に拡張することは間違いなく実行可能です (スクラムは無限のスケーラビリティを実現するように設計されています -- Jeff Sutherland)。スクラムはすでに大規模なチーム (500 人以上) で使用されています。
しかし、スクラムを会社全体に直接拡張しようとは絶対に思いません。エンタープライズ全体のスクラム/アジャイル展開には従うべき手順があり、そうしないと気が狂ってしまいます (失敗の良いレシピです)。
Rally には、このトピックに関する IMO のすばらしいプレゼンテーション、ホワイト ペーパー、およびブログ記事があります (これらだけではありませんが、私は彼らの資料を楽しく読みました)。ご覧になることを強くお勧めします：
これらのリソースのいくつかを読むと、より良いイメージが得られると確信しています。しかし、これが簡単だと言っているわけではありません。
私は似たような状況でスクラムマスターをしていました。開発作業のサブシステムの「サブ」製品所有者または「共同」製品所有者を持つことができます。企業では、これはかなり一般的です。彼らは本質的に、ビジネス アナリストを含む「プロダクト オーナー チーム」になります。
ただし、このプロダクト オーナー チームには指名された「リード」が必要です。違いを解決し、バックログの全体的な優先順位を確立できる人 この人は、他のすべての製品所有者のニーズが満たされていることを確認する必要があります。実際には、これは通常、プロジェクト マネージャーでした。
別のアプローチは、サブプロジェクトを別々のスクラム チームに分けてから、「スクラム オブ スクラム」を作成することです。しかし、チーム間の情報の流れがより困難になるため、単一の開発プロジェクトではうまくいかないと思います。各サブ プロジェクトが互いに独立して機能できない場合を除き、最初のアプローチをお勧めします。