レトロスペクティブミーティングの前に、スクラムレトロスペクティブフィードバックを文書化する必要がありますか？
私たちのスクラムマスターは、レトロスペクティブの前に、反復のフィードバックを文書化することを望んでいます。彼女の主張は、彼女は私たちにフィードバックを文書化する時間があることを望んでいるということです。別の男は、ミーティング中またはミーティングの直前にフィードバックを文書化するべきだと考えています。
私は大学で働いているので、これを行うための最善の方法をまだ学んでいます。遡及フィードバックを処理する適切な方法はありますか？
Retrospectiveフィードバックを文書化する規定の方法はありませんが、考慮すべき点がいくつかあります。
考慮すべき最も重要なことは、チームがオープンで正直であることができる必要があるということです。電子ツールを使用していて、会議の前に回想ノートを完成させるように人々に要求している場合、それらのノートの作成者は個々の人に関連付けられている可能性があります。関係者は、チーム外の人が書いている内容を見ることができることを知っていると、完全にオープンで正直にならない可能性が高くなります。
とはいえ、回顧の準備をして、時間を十分に活用することが重要です。おそらく、チームが電子ツールにメモを追加できるようにすることは、そうするための良い方法です。しかし、それはチームメンバー間の自由でオープンで正直なコミュニケーションとバランスをとる必要があります。会議の前に「終了した」遡及ページを用意し、会議中に編集しないのは無理だと思います。
私の観点から、私が使用した最新のチームは、遡及的なメモにConfluenceを使用しました。遡及的なページはスプリントの早い段階で投稿され、チームはオプションで、話をするためにメモを追加して、物事を忘れないようにすることができました。しかし、回顧展自体では、私（チームのスクラムマスターとして）が追加のメモと編集を行っていたため、これ以上の議論を個々の人に結びつけることはできませんでした。唯一の期待は、チームが議論を行う準備ができていることであり、チームとうまくやり取りしているようでした。
チームは、組織の制約に基づいて、可能な範囲で作業方法を選択できるようにする必要があります。スクラムマスターは、チームの作業方法を指示するのではなく、効果的な技術について指導し、必要な作業を実行できるようにする必要があります。
問題に集中し、チームとして良い解決策を考え出してください。
標準的に言えば、チームに役立つことは何でもします。
そうは言っても、ドキュメントへの2段階のアプローチが理想的です。
フェーズ1：レトロの前に、各チームメンバーが自分のフィードバックを個人的に文書化します。
フェーズ2：レトロ中に、「うまくいったこと」のラウンドに続いて「うまくいかなかったこと」のラウンドを実行します。主なポイント、決定、およびアクションアイテムを文書化します。
振り返りの主な目的はドライブ変更およびreinforcegoodprocessesであることを覚えておいてください。 discussionとconsensusがなければ、それは起こりません。 誰も話す準備ができていない場合、ディスカッションは発生しません。そして、の場合、変更/強化は発生しません。チームはそれを文書化しません—理想的には一緒に。
個人的に、私は本当に私のチームメンバーが前もって個別にフィードバックを明確にし、文書化することに時間を費やしていることを感謝しています。ディスカッションが実際に発生することを保証します。また、接線での議論の結果、チームのドキュメントに重要なものが残されていないことを確認するのに役立ちます。
（また、遡及的プロセスはプロセスの1つであることを思い出してください）
ふりかえりのデータ/入力（=フィードバック）の収集は、ふりかえりミーティングの前、ミーティング、またはその両方（結合）で行うことができます。以下に、各アプローチの利点と欠点をいくつか示します。
会議前のデータ収集
会議の前に、Googleドキュメント、Confluence、Wiki、Slackなどの共有ドキュメントまたはワークスペースを使用してデータを収集できます。または、進行役として参加者に、収集した場所に入力を送信して配布するよう依頼することもできます。会議の前または開始時にチームに。
利点：
- 人々に回顧的インプットについて考える時間を与える
- 時間が許せば入力を準備できます（時間と場所は独立しています）。
- 時々人々が彼らの入力を読み直すとき、それは彼らに追加の事やより良い処方を考えさせる
- 内向的な人が意見を共有しやすくする
- Groupthinkを回避することができます（人々がお互いの入力を見ない場合）
- 進行役は入力を確認し、会議の前に追加または説明を求めることができます
- 質問を使用して、特定のトピックに入力を集中させることができます
- 話すことよりも書くことを好む人にとってはより簡単です（これにより、母国語以外の言語での回顧の言語障壁も低くなることに注意してください）
短所：
- 人々は入力をすることを忘れるか、それのための時間がないかもしれません
- 人々がインプットを提供するのに十分な規律を持っていない場合は、フォローアップが必要になる場合があります
- 入力の量と質は人によって異なります
会議でのデータの収集
利点：
- ファシリテーターとして、人々がインプットを提供するときに直接対話することができます
- 誰もが入力する時間があることを保証します
- あなたはそれをタイムボックス化することができ、必要なときにさらに入力が必要な場合はタイムウィンドウを延長することができます
短所
- 会議の時間の一部は入力の収集に費やされるため、分析とアクションに費やす時間が少なくなる可能性があります（会議の時間を増やすことを計画していない場合）。
- よりボーカルな人は他の人の発言を阻害する可能性があります（これに対処する方法があります）
- トピックについて異なる考え方をする人が発言しないグループ思考につながる可能性がある
状況と長所と短所に応じて、最適な方法を使用することをお勧めします。または、実験して、どのような状況で何が効果的かを調べます。
まず、フィードバックを文書化する方法自体が遡及プロセスの対象となることに留意してください。フィードバックの記録方法が気に入らない場合は、振り返ってみてください。私が参加しているほとんどのチームは、好きな方法が見つかるまでさまざまな方法を試し、それを使い続けます。
会議の前に書面で提供されたフィードバックに関する私の主な懸念は、時にはそれが実際に完全に議論されないことにつながることです。また、トーンや意味が他のチームメンバーに正確に伝えられない場合もあります。徹底的なディスカッションがあり、そのディスカッションに基づいてドキュメントを更新している場合（リアルタイムでも後でも）、問題なく機能します。
私はアジャイルスクラムのかなりモダンなスタイルで大企業の環境で働いています。各スプリントの最初に、私たちのスクラムマスターは各チームに匿名のスプリントボードを投稿します（つまり、開発者には独自の、QAには独自のなど）。これは、VPN上の誰にでも公開されるWebページにすぎず、リンクはチームの個人にのみ与えられます。ボードには3つの列があります：何がうまくいったか、何がうまくいかなかったか、および何をすべきか。
スプリントが進むにつれて、人々はボードに何かを追加します。スプリントの最終日には、各チームがスクラムマスターと座り、ボード上の項目を確認するミーティング（事前に十分に予約されています）があります。
このプロセスに従うことのいくつかの利点は次のとおりです。
- 匿名であり、誰もがボードにアイテムを置いたと主張する義務はないため、一般的に人々はより正直です。
- 私たちは自由にメモを取ることができますが、ボード上のアイテムによって取り上げられたトピックのみに焦点を当てているため、誰もが次のミーティングに向けて事前に準備することができます。
- スプリント全体を通して物事が頭に浮かんできたら、すぐにボードに追加できます。
これが最善の方法であるとは主張していませんが、私のキャリアを通じて、さまざまなチームがさまざまなアジャイルスクラムの実装を試すのを目にしてきました。
お役に立てれば、
乾杯！