Deep Dive: Retrospectives in Azure DevOps
もうすぐクリスマスですね('ω')
クリスマスといえばアドベントカレンダーなので、今回はこちらのアドベントカレンダーの企画に参加させて頂きました。
Azure DevOpsでレトロスペクティブをやる
今回は、Azure DevOpsの拡張機能、Retrospectivesを使ってスクラムイベントのひとつであるレトロスペクティブでの活用方法を実際のレトロスペクティブの進め方に沿ってご紹介したいと思います。
拡張機能いれたものの結構機能が多くて使いこなせてない、レトロスペクティブのイベントの中でどういう風に使っていけばいいのかいまいちイメージ湧かない、というお声も
あったので、そういったお困り事を持ってる方の一助となれば幸いです。
あくまでも活用方法の一例なので、必ずこの通りに使わねばならぬというわけでもないですが、
実用例のひとつとして参考になれば幸いです。
拡張機能Retrospectivesの本家の説明書は、こちらのReadMeになりますのでこちらも併せてご覧ください。
そもそもレトロスペクティブとは
ツールの活用の前に、そもそもスクラムにおけるレトロスペクティブとはなんぞやという所からおさらいをしたいと思います。
本家のScrum Guide 2020ではレトロスペクティブについて以下のように定義されています。
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリ
ントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、ス
プリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどの
ように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。
つまり、スクラムイベントとしてのレトロスペクティブの意義は、スプリントの中でのチームのパフォーマンスやふるまい、やってきたことを検査して、改善できることを特定して、
次のスプリントでのパフォーマンスをbetterにしていくための適応の機会をもつことだといえるかなと思います。
※今回はレトロスペクティブにフォーカスしているため、他のスクラムイベントは上記の図式では省略しています。
レトロスペクティブの流れとAzDO拡張機能Retrospectivesの活用ポイント
ここからは、レトロスペクティブの流れ、進め方を見ていきつつ、その中でRetrospectivesの拡張機能の活用ポイントをご紹介していきたいと思います。
Step0: レトロスペクティブの準備
レトロスペクティブの準備段階では、そのSprintでフォーカスして検査すべき内容を識別し、それをチームとしてふりかえるためのレトロスペクティブのフレームワークを選定し、進め方を検討します。
レトロスペクティブの準備では、以下のようなことを考えて、その時のレトロスペクティブで採用するフレームワーク、進め方、フィードバックの集め方を検討するとよいでしょう（例）。
- 予定していたスプリントゴールを達成できたか？できなかった場合、その理由はなぜか？
- チームのコラボレーションは効果的だったか？どのように改善できるか？
- 今回のスプリントで使用したワークフローやプロセスに関して、どのような問題があったか？
- コミュニケーションの面で、チーム内で何か改善点はあるか？
- 今のチームの雰囲気はどうだったか？
- このスプリントで遭遇した主な障害は何だった？これらの障害にどのように対処した？もっと効果的な対処法はあるか？
- チームメンバーは自身のスキルや知識をどのように向上させることができるか？
この準備の段階で、必要であればレトロスペクティブの時間でチームメンバーで使用するレトロスペクティブボードを用意します。
Azure DevOpsの拡張機能Retrospectivesでは、retrospectiveのボード作成時に以下の設定ができます。
Board Settings
Max Votes per Userの箇所は、集めたコメントに対して投票ができるようになっているので、その投票セッションの際に1人何票投票するかの上限を設定できます。
他に、以下の項目が設定できます。
-
Include Teams Asessment
チームメンバーから匿名で意見を収集できるAsessmentを追加するかどうかのオプション（詳しくはこちら） -
Obscure the feedback of others until after Collect phase
これを有効にすると、コメントの収集フェーズではコメントの内容と起票者がマスクされます。 -
Display 'Retrospective Prime Directive'
これはレトロスペクティブ実施時のマインドセットのようなものを表示するかしないか、という設定です。これを有効にするとこんな感じでレトロスペクティブボードのタイトルの横にPrime Directiveが表示されます。
これを押下すると、レトロスペクティブを実施する上での心構えが表示されます。
「私たちが何を発見しようとも、誰もがその時点で知っていたこと、自分の技術や能力、利用可能な資源、そして目の前の状況を考慮し、できる限りの仕事をしたと理解しているし、心からそう信じている。
Retrospectives拡張機能のReadMeでは、レトロスペクティブ開始時にこれを表示して読み上げて、この場で発見したことは個人の問題ではなくプロセスの問題として取り組まれることをremindするのがおすすめである、とあります。大事なことですね(´ω｀)
It is recommended that you click on the Prime Directive and read it out loud for everyone to hear. Remind everyone that any issues discovered will be assumed to be process problems, not people problems.
- Do note display names in feedback
メンバーから集めるコメントに名前を記載するかしないかを設定できます。
Column Settings
今回やるレトロスペクティブのフレームワークに従って、テンプレートを選択
レトロスペクティブ=KPTをやるというわけではないので、その時のチームの状況に合わせて最適なレトロスペクティブの手法のテンプレを選んでください。（たとえば前回のsprintではTeams Confidenceが低そうだったらTeam Confidenceを選ぶとか）カスタムでも作れます。
※こういうときはどんなふりかえりの手法が有効？を考えるためには以下の本がおすすめです
様々な状況、その時の考えたいことに合わせた手法が紹介されています。
レトロスペクティブ本番
Retrospectives拡張機能では、以下の4つのタブが設定されています。
レトロスペクティブの進行に従って、各タブを切り替えていきます。
- Collect
フレームワークに沿って、各列に対して今回のスプリントでのコメントを収集する。 - Group
集まったコメントで、似た内容や同じような内容のコメントをグルーピングしていく。
これによりレトロスペクティブでfocsuして話し合うべき対象が絞られる - Vote
グルーピングされたコメントに対して各メンバーが投票する。
これによって最も票を得たコメント=その時点でチームの関心が高い事柄 をキャッチすることができる - Act
Voteまでのフェーズで上がったコメントに対してディスカッションする。
ここで取組むアクションを特定し（できれば）、改善タスクを作成する。
Step1: Collect コメントの収集
※今回はStart（始めるべきこと）-Stop（やめるべきこと）-Continue（続けるべきこと）のフレームワークを使ってます。
この段階ではメンバーから今回のスプリントでのチームとしてのパフォーマンスを振り返って、フレームワークに沿ってコメントをとにかく収集します。
コメントの収集に関するよくある質問↓
Q.コメントはレトロスペクティブの時間で収集すべきですか？それともレトロスペクティブの前に収集すべきですか？
これは私が実際のお仕事中にアジャイルコーチに聞いた質問です。
答えとしては、「Sprintの状況とそのときふりかえる内容による」。
レトロスペクティブでは特定のテーマ（今回のSprintで起きてしまったデグレやバグなどの、チームに大きなインパクトがあった特定のインシデントについて等）を決めてそれについてdiscussionするとかもありです。
（そのSprintでチームに対してインパクトがある事象が起きたのに、そんなときにタイムボックスを消費してKPTやってる場合ではない）
こういう割とすぐにアイデアが出てきにくいテーマに対して事前に改善案出せ！意見出して！って言っても無理があるので、ちゃんと集まってフォーカスしないとそもそも意見が出てこないようなテーマ、もしくはSprintがめちゃくちゃ忙しくて１人でふりかえるような余裕もないようなときに「事前にコメント書いてね」も結構しんどいので、その場合はレトロスペクティブの時間でふりかえりにフォーカスする時間をある程度確保する方がよいかなと思います。
逆に、KPTやGodd-Bad-Ideasのようなフリーコメントで意見が出せるようなテーマであれば、事前に意見を集めても意見は出やすいかなと思うので、１人でふりかえる時間を持って書いてもらう、というのもありだと思います。
Q. レトロスペクティブを実施してもあんまりコメントを書いてくれません。どんな工夫ができますか？
あくまでAzure DevOpsのRetrospectivesの機能の中でできる工夫としては、
- 匿名で意見を集める
- コメントを収集フェーズでは非表示にする
というのはTryできるかなと思います。
どちらもRetrospectivesのボードを作成する際に設定が可能です。
1番に関しては、Do not display names in feedbackを有効にすると、集めるコメントは全て匿名になります。
意見がなかなか出てこないときや、なんとなくチームの雰囲気悪いから匿名でぶっちゃけでコメント書けるようにしよう、というときに設定してました。
2番目はObscure the feedback of others until after Collect phaseを有効にすることで設定できます。
これによって他の人の意見が収集フェーズ（メンバーがコメントを書く段階）では表示されなくなるので、他の意見に引きずられずに意見を出しやすくする効果があります。
あとは、機能以外の所でいうと、基本的なところですが、毎回のSprintで様子を見ながらどういうテーマだったら出しやすいのかを考えるとか、これはなるほどとは思ったのは敢えていつもやってることとは逆のテーマを設定して書かせてみるというものでした。
（例えばいつもは「どうすればもっとよくなるのか？」にフォーカスしているのであれば、「最悪な状態の開発環境とは何か」とかに対して考えてみるとか。
そうすれば裏と表で「こういうことにネガティブを感じているのであればこれを回避できるようにしよう」という風に考えることができる）
Step2: Group コメントのグルーピング
一番上のタブでGroupに切り替えます。
この段階では、最初のコメント収集フェーズでとにかく集めたコメントをグルーピングしていきます。
集まったコメントは貴重なフィードバックです。しかしレトロスペクティブの時間は有限、、、
全部に対してディスカッションしてたらあっという間に時間がなくなってしまうので、これ以降のフェーズでは今回のレトロスペクティブでディスカッションする対象を絞っていきます。
この段階では、集まったコメントの中で似た内容のコメントをグルーピングして整理していきます。
例えばBadのレーンに集まったコメントを見ると、水色枠のコメントは両方ともテストが手動であることに関するコメントです。これは同じ内容のコメントなので、こういったコメントをグルーピングします。
これを一緒にしたいコメントをグルーピングしたい対象のコメントに向かってdrag&dropすると、
こんな感じでグルーピングされます。
> を押下すると、グルーピングされたコメントが表示されます。
Step3: Vote フォーカスしたいコメントへの投票
Step2のグルーピングで似たような内容のコメントがグルーピングされました。
次は各コメントに対して投票を行います。
タブをVoteに切替えて
そうすると各コメントへの投票ができるようになります。
ここで今回のレトロスペクティブでフォーカスして話したいこと、共感したコメントに対して各メンバーに投票してもらいます。
投票はコメントの↑を押すと投票ができます。
↓を押すと投票の取り消しができます。
自分の持ち票の残りは左上のVotes Used: で確認できます。
Step4: Act フォーカスしたい内容を話し合って改善アクションを特定
タブをActに切り替えます。
そうすると、Step3で投票された票が多い順に上から並びます。
これによりチームメンバーがフォーカスしたい内容が視覚的に確認できます。
ここからより票が多いコメントにフォーカスして「これ次の改善アクションとしてはどういう風にする？」みたいなディスカッションをしていきます。
が、投票をしても票が多いコメントが多い！残り時間が！ということもあるので、タイムボックスを遵守するために上手い事タイムマネジメントをしながらディスカッションをしていきます。
そんなときに便利な、ストップウォッチ機能があります。
ここのFocus Modeを押下すると
こんな感じで各レーンごとに票が多い順で一つずつコメントが表示されます。
これでディスカッションすべきことに集中できます。
さらに。▶を押下すると、ストップウォッチになって、このコメントにどれぐらいディスカッションをしているかを確認しながら進めることができます。
議論が白熱してくるとついつい一つのコメントに時間を掛け過ぎてしまって、「えっ！もうこの話題で10分使っちゃってた！」とかも割とあるので、この機能は結構おすすめです。
タイムボックスを意識しながら話すべき事を話してアクションを決めてタイムマネジメントして、、、っていうのは割と大変なので、是非このストップウォッチ機能も活用してみてください。
ディスカッションをして次のスプリントはこれをやろう！という改善のアクションが特定できたら、+ Add work itemからタスクを作成します。
ここからwork itemを作成すると、retrospectivesで記載されたコメントがDescriptionにデフォルトで設定され、feedback``reflect-hubのタグが設定されます。
話合ったけれども改善のアクションが特定できなかった、、、でもこの問題は今後もチームとして改善すべきだ、、、という場合も、「この問題に対処していくべきである」ということがわかったということで、Impedimentとして登録して継続して取り組んでいく、という風にしてもよいと思います。
Team Assessment：チームに最適なレトロスペクティブのテンプレートの適用
番外編として、Team Assessmentの機能を紹介します。
ここのTeam Assessmentを押下すると、心理的安全性とかエネルギーとかワークライフバランスとか各項目入れてもらう感じのアンケートっぽいものが表示されます。
ここでの回答はRetro Summaryで匿名で平均化されます。
収集した結果はRetrospective Summaryから確認できます。
Readmeでは、これをレトロスペクティブ前に実施してチームの状態を見てみて、Unfavorableが20%を超える項目があった場合、その問題について話し合えるようなレトロボードのテンプレを選んでボードを作ってレトロスペクティブを実施してみることをお勧めしています。
これによりチームの反応に基いて適切な改善の機会を特定することができるとのことです。
例えばここでUnfavorableが20%以上を超えているPsychologycal Safety（心理的安全性）の項目のDiscuss and Actを押下すると、
このボードのテンプレを変えていいですか？というダイアログが出てきます。
OKを押下すると、
What makes it safe（何によって安心を感じたか）- What hinders safety（何によって安全性を阻害されたか）- One action in next sprint（次のsprintのためのアクション）
という感じで、Psychologycal Safety（心理的安全性）にフォーカスできるテンプレートが自動で適用されます。
Team Assessmentを使用する場合、このようにテンプレートはアセスメントの結果によって適用されるので、作成時にはinclude Team Assessmentに✓を付けた状態でテンプレートは選択せずにボードを作成し、
コメント収集のstepの前にアセスメントをチームメンバーに入力してもらってから特定の項目でのDiscuss and Actを選択することでその問題に対してフォーカスできるテンプレートが適用されます。
まとめ
今回はスクラムのレトロスペクティブでのAzure DevOpsのRetropspectives拡張機能の活用方法についてご紹介しました。
ツールはあくまでもツールでスクラムのマインドセット自体が大事なのはいうまでもありませんが、ツールを活用することでスクラムイベントを効果的に進めることもできるので、ぜひ試してみてください。
Discussion
Azure DevOps のスクラムイベントのレトロスペクティブの活用に関する包括的なガイド(特にチームの振り返りセッションが強化される内容だと思います）をありがとうございました。
準備からアクションまでの各ステップの詳細な説明により、プロセスが非常に明確になった気がします。
特に投票機能と、それが問題の優先順位付けにどのように役立つかに興味がそそられました😄
ありがとうございます！
チーム内で活用して頂けると幸いです('ω')