初めてスクラム開発でプロダクトオーナーを担当して失敗したこと
はじめに
こんにちは。
僕は web 系の開発会社でスクラム開発チームのプロダクトオーナーをしている vanilla.dev と申します。
僕は現職で初めてスクラム開発に出会い、それもスクラム未経験でプロダクトオーナーを任せていただけたのですが、1 年弱プロダクトオーナーを努めてやってしまった失敗を振り返ってみたいと思います。
あくまで参考程度にみていただけたら幸いです。
ロードマップ適当に引きすぎ
僕のチームでは、現在稼働しているサービスの管理画面のリプレイスをしているのですが、あまりにも適当にロードマップを引きすぎました。
具体的には、ユーザーがあまり使わない機能をロードマップの最初に設定してしまっていたのです。
僕は、前任者から引き継いでプロダクトオーナーになったのですが、当時の自分は、プロダクトオーナーになったばかりで、新任でも問題なくスクラムを回せていることをステークホルダーへアピールすることを意識しすぎていました。最悪ですね。
結果的に、実装は簡単だが、ユーザーからのニーズは低い機能がロードマップの先頭に並ぶことになってしまったのです。
また、仕様の調査をしないままロードマップをひいてしまったため、リリースしても単体では使えない機能をリリースしてしまったこともあります。
その機能は、機能 A や機能 B に依存しているゆえに、単体でリリースしても全然使えません。機能 A や機能 B がないと使えないことに気づいたのはすでにその機能をリリースした後でした。
仕様がふわふわしたままスプリントを開始してしまう
スプリント開始前にバックログリファインメントをして、開発チームと十分な仕様検討をするのが理想です。
しかし、リファインメントの時間をまともにとらないままスプリントを開始してしまったため、考慮漏れや新たな仕様が見つかり、当初の見積もりから大幅に実装が増えるという最悪の事態を招いてしまいました。
結果としてスプリントゴールは達成できない、ベロシティが大きく下がってしまいました。
スプリントレビューでフィードバックを回収できない
プロダクトオーナーになった当初はスプリントレビューで全然フィードバックを回収できていませんでした。というかスプリントレビューがただのデモ実演会になってしまっていました。
当時を振り返ってみて以下の 2 点が理由として考えられるかなと。
スプリントレビューの意義・目的がわかっていなかったので、プロダクトバックログのデモ手順通りに動作することを見守る会議だと認識してしまっていたから
プロダクトオーナーになりたての頃は役員クラスの前でファシリテーションすることに慣れておらず、ファシリテーションだけで頭がいっぱいだったから
スプリントゴールが明確でないままスプリントをまわしてしまう
プロダクトオーナーになりたての頃はスプリントゴールを開発チームに伝えずにスプリントを回してしまっていました。
プロダクトバックログの上から n 個までをスプリントのタスクボードにいれるのみです。
このスプリントで達成したいことなどは開発チームへ全く伝えられていませんでした。
失敗から反省し、行動へ
上記のやらかしから反省し、少しずつ改善できました。まだまだ高いレベルでスクラムを回せているとは言えないかもですが。
具体的にはざっと以下のような行動をしてきました。
ロードマップの優先度を見直し、スコープごとにフェーズを区切り、段階的な開発に移行した
バックログリファインメントの時間を増やす
バックログリファインメントが間に合っていないタスクはスプリントに入れない
事前にステークホルダーにスプリントレビューの会議体を説明するミーティングを開く
改善のためのフィードバックはどんな些細なことでもいただきたい旨を強調して説明した
スプリントプランニングで最低限そのスプリントで達成したいことを説明
JIRA の「スプリントの目標欄」にもスプリントゴールを記載し、デイリースクラムでも繰り返し説明した
そもそも失敗に気づけたのは、チームにスクラムの経験が豊富なスクラムマスターがいたことや、スクラムの輪読会を開いて本来のスクラム体制のあり方をチーム全員が再認識できたことが大きいです。
まだまだ改善の余地があるスクラムだと思いますが、ちいさくカイゼンすることが大事かなと。