「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答えてみた
@ryuzeeさんの スクラムマスターを雇うときに聞いてみるとよい38個の質問 に答えてみました。
他の方がブログで回答されているの読む前に、まずは"いまの自分ならこう考える"を書き残しておきたかったので。
これを公開するのは正直なところなかなか勇気がいるのですが、アウトプットしないと何もフィードバックは得られないので公開してしまうことにしました。これが正解という回答はもちろん無いので「なるほどなー」とか「こんな考え方をしてしまうのね」とか思いながら読んでもらえると嬉しいです。
何も見ずに、頭の中から絞り出して38個 回答します。
---------(ここから)---------
スクラムマスターの役割について
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
プロセスを守らせるのは"よりよい対話"のため。
建設的な対話をするためには、現状に対する認識のギャップが少ないほうがいい。チームがスクラムのプロセスやワーキングアグリーメントを守ることで認識のギャップが減り、よりよい対話をできるようになるから。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
継続してユーザーに価値を届け、望む成果を得られ続けている状態。
継続して望む成果を得るためにはユーザーや市場の変化に追従していかないといけない。そんな中でも継続して成果を得られているってことは、アジャイルがうまくいっているんじゃないかな。
チーム自身がスクラムマスターの役割をできるor不要になってくれば、スクラムマスターとしての働きが成功していると思う。
チームは自分たちで学びより多くの価値を生み出せるようになっているけど、スクラムマスターからの支援は減っているという状態。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
・各スプリントのベロシティ：チームの成長,安定性を知るため。
・スプリントのバーンダウンチャート：進捗状況を可視化するため。
これぐらいは最低限で追跡するかな。
あとは場合によるけど、チームが定性的にしか会話できていないようなものは、現実を見て学べるようにメトリクス取りたくなる。
・ストーリーのリードタイム：長いということはストーリーが大きいorリソース効率になっているなど課題があるので。
・稼働時間：実際にどのくらい開発に時間使えてるのかの見える化。
とか。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
いまのチームの実力以上のことをコミットしてしまっているため。(スキル、割り込み、モチベーション...何なのかはわからないけど)
直接的には指摘しないで、メトリクスを共有した上でふりかえりの場を設けて、いまのチームの現実に向き合ってもらえるようにするかな。で、まずはチームの実力にあったコミットメントをできるようにする。
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
（ディスカバリープロセスってプロダクト作る前に市場調査したりとかするやつであっているのかな？）
参加してもいいと思う。そこに参加することでチームのアウトプットの質が良くなるはず。プロトタイプ作るでも、ユーザーヒアリングするでも、データの分析するでもなんでも手伝えばいいと思う。
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
プロダクトオーナーにはWHY,WHATに集中してもらえるようにするかな。
そのためには、プロダクトオーナーがHOWを意識しなくてもよくなるように開発チームを支援するし、WHY,WHATをうまく考えられるように他部署やステイクホルダーとのコミュニケーションを支援する。
あと、やっぱりプロダクトオーナーは決断力の消費が激しい役割なので、いちばん決断力を使うであろうプロダクトバックログの整理はファシリテートして支援するかな。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
スプリントレビューに必ず出席してもらうことで、スプリントごとにコミュニケーションができる場があることを保証する。
また、
・チーム：ステークホルダーに話しかけにくい。
・ステークホルダー：必要ならどんどん話しかけて欲しいと思っている。
みたいな場面があるので、話しかけてもいいんだよということをチームに認識してもらったり、必要ならディスカッションの場に呼んできたりして、チームとステークホルダーのコミュニケーションの垣根を低くする支援もするかな。
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
スクラムの用語を使わずに、あくまで開発の進め方やルールとして説明するかな。バックログだったら「やりたいことこリスト」みたいに相手も当事者意識を持ちやすい表現に置き換えて。そして、その進め方をすることでどんなメリットがあるのかを理解してもらう。
つまり気づいたらスクラムのプロセスになってたという感じにして巻き込んでいきたい。
上級管理職にどのようにスクラムを紹介するか
学習のダブルループを説明する。
スクラムを導入することで、プロダクトもチームも早く何度も経験から学ぶ機会を得て、常に変わり続けることができるようになる。みたいな感じで。あと、トヨタ生産方式にも通じるところがあるとか(笑
あなたはすでにステークホルダーにスクラムのトレーニングをしたとする。この考え方を適用しようとする初期フェーズのあと、スクラムの適用を続けることに同僚が激しく抵抗するような障害やハードルにぶつかったとする。このような状況においてどんな戦略を取るか？またどんな経験があるか？
スクラムのどの部分に抵抗を感じるのか（プロセス？役割？バックログ？）を教えてもらう。チームの合意が取れるなら、その抵抗を感じる部分を期限付き(１スプリントだけとか)で違うやり方に変えてみようと提案する。期限のあとに、ふりかえりをすることに合意をしてもらう。
...みたいな感じで、無理にスクラムを適用するというよりは、チームの合意を得たうえで変化することを試してみるかな。学習のダブルループが損なわれそうになったらちょっと説得するかもだけど。それで望む成果が得られるのであればいいと思う。
プロダクトバックログのグルーミングと見積りについて
プロダクトオーナーはステークホルダーの要求をプロダクトバックログ項目に落とし込んでその見積りをチームに求めることになる。その流れでよいか？
あれ。いいんじゃないかな。でも質問するということは不適切なのかな？
思うこととしては...
・ステークホルダーの要求がそのままプロダクトバックログになるのは嫌かも。プロダクトオーナーが取捨選択することを期待してる。
・バックログ項目に落とし込む前に、Tシャツサイズとかの粒度でチームに見積りを聞いてみてもいいんじゃないかな。判断変わって、プロダクトバックログに落とし込む作業が無駄になるかもしれないので。
・プロダクトバックログリストの上位になければ、チームはすぐに見積りをする必要はない。また、上位にあるのであればチームは求められなくても平均的に見積りや見積りできる状態にする活動をやっておくべき。
チームに最新情報やマーケット状況を伝えるためにプロダクトオーナーにどんな情報を要求するか？
KPIなどビジネスとして望む成果については常に共有しておいてもらう。
これが意識できていないとチームの視座が低くなってしまう。開発プロセスがうまく行ってもビジネスとしての成果ができいなければ意味がないので。
あとは、直近のスプリントの背景となった情報を共有してもらうかな。
プロダクトバックログアイテムの理解が進み、チームのアウトプットの質に良い影響を与えると思うので。
誰がユーザーストーリーを書くとよいか？
誰でも良い。
ユーザーのことを理解し、プロダクトを価値あるものにすることはチーム全員の責任なので。また、書かれている内容に対する質問責任は、書いた人以外にあると思う。
よいユーザーストーリーとはどんなものか？どんな構造か？
「誰にとってどんな価値のあるストーリーなのか」が明確に書かれていること。加えて「背景」や「ビジネス価値」が書かれていれば最高。
構造は代表的な「xxxとしてxxxできるので、その結果xxx。」でもいいけど、「WHO/WHAT/WHY」みたいに項目ごとに分けて書いているのが個人的には好き。
「Readyの定義」には何が含まれているべきか？
・受入条件が明確になっていること。
・スプリントレビューでのデモの手順がわかること。
・チームにとって適切なストーリーサイズになっていること。
・チームがコントロールできないとわかっている外的要素が無いこと。
・チームが見積り可能なこと。
...まだまだありそうだけど、パッと思いついたのはこれぐらい。
ユーザーストーリーを時間で見積もらないのはなぜか？
ストーリーの相対的な比較ができれば十分なため。
プロダクトオーナーはユーザーストーリーの見積りを参考にして、リリースプランニングやプロダクトバックログアイテムの判断を行うが、これには必ずしも時間での見積りは必要なく、何らかの相対的な見積りがあれば十分。
また、時間で見積ることによる負の影響も大きい。
・時間での見積りはそのままコミットメントになってしまいがち。
・（絶対指標なので）見積りのアップデートに労力がかかる。
その結果として見積りを当てようという力が働いてしまい、詳細がないと見積もれないor見積りに過大な時間をかけてしまう。たぶん当たらないのに。
プロダクトオーナーはあとになってから取り組むようないろんな種類のアイデアを追加してくる。結果的にいろんなタイミングで取り組む200個のチケットができたとする。それに対してどのように取り組むか？スクラムチームは200個のチケットに取り組めるか？
フォーカスするチケットを決めて、残りは(いまは)無視する。
具体的には、ユーザーストーリーマッピングなどを用いて、次のリリースで本当にフォーカスすべきチケットを明確にする。そこまでやればまずは最低限の価値を持ったリリースができるので。
残ったアイデアについては、フォーカスすべきチケットが完了してから考えることにする。そのときにはプロダクトを取り巻く状況も変化しているので、いま考える時間がもったいない。
JIRAならバージョンとか付けてフィルタリングるかなー。
スプリントプランニングについて
チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか？
ダブルループ学習が機能するように支援することで、自然と価値のあるストーリーに取り組めるのではないかと。
外側のループであれば
・スプリントレビューのフィードバックを反映できているか。
・最新の情報がチームに共有されているか。
・事実に基づいた会話ができているか。
内側のループであれば
・見積りをアップデートできているか。
・開発チームの学びや気づきをプロダクトオーナーと共有できているか。
ユーザーストーリーの価値をどんなメトリクスに基いて判断するか？どんなメトリクスは受け入れがたいものか？
最終的には売上やKPIなどのビジネス価値に影響を与える指標で判断されていればいいかな。影響の与え方はいろいろあると思うけど、具体的にはこんな数字で説明してくれると納得しやすい。
・契約率/解約率
・タイミング（機会損失）
・プロモーション効果
・障害率
・運用コスト
・ユーザーからの要望数
受け入れがたいものとしては...
・見積り（すぐできるからやりましょう系）
・個人的な緊急度（部分最適系）
・評価目標（やるって決めたので系）
チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか？
・チーム内の情報の非対称性を埋める
・事実に基づいて会話をする
の2点に気をつけてファシリテーションをするかな。
チーム内で同じ情報を持ち、事実に基づいて会話ができているのであれば、ユーザーストーリーの選択で大外しをすることは無いと思う。また結果的に外してしまったとしても、チームの判断をふりかえることができるので。
どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか？
3割...くらいかな。状況によるのでなんともいえない。
ただ、リファクタリングやバグ修正に適切な時間を投資できていなければ、結果的に障害対応などでユーザーストーリーに使える時間が減ってしまう。もしチームがスプリントを安定して回すことができているのであれば、それがそのチームにとっての適切な時間なんじゃないかな。
チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか？
まず止める。
プロダクトオーナーが開発経験豊富な場合になりがちだけど、開発チーム自身の責任感や学びの機会を奪ってしまうので、どうやって開発を行うかは開発チーム自身で悩んで決めて実行させて欲しい。と伝える。
ただ、よい進め方の良いアイデアがあるのであれば、あくまで提案としてチームに言ってもらうのはいいと思ってる。それを受け入れるかどうかはチームの自由と責任。プロダクトオーナーからのアイデアを採用するにしても、チームが責任を持って採用しているかは気をつけて観察するかな。
チームメンバーによるタスクのつまみ食いをどのように扱うか？
スプリントプランニングでの「つまみ食い」ってなんだろ。
プランニング中にキーボード叩いて、ちょっと調べ始めたりするやつかな？
あるあるだけど、スプリントプランニング中はやめてもらう。
プランニング中にチーム内での情報の非対称性が高まっていくのでよくない。つまみ食いしている人しか知らない情報ができるし、つまみ食いしている人は他の人の発言をちゃんと聞けていないので。
気になることがあるのであれば付箋で書き残しておいて、途中で30分くらい調べる時間をまとめて作る。調べた結果を共有してプランニング再開。みたいな扱い方はどうかな。
ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか？
それはReadyでは無い。止める。
Readyの定義をチームが再度確認するように促す。
とはいっても突っぱねるだけでは無責任なので、
・価値がある状態でユーザーストーリーを分割できないか？
・他のユーザーストーリーで同じビジネス価値を出せないか？
など、前向きなプランニングができるようにファシリテーションをするかな。
スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか？
チームで合意をとったうえで、期間限定で参加をやめてみてもらう。
...かなぁ。無理に説得しても「参加したくないと言ったらスクラムマスターに説得される」という経験しか残らないので。
その後ふりかえる。本人だけでなく、他のチームメンバーとしてもどうだったかを共有する。その結果、本人は困らなかったけどチームとして困ったのであれば課題が明確になるので。
もし誰も困らなかったのであれば、いまのチームとしてはそれで良いんじゃないかな...スクラムマスターとしてはその状況は要注意なので気が抜けないけど。いいのかな。
スタンドアップやデイリースクラムについて
チームのサイズや経験度合いに関わらず全部のチームにスタンドアップを薦めるか？
必ずしもスタンドアップでなくてもいいと思っている。
・会話に集中できる
・全員が同じものを見て会話ができる（カンバンやメトリクス）
・タイムボックスを守れる
が満たせるのであれば検査と適応の目的は果たせるので。
そもそもリモートでのスクラムチームなどスタンドアップできないチームもあるだろうし。
ただし個人的には、以下の理由でデイリースクラムの効果をより引き出せると考えているので、できればスタンドアップ推奨派。
・非言語のコミュニケーションが取れる（疲れてるなーとか）
・カンバンやメトリクスにアクセスが容易（立たなくていい）
・業務とのメリハリをつけられる（あるいみルーティン）
・スタンドアップだと疲れるのでダラダラ話しにくい
なにか困っていることの助けが必要なとき次のスタンドアップまで待つことを期待するか？
困っているならそのときにコミュニケーションをとって欲しい。
（デイリースクラムはチーム全体でスプリントゴールに向けた検査と適用をする場であって、個別のお悩み相談会をする場ではないので...）
スタンドアップをリードして単なるメンバーに対する報告セッションにしてしまうような人をどのように扱うか？
デイリースクラムの目的や期待を伝えるかな。
そういった場をリードしてくれているのは嬉しいことなので。
ただいつも同じ人がリードすると、無意識のうちに報告セッションになりがちだと思う。その人がいいとか悪いとかではなく。
進行役を持ち回りにしたり、スクラムマスターがいつもと違う進め方をリードしたりして、マンネリ化形骸化しないようにする工夫が大切かな。
スタンドアップが無駄だと思っていて遅刻して来たり協力的でなかったりもしくは出席すらしないような人をどのように扱うか？
・進行役を持ち回りにして、その人が無駄だと思わないデイリースクラムをやってみてもらう。
・その人が参加してくれないという行動から起こっている問題あるのであれば「チームの困りごと」に変換してしまう。
難しいなぁ。単純にルールを振りかざすのは本質的な問題の解決にはならないので避けたいんだよなぁ。
スクラムチームのスタンドアップにステークホルダーは誰も参加していない。この状況をどのように変えるか？
デイリースクラムは開発チームのイベントなので、ステークホルダーが参加していないことは問題無いんじゃないかな？
必要あればステークホルダーを呼びにいくとか、ちゃんとコミュニケーションが取れていればいいと思う。
分散チーム間のスタンドアップをどのように進めるか？
「デイリースクラムを見学してもらう」っていうのはやってみたことがある。見学者から重要な連絡や質問をする時間も確保してた。Slackなどオンラインのコミュニケーションでは把握できない行間や空気感を知ることができると評判だった。
スクラムチーム用の物理カンバンボードをいま書いてください
スプリントバックログのカンバンだと仮定して、
・レーンは InBox,InProgress,Done の３つ。
・InProgressは意図的に狭くしておく。(物理的なWIP制限)
・行はユーザーストーリーごとに区切る。
・右端に「わかったこと」スペースを作る。(ふりかえりの材料になる)
・色とかアイコンで視覚的にわかりやすくする。
緊急レーンとかは必要性が出てきたらかな。
あまり最初から多機能にはしないように気をつけている。
ふりかえりについて
だれがふりかえりに参加してよいか？チームだけか？プロダクトオーナーも参加してよいか？
プロダクトオーナーも参加すべき。
次のスプリントをより良くするためには、スクラムチーム全員でふりかえりをすべき。スプリント計画やバックログアイテムの書き方などプロダクトオーナーがオーナーシップを持つ要素もその対象になるので。
ただし、プロダクトオーナーの意見が強くなりすぎていたらファシリテーションに入るかな。
チームが健全な状態かをふりかえりの中で確認するか？それとも不要か？もし必要だとするとどうやって確認するか？
ふりかえりの前段として、チームのメトリクスをみんなで確認することはやるべきだと思う。同じ認識を持った上でふりかえりをするほうがより効果的なので。
そのためには、そもそも"チームが健全な状態"ってなんなの？って会話をちゃんとして、自分たちのメトリクスを決めておかないといけない。
過去には以下のようなメトリクスをスプリントごとに収集して、時系列で表にまとめてそれを埋めてからふりかえりを開始するようにしていた。
・チケットのリードタイム
・稼働時間の実績
・不具合の修正数
・テストカバレッジ
過去に使ったふりかえりのフォーマットはどんなものか？
・KPT
・YWT
・タイムライン
・Fun/Done/Learn
・Happiness door
あれ意外と少ない...
どうやってマンネリを防いでいるか？
・場所を変える
・チェックイン時のアイスブレイク（一言チェックインとか）
・チーム外の人に見学してもらう
・2組に分かれてふりかえり,お互いに共有する
・進行役を交代する
とにかくふりかえりという"作業"にならないようには気をつけてる。
チームはいつも妥当なアクションアイテムを選んではいるものの、実際に行動できていない。この悪しき習慣をどう扱うか？
・自信をもって実行できるものを１つだけ選んでもらう
・選ぶときに具体的なアクションまで決めてしまう。
・アクションアイテムをスプリントバックログリストに含める
この3点をやれば、ほとんど実行できるようになるかな。
まずは小さな１歩でもいいので、チームが自分たち自身にした約束を守ること。自分たち自身への信頼貯金を貯めることが大切だと思う。
どうやってアクションアイテムのフォローアップを薦めるか？
上の回答にも書いたとおり、アクションアイテムをスプリントバックログアイテムに含めることで解決できるかな。
---------(ここまで)---------
タフな質問に38個も答えるのはとても大変でしたが、文章にする過程で過去の出来事をふりかえり頭の中を整理できたので有意義な半日(!)でした。回答に書いたことを実際には行動に移せてないな、と苦笑いしながら回答したりも。
ともかくこれで他の人の回答を読める。嬉しい。
おしまい！
この記事が気に入ったらサポートをしてみませんか？