アート・オブ・アジャイルデベロップメント読書会 5.5 ふりかえり === ###### tags: `アートオブアジャイルデベロップメント読書会` [読書会インデックスページ](https://hackmd.io/qzr55OUxR_aKBNKZjRaxwA?view) # Discord開始位置 * [connpass募集ページ](https://agiledevs.connpass.com/event/211717/) * ハッシュタグ: [#agile_devs](https://twitter.com/hashtag/agile_devs) * [discord:2021/05/09](https://discord.com/channels/767540649418686486/774111081634332673/840890757288034304) # 自己紹介 - ファシリ役 - - 読み上げ役 - # 参加の仕方 - マイクはいつでもONにして、話に参加して結構です。 - テキストチャットでも、コメントやリアクションでどんどん参加してください!ラジオ担当が拾っていきます。 - 聞いているだけの方もOKです! # ディスカッションをより豊かにするためのグランドルール [アートオブアジャイル輪読会はじめの1歩 - Speaker Deck](https://speakerdeck.com/t3kob/atoobuaziyairulun-du-hui-hazimefalse1bu) - 参加者は毎回任意 - 今回は不参加、次回は参加をするといった気軽な感じ - 途中参加も断然OK! まずは聞くだけでも大丈夫です! - フィードバックを恐れない - マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう - アウトプット7割:インプット3割の気持ちで臨みましょう! - 経験の有る無しは気にしない - 自分はアジャイル非経験者だから……と気後れする必要はないです - 堂々と意見や疑問を語りましょう - ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです - 電子書籍で読んでいるとページ数ではわからないため - 話していない人が、率先してメモしましょう - このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1: :+1: :tada: - 気になる質問や同感するものには :+1: を末尾につけてください。 # タイムテーブル | 時間 | 所要時間 | 内容 |備考 | | -------- | -------- | -------- | -------- | | 19:30- | - | もくもくタイム | | | 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | | | 20:15-20:25 | 10分 | 参加者アンケート | | | 20:25-20:35 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | | | 20:35-21:35 | 60分 | 本の節ごとにディスカッション(ここでも適宜、HackMDに気づきとか書いていってもらっていいです) | | |21:35-21:40 | 5分 | 次回開催日と読む範囲決めてクローズ | | # 下に感想などを書いていって下さい。どんな些細なことでもOKです。 # 感想など > 5.5.5 ステップ 3:ミュートマッピング - 知らない手法でした。「話をしない」が印象的 ## 目安の時間 - 1トピックにつき10分を予定しています - 盛り上がったら延長することもあります ## 感想・気づき - 原題は Retrospectives - Second Edition も[著者ページ](https://www.jamesshore.com/v2/books/aoad2/retrospectives)で公開されてました。 :clap: ### 5.5.1 - ふりかえりを自分たちで実施する場合について、本文で言及されている参考資料 - Derby & Larsen 角征典 訳『アジャイルレトロスペクティブズ : 強いチームを育てる「ふりかえり」の手引き』オーム社、 2007.9 - Kerth, Norman. 2001. Project Retrospectives: A Handbook for Team Reviews. New York: Dorset House Publishing Co. 和書未刊 - https://learning.oreilly.com/library/view/project-retrospectives-a/9780133488753/ ### 5.5.2 イテレーションのふりかえりの実施方法 - > チームの仲がよいなら、誰でもイテレーションのふりかえりをファシリテートすることができる。しかし、 始めのうちは経験豊富な中立の立場のファシリテータを入れる方がよい。 - メンバー全員に当事者意識を持ってもらう為、ファシリは誰でも担当すべきだと思っていたが、仲が良くない状態でのファシリは心理的に重たかったり、人によっては やり方が分からず思わぬ方向に進んでしまったりするので、最初は経験豊富な人が行うということに、とても納得した。 - > 1. NormKerthのプライムディレクティブ > 2. ブレーンストーミング(30分) > 3. ミュートマッピング(10分) > 4. ふりかえり目標(20分) - 合計1時間。ふりかえりにかける時間を短くしたがる圧力は結構かかりがちな印象は持っている。:+1: ### 5.5.3 ステップ1: プライムディレクティブ - > 個人を非難したり攻撃したりするためにふりかえりを使用しないでください。 - 問題探しをしたい人はどうにも一定数いる。「**学び**、改善する機会」という意識は常に持ちたい。:+1::+1::+1: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840925346509225985) - > *今日私たちが発見したことに関係なく、私たちは、当時知っていたこと、スキルと能力、利用可能なリソース、および目前の状況を考えると、誰もが可能な限り最善の仕事をしたことを理解し、真に信じています。* - ノーム・カースの言葉はふりかえりのたびにチームで読みたい。最初の場づくりとしてこの認識を合わせるのは大事だと思う。 :+1::+1::+1: - 「攻撃しないこと」ってだけじゃなく、誰かの引用するとそれっぽくなるので伝え方としてよさそう。笑 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840925683747389440) ### 5.5.4 ステップ2:ブレインストーミング - > そして、ホワイトボードに次のような見出しをかく。 ・楽しいこと ・イライラすること ・悩ましいこと ・このまま ・増やす ・減らす - KPT に比べて、この見出しの粒度は直感的で分かりやすい。これくらい細かい粒度で見出し作ってた経験がある人がいたら、聞いてみたい。:+1::+1::+1::+1: - 後ろ三つだけやる(small starfish)のはやってました。結構チームから意見出やすくて良かったです。 - チームがコントロールできないアイデアでもよい。 - コントロールできないアイデアだと、アクションまで行き着かない気がするけど、それでもやった方いい理由ってなんだろう。 - 割と、「言ってもどうにもならない」と思ったアイデアも、場に出してみると議論からいいアクションが出てくる経験あります。:+1: - イライラすることと、悩ましいことの内容が若干被っていて、迷った時に悩ましいことへ倒しがちになりそうな予感はする - イライラすることが、間接的に誰かへの攻撃にならないかは気にする必要がありそう - 誰かへの攻撃にならないように(そう受け取られないように)発言にめっちゃ気を遣う。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840922481677303828) ### 5.5.6 ステップ 4:ふりかえり目標 - > 気に入っていたカテゴリがなくなったのが不満だって? 1か月か2か月待とう。もしそれが重要 であれば、いつかは注目してもらえる。 - ふりかえりですべてを解決せず優先順位付けるのよい。 重要であればあとで浮上してくるのもわかる:+1: :+1::+1: - 再び議題に挙がるというのは本当にその通りで、それよりも注力すべきことがアレコレと増えてしまい、ノイズのような形になってしまう方がデメリットに感じる - 振り返り目標、ってちょっと日本語が変 - Retrospective Objective、まあ直訳するとそうだけど、「振り返り自体の目標」に聞こえるので意訳しても良さそう - 以前、出たお題ずっと継続して優先度高いものは持ち越したんですが、管理めんどくさくて結局毎回イチから出した方がやりやすかったです ### 5.5.8 質問 - > (DeepL翻訳) 万が一、失敗したら、しばらくふりかえりの開催を中止する必要があるかもしれません。次回のレトロスペクティブには、組織開発(OD)の専門家を招いてファシリテートしてもらうことを検討してみてはいかがでしょうか。 - 専門家でなくても、チーム外の人を呼ぶ力は良い刺激になる話はよく聞く。 - > (DeepL翻訳) 最後に、チームがふりかえりで発言権を持っているとは感じていない可能性があります。あなたが行っている方法を正直に見てみてください。進行役というよりも、チームの鼻を明かしてしまっていませんか?次回のふりかえりでは、他の人にファシリテートしてもらうことを検討しましょう。 - リモート会議になって、進行役の催促に従ってしか喋らない場ができることもある。(「付箋を貼る時間を作る」→「内容について議論する」だと起きやすい) ファシリを回すことで、これは解消/改善できるのかもしれない。 ## 疑問・参加者に聞いてみたいこと ### 5.5.2 イテレーションのふりかえりの実施方法 - > 1. ノーム・カースの最優先条項 - :isnani: - 5.5.3で説明あり(このお話、名前ついてたのね) - 出典(Chapter One. Introduction to Retrospectives) - > Kerth’s Prime Directive > Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. - > DeepL翻訳 > 何を発見したかにかかわらず、当時わかっていたこと、自分のスキルや能力、利用可能なリソース、目前の状況を考慮して、誰もができる限りの仕事をしたことを理解し、心から信じなければなりません。 ### 5.5.3 ステップ1: プライムディレクティブ - > それでも出席者が同意しない場合は、ふりかえりを行いません。 - チームにここまで強烈な人がいたことはないのですが、経験ありますか?ケースによって、当人が合意できない理由の議論を先に解決する場を作る...など、どういった対処をしたか聞いてみたいです。 - 今回のは数ある振り返り手法の1つだと思いますが、みなさんどう言う振り返りを普段使っているのか聞いてみたいです :+1::+1::+1::+1::+1::+1: - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840911802652950539) - 親密度の向上を期待して ふりかえりを導入したが、そこまで効果を実感できていません。オススメの方法があれば聞きたいです(仕事と関係無い内容の記載も推奨しているがあまり出ないし、出ても深堀りするわけでもなく、効果を感じない。「お菓子を食べながらでOK」と言っても誰も食べない)。 :+1::+1: :+1: - ふりかえりの文化がないところで、毎回同じ過ちが発生しがちなので、ふりかえりを導入したい。まず何をしたほうがいいのか意見があれば聞いてみたいです。:+1::+1::+1: :+1: - うちのチームは、年間ふりかえりで タイムライン + YWT をやった結果、「こうやって情報共有できるのがいい」という意見が出て、短期ふりかえり(合わせてスクラムも)が導入されました。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840916143740420106) - ふりかえりのふりかえりを実践する頻度 - このふりかえりはよかったみたいな経験がある方がいたら、どんなふりかえりだったか聞きたい:+1::+1::+1::+1: - ふりかえり方法選んだり、というのはしています。なぜなぜとかばかりやると、重厚すぎて逃げる人出そうですね。 - [discord](https://discord.com/channels/767540649418686486/774111081634332673/840919394481733643) - keep等を、2イテレーション以上継続して残し、上手く行っているケースがあったら聞きたいです。次第にノイズとなり、在って無いようなものになっています:+1: - うまくいかなかった振り返りがあったら聞いてみたいです:+1::+1::+1: ### 5.5.3 ステップ3:ミュートマッピング - 親和図法 :isnani: - 原文は `affinity mapping` - 検索したら[でてきた](https://openpracticelibrary.com/practice/affinity-mapping/) ---- ## ミニエチュードの質問 * ミニエチュードは、このプラクティスに対して気づきを得るための質問です * 詳細はP76ページを参照してください * 以下の質問に、回答を継ぎ足していってください ### (このプラクティスを使ったことがなければ) - 何が簡単だと思ったか、何が難しいと思ったか、何が馬鹿げているように思ったか? - これまで経験したものとどう違うか? - 書かれているとおりに正確にやるには、どういう条件が当てはまっている必要があるか? ### (このプラクティスを使っているなら) - 自分がやっているプラクティスは、本書に書かれているもの突どんな点が違っているか?(気づいたことだけでいい、理由はいらない) - もし書かれているとおりに従うと、何が起こると思うか? - このプラクティスについて新しい洞察を得るために、お試しでやり方をどこか変えてみることはできそうか?(プラクティスが不適切だということを多足噛めるために、お試しでやってみるのは良いことだ)