スクラムマスターを雇うときにすべき38の質問

ちょっと職場で話題にのぼったので、ちゃんと全部答えてみた。
理想(目標)を中心に書いているので、現場でこの通りにできているかと言われたらNoである。

自分に限らず、言ってることをそのまま出来る人は多くないんと思うので、おそらくこれらの質問は必要条件であって、十分条件にはなりえない。（意識の高さはわかるかもしれないが、ライスケールが測れないので目安にしかならなそう）

俺もチームに決断を促すのを理想とはしているが、実際は時間がかかりすぎるので誘導尋問や具体的な細かいアドバイスをしてしまうことが多い。

スクラムマスターの役割について

アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？

• 「よりも」であって、「の代わりに」ではないので、プロセス要らないよとは言ってないよね
• 個人との対話を重視し、効果を高めるためには、プロセスを守る（あるいは守った結果、破る決断をする）ことも必要。
• 対話だけじゃプロダクト作れませんから

自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？

• プロダクトのリリースとプロセスの改善を継続的に繰り返せていること（定量的には、期間と頻度で評価する）
  • ただしこれは、アジャイルがうまく行っているだけで、プロダクトがうまく行っていることは意味しない
  • プロダクトがうまく行っていかどうかは、KGI/KPIの達成状況で判断する
• ↑の状態をチームが維持できているなら、うまく行っていると言える
• かつ、プロダクトがうまく行っていれば言うことなし

追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？

• スクラムチームの中に、普遍的に追跡しないといけないメトリクスはないと考えている。
  • チーム内のメトリクスは、追跡し始めると常に粉飾のリスクにさらされる　ってのが持論。
• 追跡すべきものを上げるとすれば、　DL数、離脱率、収益など、チームの外にある（粉飾できない）指標
  • これらを改善するために、一時期にチーム内のメトリクスを取るのはアリ。
  • ただ、状況によるので「これ」とは定められない

あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？

• 知らんがな(´・ω・｀)
• これだけの情報であれこれ言うやつを俺は信用しない。
• といいつつ自分がチームと向き合うとしたら、以下の観点からアプローチすると思う。
  • コミットメントが過剰になっていないか
  • バックログアイテムがINVESTを意識して切れているか

製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？

• 参加してよい。むしろ積極的にするべき。
• プロダクトがなぜ必要で、何を目指しているのかを理解し、オーナシップを得るために、議論にも積極的に参加する。

設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？

優先順位の決定に必要な情報収集や検討、ステークホルダーとの調整や議論をプロダクトオーナ以外のロールも支援する

どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？

• ステークホルダーとの関係を可視化し、誰がステークホルダーなのかを明確にする
• それぞれのステークホルダーと、対面、あるいはオンラインでリアルタイムに会話できる環境を用意する

どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？

• 短いフィードバックサイクルで反応することで、俊敏な動きの価値を背中で示す（良いねと思わせる）
• 示した価値を一緒に手に入れるために、協力を願い出る（うちも頑張ろう、とポジティブな動機づけをする）
• 複数部門が関連するときは全員を一箇所にまとめて話をする（他所を理由した逃げ道を塞いで、頑張ろうを維持する）

上級管理職にどのようにスクラムを紹介するか

• 改善のために問題をあぶり出す仕組みです
• 当たり前ですが、問題がたくさん出ます。（そのためのスクラムです）
• たくさん出るので覚悟して一つずつ改善していきましょう

あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？

• なんでそんなに抵抗するのか、何が不安で何が不満なのかを聞く
• 代替案があるなら教えてもらう。真摯にその案を理解し、不明点や懸念を伝え、どうすればいいか議論する
  • 代替案がないなら一緒に考える。
• 他のメンバーも巻き込んでどうするか話し合う。その結果、スクラムを採用するのか、しないのか、は 当事者に判断を委ねる。
  • 押し付けではなく、　自分たちの総意でスクラムに取り組まないとうまく行かない。

プロダクトバックログのグルーミングと見積りについて

プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？

• プロダクトオーナー1人でやって、チームもプロダクトもうまくいくなら問題ない。
• うまく行かないなら、スクラムチームを巻き込んで一緒に要求を理解し、PBIに落とし込むほうが良い。

チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？

• ユーザの反応
• 経営層、マネジメント層の期待、反応

誰がユーザーストーリーを書くとよいか？

• 誰でもいいけど、ユーザに近しい立場、あるいはユーザをよく理解した人のほうが良い
• （以降、ユーザストーリー＝PBIという前提で回答する）

よいユーザーストーリーとはどんなものか？どんな構造か？

• 「なぜ」がわかること
• INVESTを意識してかけていること（100%従う必要はない）

「Readyの定義」には何が含まれているべきか？

• 完了条件が明確であること
• それ以外はそのチームの文化次第

ユーザーストーリーを時間で見積もらないのはなぜか？

• スクラムに馴染んでいないの人たちの誤解を招くから
• どうせ時間で見積もっても理想時間と現実時間は乖離して無駄なので、ptに丸めることで不確実性を示す。

プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？

• 優先順位に従ってキャパシティの範囲内で順番にやるしか無いんじゃないですか。
• ただし時間経過でアイデアの価値は増減するので、元の200個全部やることは経験上ありえないと思う。（いずれ、別の100個が生まれる）

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？

• プランニング開始前に、ストーリーがReadyかつ、優先順位順に並んでいる状態を用意する
• その状態にないと誰がどう困るかをチームに考えさせ、必要性を認識させる
• その状態を作るために、POはじめとするスクラムチームに行動を促す

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？

