システムの機能要件を定義し、その優先順位を決め、開発プロジェクトを進行させるProduct Owner（PO）。役割としてとても重要であるのは間違いないのですが、SIerとしてAgile開発のプロジェクトに関わると、存外にこのPOという役割の重要性がクライアントにご理解頂けないことで、プロジェクトの運営に問題が生じることがあります。
Scrumを組めるほどに時間がない？
ウォーターフォール型のシステム開発と比べると、Scrumはかなり開発側とクライアント側（PO）がコミュニケーションに費やす時間が増える傾向があります。これがあるからこそビジネスに必要なシステムの要件がつぶさに検討できるし、軌道修正が迅速にできるし、ということになってきます。（多分）
しかし、ウォーターフォール型の開発でおおよそ典型的な週一、曜日と時間を指定したせいぜい1－2時間くらいの定例会と比較するとScrumの各イベントに要する時間というのは初めてこれに臨む人からすると「かなり多い」という印象を持たれると思います。
スプリント計画会議：約半日
バックログリファインメント：必要な都度
スプリントレビュー：そのスプリントでの全機能を一通り動かすしそれに対するフィードバックをもらうので2時間くらいは必要になってくる。
レトロスペクティブ：ワークショップ形式・全員参加の反省会。これも2時間くらいないとすごく中途半端になる。
普通のウォーターフォール型システム開発と比較して拘束時間が3－4倍くらいになるというのがScrum開発での感覚です。普通の事業会社の正社員だとシステム開発をすることに100％労働時間を投下できるわけではないので、大体のプロジェクトでこのうちのいくつかへのPOの参画が欠落していくのですが、多くのケースで「POが参加してくれるのがスプリントレビューだけ」という現実があります（笑）
結局、我々ベンダー側の営業だったりという人間がクライアント側のPOの代理だったり補佐だったりという立ち位置でスクラムイベントに参加するのですが、これは本来のクライアント側のPOとは似て非なるものであるわけで、顧客自身のニーズからは乖離していくことになるわけです。
一人では判断できない？
大企業は大企業とお付き合いしたがる傾向があるので、大きな企業には大きなSIerが普通は付きます。（作るシステムの規模も当然大きいので、小さなソフトハウスでは対応できないし何より保証できない）
そうなると、システムの要件を決めるという重要なタスクが「たった一人の判断」ということはありえなくなってくるわけです。大企業だと、要件を決めるために相当の数の部署だったりキーマンだったりというところと調整・根回しをしなければならないわけで、その意味で意思決定がたったの一人で完結するということはまずないわけです。
スプリントを開始する冒頭のタイミングでスプリント計画会議という、いわば「今後2－3週間で何をどういう順番で開発していくのか」という場が持たれますが、「何を」「どういう順番で」ということが、忙しい中一生懸命時間を工面してその場に居合わせてくれたPOの皆さんだけでは決めきれないという事態が生じます。
鉄は熱いうちに打て
この「POが思うようにイベントに参加してくれない」という事象はScrum開発の現場で非常にしばしば目にする状況です。これを防ぐには、プロジェクトが発足する冒頭の部分でウォーターフォールとAgileの違いを説明し、Agileを採用する場合には相応の「人的・時間的リソースの投下」と「その場で完結する意思決定の可能なメンバー」が必要だということをガッチリ説明してご納得頂いた上で始める、ということです。中途半端なScrumをやるくらいであれば「期間の短いウォーターフォールを繰り返す」という方が、まだ歪みが少なくて良いと思うのです。