スクラムレトロスペクティブで使えるWin/Learn/Tryの紹介

こんにちは、メルカリでCXP-Core(CXP: Customer Experience Platform)でBackend Engineer/スクラムマスターとして働いている@wakoです。今回は私のチームのスクラムレトロスペクティブで使われているWin/Learn/Tryフレームワークを共有させていただきます。*1

Win/Learn/Tryとは

Win/Learn/Tryとは、スプリント内の出来事をWin/Learnに分けてチーム内に共有し、新たなTryをチームで模索するフレームワークです。

以下で各項目の説明をします。

Win

そのスプリントで出した成果等を報告します。Winと言われてもピンと来ない場合はDone/Deliverと言い換えるとわかりやすいかもしれません。レトロスペクティブで利用されることの多いKPTでいうとKeepに近い項目ですが、Keepは少し抽象度が高くてイメージしづらいですし、よりポジティブで具体的な内容が出しやすい点でWinの方が気に入っています。

また、メルカリでは目標設定にOKRを採用していますが、OKRイベントにおけるWinセッションのようなニュアンスも取り入れた結果、Winというワードにたどり着きました。

Learn

そのスプリントでの学びをチームにシェアして、以降のスプリントに活かします。後述しますが、Fun/Done/LearnのLearnのアイディアをお借りしてきました。KPTでいうとProblemに近い項目ですが、問題ではなく学びにフォーカスすることで、前向きな気持ちで課題に向き合える点がいいなと感じています。

Try

WinやLearnから抽出された課題やチャンスに対してチームとしてどういったアクションを取るかのアイディアを出します。KPTのTryと同じ項目ですが、KPTより深堀りしたり抽象化をしたりしないと(特にWinからは)Tryにしづらいので少し難易度は高いです。

例1)
Win: 大変だったxxxの実装が無事完了した!

→ お疲れさまでした! 何か工夫をしたんですか?

→ ドメイン知識のある人にペアプロに付き合ってもらいました

→ Try: 今難航している別の実装でも詳しい人にペアプロをお願いしてみる

例2)

Learn: Aの箇所はxxxで実装されていると思っていたけど、yyyで実装されていた

→ Try: 週次の勉強会でシェアする

Win/Learn/Tryに辿り着いた背景

当初の課題感

2020年の年始頃まで、チームのレトロスペクティブはKPTやそれに類似するフレームワークで行っていました。しかし、KPTでレトロスペクティブを行うと既存のProblemにフォーカスしすぎてしまい、新しいチャレンジや「攻め」のアイディアが出づらいように感じていました。また、私のチームは小粒の課題は各人がそれぞれ解決できてしまうチームだったため、あまり大きなProblemが出ないということもありました。

Fun/Done/Learnを試してみる

他にいいレトロスペクティブフレームワークがないかと探していたときに見つけたのがFun/Done/Learnでした。ところが実際にチームでやってみたところ、FunやLearnも十分にアイディアが出て、チームの目指したい方向性が見えてこないという結果でした。
私の理解では、Fun/Done/Learnは「どのようにチームのFun/Learnを増やせるようなアクションを抽出するか」にバイアスがかかりやすいフレームワークだと感じていたので、既にFunやLearnの多い私のチームには向いていないように感じました。

また、何度か実施して改善しようと考えていたのですが、コロナウイルスによってWFH(自宅勤務)が始まり、ホワイトボード前提のFun/Done/Learnを実施すること自体が難しくなりました。

Win/Learn/Tryを考えつく

オンラインでの実施に向いていて、かつ新しいチャレンジや攻めのアイディアを抽出しやすそうで、私のチームにFitしそうなフレームワークをネットやアジャイルレトロスペクティブズから探したのですが、どうもピンとくるものがありませんでした。
そこで今まで経験したKPTやFun/Done/Learnからエッセンスを抽出してWin/Learn/Tryを考えつきました。*2

これってYWTなのでは?

この記事を書いている途中で、「これってYWTなのではないか」ということに気付いてしまったのですが、Y(やったこと) と Winではニュアンスが違うことや、YWTではY(やったこと) → W(わかったこと) → T(次やること) の流れでシーケンシャルにネクストアクションを導出する仕組みに対して、Win/Learn/TryではWinとLearnからパラレルでネクストアクションを導出する仕組みなので差別化できているのではないかという結論に至りました。

