レトロはふりかえりの場なのでふりかえる

TL;DR

• 改善のサイクルを設ける
• ふりかえりはふりかえりなのでふりかえる
• Actionはとりあえずやってみる。代わりに効果検証を忘れずに。

はじめに

レバテックの多くのチームではスクラムに取り組んでいます。
今回は、自チームのレトロスペクティブのやり方とその設計背景についてまとめようと思います。

なお、この記事はレトロスペクティブの一例であり、決してベストプラクティスの紹介ではないことにご留意ください。

レトロスペクティブについて

まず、レトロスペクティブについてスクラムガイドでは以下のように書かれています。

• スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
• スプリントレトロスペクティブには、以下の目的がある。
  • 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
  • うまくいった項目や今後の改善が必要な項目を特定・整理する。
  • スクラムチームの作業の改善実施計画を作成する。

スクラムガイドに書かれているように、レトロスペクティブとはスプリントを検査して改善計画を立てるためのスクラムイベントです。また、単にプロダクトを考えるのではなく、人・関係・プロセス・ツールの観点で検査するという点がポイントです。

位置付け

多くのスクラム有識者はレトロスペクティブが最も大事なスクラムイベントだと言い、最低限レトロスペクティブさえできていればスクラムは成り立つと言う方もいます。

さて、それはなぜでしょうか？

私はアジャイル・スクラムを実践する上で、「改善サイクルを回す」ことが必要不可欠だからだと考えております。

レトロスペクティブはチームに改善サイクルを根付かせるためのイベントであって、改善サイクルを効果的に回し続けられるかどうかがスクラムチームの成熟度を決める大きな要因になる。
そのため、レトロスペクティブの効果を最大化することで、チームの成熟度を高めることができるのだと考えております。

自チームのやり方

ここからは実際に自チームがどういうプロセスを築いているのか話します！
自チームでは「タイムライン+KPT」のハイブリット方式でレトロスペクティブを実施しています！

大枠の流れ

大枠の流れはこちらになります！

1. タイムラインに前スプリントのTryと出来事を洗い出す
2. 前スプリントのTryから効果、出来事からProblemを考える
3. 効果からKeepを決める
4. ProblemからTryを決める
5. 決めたTryを翌スプリントのタイムラインに置く

実際のアイテムはこのようなタイムラインで管理してます！

各フェーズでやること

1. タイムラインに前スプリントのTryと出来事を洗い出す

まずはタイムラインに出来事ベースのアイテムを置いてふりかえりの材料を集めます。
※前スプリントのTryは前スプリントでTryを決めたタイミングで今スプリントのタイムラインに置くようにします。

このフェーズは、レトロスペクティブの前にある程度洗い出している場合もありますが、レトロスペクティブの冒頭5分を使って洗い出すようにしています！

2. 前スプリントのTryから効果、出来事からProblemを考える

それぞれのアイテムに対して何が良かった/悪かったのかを考えることで、今回のスプリントの経験をもとに改善計画を立てることにつながります。

前スプリントで立てたTryに対しては実行した効果、スプリント中の出来事に対してはProblemを考え、見つかった問題はKPTのProblemセクションに起票しておきます！

【補足】前スプリントのTryの効果検証方法について

レトロスペクティブでは「人・関係・プロセス・ツールの観点で検査する」ため、
効果検証にはプロダクトの指標(ストーリーポイントやFourKeysなど)ではなく、定性面や自分たちで決めた指標を使うようにしています。

例えば、Tryが1日5分雑談をすることだった場合の計測指標は、下記のようなものになります！

• ムードメーターの1週間の平均値
• 問題発生時、メンバーに相談するまでのリードタイム
• レビューのやり取りの回数
• チームが前向きになれたと感じるか

3. 効果からKeepを決める

次に前工程で確認した効果からKeepに入れるか（継続するか）どうかを決めます。
続けることで効果が増大しそうであればKeep、これ以上改善される見込みがない、または効果がなかった場合は終了と判断します。

4. ProblemからTryを決める

次にProblemセクションに起票しておいたものから、それを解決するために何ができるのかを考えます。
ここに最も時間をかけてレトロスペクティブを進めることになりますが、レトロスペクティブの時間内に全てのProblemに対して話し切ることができないので参加者全員で投票をし、優先的に話す内容を決めています。

また、Tryを決める時は、誰かがモヤモヤした状態で決めてしまうと実行の効果が薄れたり、そもそも実行されなかったりするので全員にとって納得感のあるTryを作ります。
（ファシリテーターの腕の見せ所です）

5. 決めたTryを翌スプリントのタイムラインに置く

最後に、決めたTryを共通認識にして履行率を高めるために、翌スプリントのタイムラインにTryを置きます。
これはチーム全員でそのTryを実行するためにも全員が参加している場で作業します。

大事にしたこと

上記のプロセスを考える上で大事にしたことが３点あります。

改善のサイクルを設ける

まずレトロスペクティブについて考える前の前提として、スプリントにおける改善サイクルを考えました。
改善サイクルとは 実行 → ふりかえり → 次のActionを決める → 実行 → ...
を繰り返すことになります。

スプリント期間でこのサイクルを進めるには、レトロスペクティブでふりかえり＋Actionを決める部分を確実に履行する必要があります。

そのため、ふりかえらずにただやりたいことを次のActionに据えることや、ふりかえっただけでActionが決まっていないという状態を作らないよう留意しつつ、改善サイクルの基盤となるイベントになることを目指しました。

ふりかえりはふりかえりなのでふりかえる

2点目は実際のレトロスペクティブ中のプロセスについてです。
改めてスクラムガイドを確認すると、レトロスペクティブはスクラムチームを検査し改善計画を立てる場です。
検査して改善計画を立てるということは、検査がままならない状態で改善計画を立てても根本的な問題解決に繋がりません。
そのため、「スプリントの出来事をふりかえる」ことを重要視しました。

Actionはとりあえずやってみる。代わりに効果検証を忘れずに。

3点目は改善計画作成についてです。
自チームではこれまで、「設定したActionが履行されない」「履行されるもののその効果測定ができない」ということが度々発生してました。

ふりかえりは現状を好転させるためにやっており、何もActionをせず現状維持のままでは効果がありません。そこでまずは、
「Actionは簡単にできることを設定し一旦やってみる。やってみた効果を検証してダメなら辞める。」
という考えの浸透を目指し、試したことを絶対に振り返られるプロセスを設け、行動のハードルを下げることを重視しました。

効果

これまでのレトロは単なるKPT方式でやっており、

• 突発的にTryが生まれる
• Tryが履行されない、忘れられる
• KeepがDoneのような位置付けになって時間が経つと忘れられる

ということが時々発生していました。
ですが、上記で紹介したプロセスへ変更したことでそのような事態を防ぎ、継続的に改善できるようになってきた実感があります（あくまで定性的な評価です)

特に直近では、チームのフロー効率を上げるためには何をしていくべきなのかという観点で、毎スプリントTryを産み、試して検証してその効果からまた新たなTryを産むということができており、スクラムチームの成熟度も高まっているように感じています！

おわりに

今回は自チームのレトロスペクティブのやり方とその設計背景について話しました。

レトロスペクティブは形骸化したり、参加者に無駄な時間だと感じさせてしまうことも多い印象を受けますが、
目的を持って設計していくことでスクラムチームの成熟度を高めることのできるイベントだと私は思っています。

この記事を読んで下さったスクラム実践者の方には当然のことだったかもしれませんが、この記事がレトロスペクティブ設計の一助となれば嬉しい限りです！