Blog

プロダクトオーナーのアンチパターン

 2018/03/12
このエントリーをはてなブックマークに追加

みなさんこんにちは。@ryuzeeです。

スクラムにおいてプロダクトオーナーは非常に重要な役割を果たしますが、一方でうまくやるのが難しい役割でもあります。 たとえばプロダクトオーナーには、ビジネス価値を最大化する、プロダクトのビジョンを周りに示して理解させる、プロダクトバックログを管理する、ステークホルダーをマネージする、開発チームの成果物の受け入れ可否を判定するといった多岐に渡る責任があり、限られた時間の中でバランスを取りながらやっていかなければいけません。

今回は、こういうのは避けようというアンチパターンを紹介します。

そもそも…

  • 多忙すぎるプロダクトオーナー
  • 不在のプロダクトオーナー
  • スクラムイベントに参加しないプロダクトオーナー
  • 単にマネージャーやリーダーという理由だけのプロダクトオーナー
  • そもそも複数人で意思決定権限が分散されたプロダクトオーナー
  • プロダクトオーナーとスクラムマスターを兼任する
  • スクラムマスターと対話できない、スクラムマスターからのフィードバックを受け入れない

開発チームやスクラムマスターとの関わり方

  • 開発チームとプロダクトオーナーという対立軸で理解しておりスクラムチームの一員という自覚がない
  • 開発チームのやり方(How)に口を出す、指示する
  • 開発チームの見積もりに疑問を投げかける
  • 開発チームが技術的負債に取り組むことを許可しない
  • 開発チームのメンバーがステークホルダーと直接話すことを許可しない
  • 開発チームとのコミュニケーションをメールや電子ツールに頼りすぎて、対面でのコミュニケーションが不足
  • 開発チームからの質問に回答したがらない、回答しない
  • 開発チームの話を聞かない
  • 開発チームに何をする必要があるか指示し、マネージャーとして行動する
  • 開発チームの行動や進捗やタスクの状況を監視する
  • 開発チームとプロダクトオーナーの関係性に受発注の図式を投影している

ステークホルダーとの関わり

  • ステークホルダーに「No」を言わず、プロダクトバックログがどんどん肥大化する
  • ステークホルダーなどに惑わされて頻繁にプロダクトバックログの並び順を変更する
  • ステークホルダーをスプリントレビューに招待しない
  • ステークホルダーや顧客のニーズや意見を聞きにいかない
  • ビジネスのKGIやKPIにコミットしていない

プロダクト

  • アイデアを実装する前にアイデアを検証しない
  • 開発中のプロダクトに対するビジョンの欠如
  • 役に立つ機能よりも、多くの機能を提供することに価値をおいている
  • 品質に重点を置かない

プロダクトバックログ

  • なぜそのプロダクトバックログ項目が必要なのか理由を明らかにしない
  • 大きすぎるプロダクトバックログを分割していない
  • 細かすぎるプロダクトバックログを用意してしまう(交渉の余地がなくなってしまう)
  • ビジネス関連のプロダクトバックログに焦点を当てるのではなく、技術の観点でプロダクトバックログを表現する
  • プロダクトバックログ項目に明確な受け入れ基準を用意していない
  • 開発チームにプロダクトバックログ項目の作成を丸投げして、成果だけ確認する
  • Readyでないプロダクトバックログ項目を開発するよう押し付ける
  • プロダクトバックログ項目の優先順位付けをしない
  • 明確な優先順位付けの考え方がない

スプリントでの活動

  • 見積りを締め切りとみなす
  • スプリントプランニングで決めたプロダクトバックログ項目すべてを完成させるために、開発チームに残業を求める
  • スプリント中に優先順位を変更する
  • スプリント中に要件を変更する
  • 受け入れ確認が恣意的だったり、追加要求を出す
  • 部分的にしか完成していないプロダクトバックログ項目を受け入れてしまう

それでは。

 2018/03/12
このエントリーをはてなブックマークに追加