Win/Learn/Tryで何が変わったか

定性的な比較になってしまうため私個人の所感になってしまいますが、KPTと比較して

• KeepよりWinの方が何を書くべきかわかりやすく、チームの情報を拾いやすい
• ProblemよりLearnの方が、チームとしてのソリューションにフォーカスしやすい
• Win / Learnの方がポジティブな切り口でTryを考えることができる

といったメリットがありました。
図にしてみるとおおよそ以下のような配置になっており、よりポジティブな切り口が重視されているフレームワークになります。
*3

また、定量的に測る目的でKPTで行ったときとWin/Learn/Tryで行ったときでそれぞれの項目のアイディアの増減を計測してみたところ、

• Keepでは1回あたり7.3アイディア出ていたのに対してWinでは9アイディア出ていた
• Problemでは1回あたり6.8アイディア出ていたのに対してLearnでは7.3アイディア出ていた
• KPTでのTryでは1回あたり3.1アイディア出ていたのに対してWin/Learn/Tryでは2.8アイディア出ていた

という結果になりました。時期によって向き合っている課題や参加メンバー、チームのフェーズが変化するため、統計的にはあまり意味のない比較ですが、Winの項目は出しやすく、Tryを出すのが少し難しいという傾向があると言えるかもしれません。
*4

今後の課題

10回程度チームでWin/Learn/Tryを試行した結果、感じている課題は以下です。

• Winはポジティブな気持ちになれ、かつ分かりやすい切り口ではあるものの、個別の具体例が列挙されるため、Tryへ昇華するタイミングで深堀り等の工夫が必要
• LearnはWinとは逆に、起きた事象をどう学びに抽象化するかが必要なのでアイディアを出すタイミングでのハードルが少し高い
• Win/Learn/Try固有の問題ではないが、同じフレームワークを使っていると課題発見の切り口が同じになり、飽き/賞味期限がくるのでフレームワークのアップデートは常に必要

まとめ

今回はCXP-Coreチームのスクラムレトロスペクティブで使われているWin/Learn/Tryフレームワークを共有させていただきました。少し慣れないとTryが出しづらいという面もあるものの、ポジティブな切り口で課題にアプローチできる点が優れていると感じました。

もし現在のレトロスペクティブフレームワークに行き詰まりを感じているスクラムチームがあれば導入を検討していただければと思います。

Appendix

レトロスペクティブ中にWin/Learn/Try以外にやっていること

以下が私のチームがレトロスペクティブを行う際に使っているテンプレートです。

説明させて頂いたWin/Learn/Try以外にも以下の項目をチームで確認しています

• 前回のアクションアイテムの確認
  • 前回のレトロスペクティブで出たアクションが実行されたかを確認します
• スプリントの完了/バーンダウンチャートの確認
  • スプリントを完了し、そのスプリントでDoneできたタスク、できなかったタスクをチームで確認します。併せてバーンダウンチャートも確認します。
• Okimochi
  • WinでもLearnでもTryでもない「お気持ち」を共有する場です
  • IceBreakの意味合いが大きく雑談系の内容が多いです
    • 例1): デュアルキーボード、肩が開いていていい感じじゃぞ (@wako)
    • 例2: ゆるぼ)クーラー付けると寒い消すと暑い問題 (@xxx)
  • レトロスペクティブでいう「チェックイン/場を設定する」にあたります
• Discussion
  • チームでより深く議論すべき内容があれば記入する欄です
  • 多くの場合、課題感の頭出しだけして必要な人だけ呼んで別で解決するようにファシリテートすることが多いです
• Action items
  • Tryで出た内容をActionに落とし込んで、メンバーの誰かにアサインします
  • 次のレトロスペクティブの”前回のアクションアイテムの確認”の項目で進捗が確認されます
• Retrospective of retrospective
  • 今回のレトロスペクティブに対するレトロスペクティブを最後の3分程度で書きます
  • スクラムマスターはこの意見を見て次のレトロスペクティブの改善をします