この記事は Holmes Advent Calendar 2020 - Qiita 12 日目の記事です。
こんにちは。 Holmesでスクラムマスターをしている吾郷です。
今日は自分が所属するHudsonチームで行ったスプリントレビュー改善について書きます。
背景と課題
Hudsonチームでは現在のプロジェクトに関わるステークホルダーを毎週スプリントレビューに招待しています。 様々な部署からご参加いただき、ステークホルダーの数は今や20名以上となりました。
組織の拡大に伴い参加人数が大きくなっている中で、ステークホルダーに求めていることや参加スタンスの統一が難しくなり、開発側からは「本来のスプリントレビューの目的を達成できていないかもしれない」、また、ステークホルダーからは「実際に何を質問してよいかわからない」といった声も上がっていました。 また、スプリントレビューを含める開発プロセス全体がステークホルダーや開発者内で不透明であることも課題のひとつでした。
そんな中、スクラムマスターが集まる会議で組織として上記のレビュー課題を改善していこうという流れになり、各チームでそれぞれスプリントレビュー改善を行う事となり、今回のワークに至ります。
やったこと
今回のワークは
- チーム内での理想とするプロダクト開発の流れの認識合わせ
- 現在のスプリントレビューに対する振り返り
- 振り返りからいくつか分類分けを行い、本来の理想の姿や大切にしたいことの洗い出し
- それを実現するためのTRY出し
といった流れで実施しました。
結果
ワークの結果
簡単ではありますが、生まれたTRYと解決したい課題を紹介していきます。
PO・SM・開発者それぞれで誰が行うかというところまで決めたTRYが生まれています。
スプリントレビューの目的資料を一枚挟む
- 担当：スクラムマスター
- 内容：スプリントレビューの始めにステークホルダーの方に向けて、このイベントの目的や求めていることを伝える。
- 背景：参加者の方々とスプリントレビューの目的の認識合わせができておらず、何を発言していいかわからないという状況。スクラムマスターがスクラムガイドにある通り、組織へのスクラムの適用を実現する。
PBとFBの状況を共有する
- 担当：プロダクトオーナー
- 内容：スプリントレビューの始めに、現在のプロジェクトの概要・今回のスコープ・過去のFBの状態を共有する。
- 背景：意見が活発にでない理由の一つに、出た意見の状態やどういう扱われ方をしているのかステークホルダーの方に不透明であることが原因ではないかと考えました。そこで、スプリントレビューで明確に伝えることで、意見を言う意義があることを示します。
ユースケースに沿ったデータの作成
- 担当：開発者
- 内容：ステークホルダーの方にイメージしてもらいやすいように、登録する登場人物などの情報を具体的なものにしておく。
- 背景：よく開発内のテストでも、アカウント名を"テスト"としたりすることが見受けられました。その状態でデモを行っても、ステークホルダーの方には、運用イメージがわきにくく、意見も出にくいといったことがありました。
TRYの結果
今回は、TRY実施後の成果指標としてFBの数と種類を各チームで集計し計測することとしました。 まさに、プロダクトの価値向上に寄与するFBをいくつ引き出せたか、いただけるかといったところを指標としました。
約一ヶ月半ほど計測してみた結果です。（Infinity、Trinityは別チームの名称です。）
TOが行き先です。簡単に定義を説明します。
Close・・・その場で回答し、解決したもの
PB・・・プロダクトバックログに追加となるもの
Research・・・プロダクトバックログに追加すべきか調査が必要なもの
Sprint・・・スクラムチームで検討すべきもの
二枚目は、スプリントレビューごとの推移です。
総計だけでみると判断しづらいかもしれませんが、推移で見るとチームのFBの変化が確認できると思います。 またHudsonでも、PBやResearchの分類も増えてきており、組織としても非常にいい形で動き出したように考えられます。
まとめ
FBを引き出す技術というのは、認識合わせや求めることの共通理解が必要なため大変難しいことだと感じています。 しかし、今回のワークでは改善の方向に進むことができました。 まだまだ開発としては課題も多いですが、チームないし組織として連携し、改善をしていきたいと思います。 実際にチーム間でも、レビュー用のテンプレートを用意したりといった動きもありました。
Holmesでは、スクラムを用いながらプロダクトを成長させ、契約に関する顧客課題解決を通じた価値提供をしていきます。 興味がある方はご連絡下さい。
