スクラムマスターを雇う時に聞いてみるとよい38個の質問
はじめに
楽しそうなので回答してみました。
自分の回答
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
型を守らせることで、「いつ」対話して「何を」得るのかをチーム・メンバに習得させるためと考える。 なので初めてスクラムに取り組むチームは最初からカスタマイズしようとせず、教科書通り全てのプラクティスを取り入れるべきだと考えている。標準とどうしても合わないものは後から見直しても十分間に合う。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
プロダクト開発・プロジェクトがステークホルダーの予想通り(予定通りではない)進捗していること。 スクラムマスターが扱う課題が技術・メンバなど内のものから、チーム・組織・プロダクトなど外に向かって変わってきていること。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
アジャイル開発・スクラム開発を取り入れて改善したかった事項をメトリクスにすれば良い。プロダクト・組織によって異なるので正解はない。 メトリクスはプロダクト・チームの状況を把握するきっかけとして使うべきで、値そのものを目標化しない方がよい。例えば生産性を上げるためベロシティを評価の指標としたらチームは見積もりの数字を大きくするだろうし、デプロイ回数に注目したら必要とされている顧客価値を提供できているかが後回しになるのではないかt。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
考えられる理由
- スケジュールが固定化しており、プロダクトオーナー・ステークホルダーがチームにバックログアイテムを与えすぎている。
- チームがスプリント期間中に全てのアイテムを完了できなくても良いと考えている。
- アイテムを完了させるための事前準備(アイテムのリファインメント、適切な分割)ができていない。
- 必要なスキルセットがチームに揃っていない。
対策
- スクラムマスターはデイリースタンドアップでアイテムが終わらない可能性を懸念として表明する。
- チームのふりかえりで議論の俎上にあげてもらう。
- 次のスプリントでは扱うアイテムを少なくし、完了させる状態が定常であることを認識させる。
- 準備・スキルの問題だと感じるときはリファインメントのやり方を見直す・技術習得の研修を計画するなどチームをサポートする対応を取る。
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
もちろん参加してよい。 リファインメントに顧客・スクラムチームを招き、直接議論させる。
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
バックログがメンテナンスされている状態を保てるようにサポートする。 上位にあるアイテムが適切に分割・見積もりされ、チームが着手できる状態になっているか、細かく詳細に入りすぎずプロダクトオーナーのマイクロマネジメントになっていないか、アイテムがステークホルダー・開発チームから上がっているフィードバックを考慮した上で妥当な優先順位で並んでいるかを確認する。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
スプリントを進めるにあたりステークホルダーへのアクセスが必要であればプロダクトオーナー・スクラムマスターに事前の断りを入れることなく直接コンタクトをとって進めてほしい。プロダクトオーナー・スクラムマスター・何らかの組織で決まった定例会議をボトルネックとしたくない。ただし、両者の話し合いで決まったことがあるのであればプロダクトオーナー・スクラムマスター・打ち合わせに参加していない人に対していつでも見えるようにして欲しい。
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
まずはうまくいく1 チームを作る、広げるのはそれから。 ITじゃないメンバを巻き込む場合はカンバンの導入から入る、その次は定期的な振り返りかな。
上級管理職にどのようにスクラムを紹介するか
「今回のプロジェクトは自社にとって初めてのことが多いので、事前に詳細な計画を立てるのではなく、少しずつ検証しながら方針修正していきます。XX週間(1〜4)ごとに動くものを用意するので、ステークホルダーのあなたにはぜひアドバイスをいただきたいです。このご時世、メンバーの生産性も上げていかないとやっていけないので、こまめに振り返りを行い改善点を直していくようにします・・・」みたいな。
あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
- 抵抗する人と話し合いの機会を持つ
- まずは1〜2週間やってみて、それから再度話しましょう
それでも改善が見られなく、他のメンバは順応し、チームの阻害要因になっていたらチームから外すことを検討する。
プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
その流れで良い。バックログアイテムの分割に悩むようであればスクラムマスターと一緒にチームが取り組みやすい単位になるよう分割を行う。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
顧客・ステークホルダーの生の声を伝えて欲しい、できればそのまま。
誰がユーザーストーリーを書くとよいか？
プロダクトに関わる誰が書いても良い。チームメンバ・スクラムマスター・プロダクトオーナー・ステークホルダーなど。
よいユーザーストーリーとはどんなものか？どんな構造か？
「何をやるか」だけが書いてある。「どうやるか」についての記載がない。 さらにやることによって、「誰にとって」、「どんな価値があるか」、さらに「どうすれば価値を提供できているかを確認できるか」が書いてあると良い。
「Readyの定義」には何が含まれているべきか？
「何をやるか」について、チームが作業工数を見積もられる情報が揃っていること。
ユーザーストーリーを時間で見積もらないのはなぜか？
見積もりは正確にできない。担当するチーム・メンバーによっても必要な時間が変わる。 時間で見積もるとその時間内に完了させることが外に対してのコミットメントになりやすい。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
チケットが何個あろうがチームがスプリントに取り組めるのは上位の数個に限定される。 200個のチケットで重要なものが上位にきており、リファインメントがされていて、開発スピードとそこから予測できる開発計画に対してプロダクトオーナー・ステークホルダーと合意がとれていれば問題はない。
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
プロダクトオーナーが上位に並べたアイテムについて、背景を質問する。
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
開発工数に対して提供できる価値が大きいものを選ぶ。 開発できそうな目処が付いているのであれば提供できる価値の大きさだけに基づいて並べることもある。 売り上げやユーザ数だけに着目すると技術負債の解消に着手しづらくなるため、チーム・プロダクトオーナー・ステークホルダーで数スプリント単位の大まかな方針を握っておきたい。
上位に持ってきたいアイテムがあれば、リファインメントの際などにプロダクトオーナーにコメントを伝える。最終的にどう並べるかはプロダクトオーナーに任せる。
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
ステークホルダー・プロダクトオーナー・メンバーと合意が取れていれば割合を気にすることなく費やして良いと考える。 とはいえ0にすると将来技術負債・スキル不足で苦しむことになるので毎スプリント10%ぐらいの時間は使うべきと考える。
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
スクラムマスターを通すように意見する。 バックログリファインメントなどプロダクトオーナーの責務に集中するよう何かプロダクト全体の課題になっていることの解決を依頼し、チーム内のやりくりは任せてもらうよう話をつける。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
バックログアイテムの「上から」順に「1つずつ」担当するよう伝える。
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
無理くり入れ込もうとしているならば、次のスプリントに回せないか話をする。もう少し時間が取れたらまた考えが変わるかもしれない。
どうしても今のスプリントに入れ込みたい場合、計画時に担当するアイテムを少なくして入れ込む余地を残しておく。ユーザーストーリーが確定し着手することになった場合も、担当する全アイテムがスプリントで完了するかをチームで判断し、終わらない場合はどれかを諦めてもらうようプロダクトオーナーと相談する。
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
なぜ時間の無駄だと考えるのかをチームメンバでスプリントの振り返りに話してもらう。 もし結論が「時間の無駄」だとなってしまった場合、その時のチームの課題を議題として放り込み、それでもスクラムのセレモニーが時間の無駄かを再度考えてもらう。
チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
勧める。 毎日、同じ時間に、短時間でチームの状況認識を揃えることに価値がある。
なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
期待しない。困っているときはすぐにアラートを上げて欲しい。
スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
司会は持ち回りにする。
メンバーからの報告はチーム目線の内容で話してもらう。
- チームのために昨日何をしたのか。
- チームのために今日何をするのか。
- チームにとって障害になりそうな事項は何か。
スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
- 叱る
- チームのメンバから外れてもらう。
スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
デイリースクラムはチームのためのセレモニーなのでステークホルダーがいなくても特に問題はない。
分散チーム間のスタンドアップをどのように進めるか？
分散チームの定義が1つのチームが複数拠点に離れていることを指しているのであれば…
- 拠点をまたいだチーム構成にならないよう分割を検討する。
- 拠点をまたいだチーム編成が避けられないのであればZoomなどのツールを使い、メンバの顔が遠隔地にあっても見える状態を作って実施する。
スクラムチーム用の物理カンバンボードをいま書いてください
| Plan | Do | Check | Done |
|---|---|---|---|
| □□□□ | ■ | ■■ | ■ |
| □□□□□ | ■■ | ■ | |
| □□□ |
- Plan : 未着手
- Do : 実施中
- Check : レビュー待ち
- Done : 完了
各タスクは数時間で終わる粒度まで分割する。 タスクは先に着手するものを右側に置く。
だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
誰が参加しても良い。プロダクトオーナーも参加して良い。 ただしマネージャーは参加するとメンバーが意見を萎縮してしまうかもしれないので、あとでスクラムマスターからふりかえりの概要報告を受けることで出たがったとしても納得してもらう。
チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
問題がきちんと吐き出されているか、なんとなく問題が先送りや見て見ぬ振りされていないかを確認する。
過去に使ったふりかえりのフォーマットはどんなものか？
KPT！
どうやってマンネリを防いでいるか？
- 自分たちが取り組んできた改善をまとめ、チーム外に紹介する。そこでのフィードバックをチームで検討する。
- リスクは高いが、大きい学びを期待できる「スプリント中の実験」を何か定める。
チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
改善項目であげる数を絞る。 毎日のデイリースクラムでリマインドする。 改善項目をバックログアイテムの一つとして取り扱う。
どうやってアクションアイテムのフォローアップを薦めるか？
毎日のデイリースクラムでリマインドする。 着手状況をチームに確認する。
