なにこれ

「スクラム開発やりたくないです」と言われてしまったのです。。。

どんな流れで言われたの？

最近、開発プロセスをスクラム開発に変更しました。現在は2回目のスプリントが終了したタイミングです。

その2回目のスプリント終了直前のスプリントレビューでプロダクトオーナーから言われてしまった。。。

対象のユーザーストーリーは「プロダクトで低調になっている箇所の分析と可視化。そして打ち手の案を出す」という調査案件が2つあったですが、アウトプットのレベルが低かった事が2個ともつづいてしまったため言われてしまった。

なんでそんな事を言われたの？

プロダクトオーナーにヒアリングしました。
開発チームのアウトプットのレベルが低いと判定した理由は以下の通り。

• 対象KPIを構成する指標の一部のみを見て、そのKPIが低調であると断定したため
  • 実例) Aを構成する要素がB,C,Dと存在するが、Dだけを調査して原因であると断定した。
• 打ち手を複数提示したが、全てその打ち手が有効（と思われる）と思われる根拠を提示しなかった。
  • 実例）〇〇をやる。✕✕をやる。そうすると良くなりそう。

プロダクトオーナーやステークホルダーが質の低いアウトプットを受けた時の感情を想像すると以下のような感じかな。

• 2週間かけても大したモノが出てこないし、任せられない。
• そんなレベルであれば、他の事をやって欲しかった。。。

そんな事を言われる状態にしてしまって、私はとても気にかけています。
この状態のままだと組織としては「信頼出来ない開発チーム」となってしまい、ビジネスサイドで仕様まで考えわたすようになり、受託開発のようになっていき、開発チームはプロダクトに向き合えなくなります。

どうすれば良かったのか？

今回のケースだと、私はプロダクトオーナーと開発チームの間のゴールが共通認識が取れなかった事が原因だと考えました。
他の観点では、そもそも調査タスクのようなユーザーストーリーは本当に開発チームのリソースを使ってもやるべきなのか？とか担当するメンバーがそこまで経験していない事を1人でやるの辛くないですか？という声も上がりました。

そのため以下対策を講じる事にします。

• スプリントプランニングでプロダクトオーナーやステークホルダとユーザーストーリーのゴールを具体的な例を持って共通認識をとる。（ゴールの定義を明確にする。）
• 調査系のユーザーストーリーは他の開発より優先度が高いのか？の確認をとる。
• メインで担当するメンバーの力量が低い場合、1人にさせず複数人でユーザーストーリーに取り組むようにする。

これらをスクラムマスターとして意識して、開発チームが実践出来る様に支援して行こう。

2020/02/02 追記

改めて考え直したのですが、そもそも調査を行うだけってユーザーストーリーじゃないし、プロダクトに変化を与えられない事を開発チームでやるべきじゃないよね。

• その調査は機能改修するより優先されるもの？
• 調査するならゴールはどこ？
• 調査自体のビジネス価値は？
• スプリント単位で調べる必要あるの？
• 他に着手してみるべきストーリーがあるんじゃないの？

今後その調査が必要ならプロダクトオーナーに返すようにします。