• プロダクトのKGI/KPIへの貢献度合い
• 受け入れがたい「メトリクス」は思いつかないが、　〜〜長が言ったから　とか、　〜〜のルールがあるから　とか、　〜〜もやってるから　みたいなのは避けたい。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？

• コミットメントの権限を侵犯しない＝チームのキャパシティを超えない　と解釈すると・・・
• チケットとキャパシティの見積もりはチームが自ら行うよう促す
• POとチームがスコープを交渉する段階では、両者が「キャパシティ内での最大価値」を目指すよう意識づけする
• 「出来ない宣言」もチームの責任だとスクラムチームに理解させる

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？

• そんなんチームの状況によりけりじゃん(´・ω・｀)
• 大体2割ぐらいが目安だと思っているが、技術的負債を返すことに集中するスプリントや、まとまった時間を取って新しい技術を検証するスプリントを作るのもアリだと思う。
• 個人的には、時間で割合を定めるよりは、改善や調査のチケットもバックログに同列にならべて、チームがPOにその価値をアピールし、優先順位設定するやり方が好み

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？

• なんでそうしたいのかを聞く
• チームにもどういうやり方が嬉しいか、なぜそう思うか、意見を求める
• それぞれのやり方のメリデメを話し合う
  • チームに知識が足りていないなら、「なぜスクラムがPOのやり方をアンチパターンとしているのか」もレクチャーする
• そのうえで、スクラムチームとしてどうしたいかを改めて問う

チームメンバーによるタスクのつまみ食いをどのように扱うか？

• つまみぐい = やりたい作業だけやってDoneまで持っていかないこと　と解釈。
• そして、チームに以下のような悪影響を与えていると仮定。
  • WIPが増えて状況把握が難しくなる
  • 着手したけどゴールできないチケットが増える
• 「つまみぐい」がチームに悪影響を与えているようなら、その「悪影響」をチームがどう捉えているか問いかける
• 悪影響の原因を考えさえせ、チームとしてどうすべきかを問う
  • 「つまみぐい」に意識が向かないようならWIPの考え方などを紹介する

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？

• 「来週じゃ駄目なんすか？なんで？」
• 「今からねじ込むと計画からやり直しで当初のゴールが達成できなくなりますけど、昨日までの議論をひっくり返してでもやりたいことなんですね？」
• 「それら踏まえてもPOとしてやるべきと判断する内容なら、チームと相談してみてください」
• チームには　「命令じゃなく相談だから、　できる・できないの軸と　やるべき・やるべきでないの軸、両方で議論してね」と伝える

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？

• そのメンバーに　何が無駄なのか　プランニングに出ないことでチームにどんな良い影響を与えられるのかを聞き、　チームに提案してもらう
• 他のメンバーに　その提案に対する意見を求める
• スクラムチームに知識が足りていないなら、　スクラムが全員参加を求めている理由をレクチャーする
• あとは　スクラムチームで最良のやり方を選んでもらえばOK

スタンドアップやデイリースクラムについて

チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？

• No　各チームに合ったやり方を採用すれば良い
• とはいえ、スクラムが推奨している理由はインプットするし、スタンドアップじゃないやり方が問題を生んでいるなら、その問題を指摘する
  • ただし、スタンドアップを薦めることはしない。選択肢を提示するだけ。

なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？

• 個人的には待つことにメリットを感じないので、とっととチームに助けを求めてほしい
• が、それを命令するのも嫌なので、そういうタイプには「今すぐに声を上げるのは嫌？」みたいな問いかけに止めたい
• あとは、イベントに頼らず、困ってないメンバーが困ってるメンバーを見つけられる文化を作りたいよね

スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？

• あえてその人の進め方に不都合な発言をしてみる（報告セッションの空気を壊す）
• スタンドアップをリードする人が固定化しているなら、それでいいんだっけ？　とチームに問いかける

スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？

• プランニングのときと同じ。やるならチームに提案してもらい、チームで決断してもらう。
• 決断を無視して遅刻してくる人についても同じく　「違反するならその前に提案して堂々とやろうーぜ」

スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？

• 変える必要あるの？
• チームが出てほしいと思うステークホルダーがいるなら、その人を呼び込む動きをするかもしれない
• ただし、本当にスタンドアップに出てもらうのが最良の解決策なのか、は注意して問いかける必要がある

分散チーム間のスタンドアップをどのように進めるか？

• 顔が見えて声が聞こえるやり方にしたい

スクラムチーム用の物理カンバンボードをいま書いてください

略

ふりかえりについて

だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？

• チームに関わる人で意見がある人はだれでも歓迎
• プロダクトオーナーについては、　してよい　じゃなく　するべき　（本来は。。。ね）

チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？

• 確認するのが望ましい。確認の指標は
  • 全員が気兼ねなく発言できているか（黙っている人がいないか）
  • 問題提起と改善アクションの立案が出来ているか

過去に使ったふりかえりのフォーマットはどんなものか？

• KPT
• YWT
• FunDoneLearn
• 闇鍋
• モチベ曲線

どうやってマンネリを防いでいるか？

• たまに違う取り組みをすることを提案する（興味本位でのってくれるようなものを）

チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？

• 行動できない　という問題にメスを入れさせる　（理由を深堀りさせる）
• ありがちな理由は以下
  • 具体性がなくて何していいかわからない
  • 数が多すぎてどれからやればいいかわからない
  • 決めて満足して翌週には忘れている
• このへんの理由を潰すアクションを1つ、必ずやることとして決めてもらう
  • 次Sprintには毎日「やってる？できそう？」を問いかける

どうやってアクションアイテムのフォローアップを薦めるか？

都度「やってる？」「できそう？」「困ってない？」を聞く
そのうち、聞かれなくてもチーム内で質問できるようになってくれるはず。。。