以前、ふりかえりについて以下の記事を書きました。
記事を書いてから、チームが変わり、ふりかえりのやり方も変わって、当時(2021/06/20)と考えも変わりました。
自分の考えを整理するために、過去を振り返って後悔すること(やり方を変えたほうが良かったこと)、答えがわからないことをまとめておきます。
ふりかえりの過去と現在の違い
過去と現在でやり方には以下のような違いがあります。
観点 | 現在(2023/08) | 過去(2021/06) |
---|---|---|
開催場所 | オンライン(Google Meet) | オンライン(Google Meet) |
記録ツール | Miro | Googleスプレッドシート |
参加人数 | 6名 | 10名程度 |
ふりかえり手法 | KPT、YWT、+&Δ等 | KPT |
実施期間 | 6か月 | 1年6か月 |
実施頻度 | 1か月に1回 | 1か月に1回 |
ふりかえりMTGの呼び方 | スプリントレトロスペクティブ | 振り返り |
自分の立場 | ふりかえりのファシリテーター、Miroのボードを作る人 | チームのKPTの管理、振り返り後の改善活動の管理をしている立場 |
記録ツールがMiroに変わり、人数が少なくなり、会議の呼び方が変わりました。
後悔すること(やり方を変えたほうが良かったこと)
当時を思い出して、やり方を変えたほうが良かったと後悔することです。
ふりかえり手法をいろいろ試すべきだった。
KPTをずっと続けていて、マンネリ化していました。マンネリ化が悪いわけではないかもしれませんが、手法が固定されると、思考の仕方も固定されてあまり問題点が出てこなくなっていました。
現在は、いろいろなふりかえり手法を試していて、手法を変えると、思考の仕方が変わる感覚があります。
どんなふりかえりの手法があるのかは、以下の記事が参考になりました。
ふりかえりの手法をたくさん学ぼう
アイスブレイク大事
現在は、ふりかえりの開始時にアイスブレイクを実施していますが、これでチームの雰囲気に固さがとれるを実感しています。
「アイスブレイクやります。」ということに何か抵抗があり、実施していなかったのですが、積極的にやるべきだったと思います。
どんなアイスブレイクをするのか、、は悩みどころで検討の余地はあるかなと思います。
以下、アイスブレイクの方法で参考になった記事になります。
* 振り返りのはじめに行うアイスブレイクを紹介します! - Qiita
* 定例会議でジブリ制作日誌眺めの薦め - koudenpaのブログ
ふりかえりのふりかえり
現在は、ふりかえりの最後に、ふりかえりのふりかえりを実施しています。
このフィードバックをもとに、ふりかえり自体の改善ができます。
以前はふりかえりのふりかえりは、不定期での実施で、あまりふりかえり自体を見直すことに意識がいっていませんでした。
記録ツールを変える
Googleスプレッドシートだと実施が難しい。ふりかえり手法も、Miroだといい感じにできます。
投票機能や、非公開モード 等の利用でMTG自体も効率的に進めることができます。
Miroが利用できないケースは、Google系のツールが使えるのであれば、Jamboardを利用するでしょう。Googleスプレッドシートを利用していた理由はデータのTRY実施項目の管理からですが、データの管理よりもMTG時のコラボレーションを優先するべきであったと思います。
TRY項目が上がらないこと、TRYの実施進捗が出ないことに悲観的にならない
前チームでは、TRYの実施状況管理に疲弊して、モチベーションが下がっていました。
TRYの項目が上がらないこと、TRYの実施進捗が出ないことに悲観的になりすぎない、ふりかえりMTGでTRY項目が上がらなくてもOKにする。くらいで問題ないと思います。チームがチームの状況に向き合って会話でき、情報収集できたらOKだと現在は考えています。
答えがわからないこと
以下、答えがわからないことになります。
組織や職能でなんとなくある壁
開発パートナーの方に、参加してもらっているケースやエンジニア、デザイナーが混じるようなケースがありますが、組織、職能に違いがあると忖度、遠慮があるような気がします。感覚的に、忖度、遠慮がないほうが良いと思いますが、これを無くすための方法がわかっていないです。
TRYを実施するメンバーが限られる
スクラムマスターや、プロジェクトリーダー等にTRYを実施するメンバーが限られる印象があります。スクラムマスターや、プロジェクトリーダーは作業に余裕がある、ある程度、自分が何をやるかの裁量があるからだと思います。
開発メンバーに自発的に、TRYを拾っていってもらいたいのですが、この状況は作り出せていないです。
以上です。
コメント