2019年度末「スクラムマスターを雇う時に聞いてみるとよい38個の質問」に答える

以前もこの質問には答えたことあるのですが、年度末なので自分のスクラムに対する考えのまとめと振り返りを兼ねてやってみました。

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

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

スクラムのプロセスやツールは個人間の対話を促すためのものなので、スクラムマスターとしてそのプロセスを正しく運用することはチーム内のコミュニケーション活性化につながる。もしそのプロセスでコミュニケーションが上手くいかないなら、プロセスやツールを見直しカイゼンを図る。

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

チームが楽しんでいること。チーム内のコミュニケーションが活発になっていること。プロダクトオーナーやステークホルダーがチームの提供する価値に対して満足していること。

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

ベロシティを今後のPBL消化の予測のために追跡する。あとはバーンダウンチャートを書いて日々の作業でチームの問題が生じていないかを確認する。障害リストに載せられた障害について情報が更新されているかを確認する。

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

チームを見てないとわからない。スプリントバックログにタスク詰め込みすぎ？例えばタスクの見積もりを時間でやってる場合、勤務時間フル稼働で想定しているとか。休憩無く作業できるの？って聞く。

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

もちろん参加して良い！UXデザイン、デザイン思考、リーンスタートアップなどを適宜使いプロダクトのより良い形を模索する。ディスカバリープロセスを経ることでインセプションデッキに頼らずともチーム内でユーザー像やミッションが明確になる効果もある。

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

ボトルネックの理由を考え、PO側で足りてないスキルを元に、POチームに加えるべきメンバーについてアドバイスする（例えば、技術的な話ができる人）。あるいは、プロトタイプの作成などであればPOに教えてできるようになってもらう。

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

ベストなのはスプリントを始める前に顧客とステークホルダーへのアクセスルートを合意しておく。途中から必要になったり、新たなステークホルダーが出てきた場合はその都度ルートを合意する。どちらの場合でもこのアクセスルートを持つことの重要性をちゃんと説明する。

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

John Kotter先生の「組織変革のための8ステップ」をベースに動く。なのでまずは危機感をもたせる。スクラムだろうとウォーターフォールだろうとアジリティは必要なんだと説く。

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

VUCAな現代でプロダクトを正しく作る方法。チームが楽しく成長できる方法。ここらへんを今までの経験を交え説明します。

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

その同僚に理由を聞く。理由を元に1週間スプリントを2ヶ月ぐらいは試してもらう。スクラムでそれだけやれば何か掴んでくれると思うが、それでダメならチームを去ってもらう。

プロダクトバックログのリファインメントと見積りについて

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

ステークホルダーがユーザーを含んでいるなら、流れとしては大体OK。ステークホルダーの要求をもとにインサイトまで考えられるとなおよい。要求＝ベストなプロダクトではないこともあるので。

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

ユーザーのプロダクト利用状況やフィードバックをチームに反映してあげる。実際のユーザーに届けられた価値こそがプロダクトの価値で、プロダクトオーナーの満足度とか社内の評価とかは二次的な価値です。

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

基本はプロダクトオーナー。だが、チーム内の課題やDev特有の課題をストーリーに起こしてPBIに記入することは個人的にOKだと思ってます。それを

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

誰が何をなぜしたいかが解るようになっているユーザーストーリー。

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

プロダクトの性質によるけど、共通しているのはPBIが完了の定義も含めてもれなく正しく書かれていてDevが迷わず手を動かせる状態になっていること。フェーズによってはイメージとかもDevと一緒に決めていいと思う。

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

でかいタスクを見積もるのは人間には無理。でも相対的に見積もるスキルは結構すぐれてる。フィボナッチ数がよく使われるのは見積もりがでかいときに6か7かでウダウダ時間を使わないため。

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

チケットがPBIのことを意味しているなら、チームが解散しなければ取り組めるんじゃないでしょうか。ただPBLに載ってる以上、優先順位はつけられるし、チームが1スプリントに取り組めるPBIには限りがあるので、200個載せることに意味はあまりないよ、とPOに伝える。あるいは、スクラムチームを増やすことを考える。

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

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

リファインメントを行い、POにPBLの管理を促し、スプリントプランニングをスムーズに実施できるよう尽力する。

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

OKR的にちゃんと自分たちのビジョン・ミッション・バリューと結びつくメトリクスになってるなら良い。受け入れがたいのは、例えばPVなど、その数値そのものが価値にならないKPIなど。

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

プランニングやリファインメントの際に、インセプションデッキやステークホルダーのことを考えながらチームが作業できるようにする。

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

チームの決めでよいと思いますが、スプリントの10%はあると良いなぁと思います。目安として、2週間スプリントなら1日分、1週間スプリントなら半日。

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

クリティカルなタスクがあって特定の誰かしか出来ないみたいな話であれば要相談。それはプロダクトオーナーの役割ではないこと、それをやることでメンバーの自主性が奪われてしまうことを説明する。

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

必要に応じての話ならまぁ良いけど、スイッチングコストを理解していないならそれについてチームに説明してみる。時間が簡単なアクティビティを通して実感してもらう。

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

状況によるが、可能であればチームはそれにコミットできないことを合意する。マイルストーン的な役割がありやらねばならない話であれば、やるしかないが、また同じ問題が出ないよう何をすべきかを話し合う。

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

なぜ、スプリントプランニングに参加したがらないのかを確認する。その上でスプリントプランニングの目的を再確認し合う。

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

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

よっぽど経験があり、普段のコミュニケーションやアラートを怠らないチームでない限りデイリースクラムはやるべき。少なくとも自分はそこに至ってるチームでできたことはないので、デイリースタンドアップは必ずやってる。

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

そうならないことを期待するが、そうなってしまった時（概してなりえる）のためにデイリースタンドアップがあると思ってます。

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

報告でなくて、毎日の検査と適応の場だよって伝える。1日レベルで何かチームに問題が起きていないか検査して、それに対してどうチームが動くべきかのキッカケを与えることこそがデイリースタンドアップの目的。

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

なぜ無駄だと思うのかを聞く。いらない理由は？逆にいてくれたほうが良かったね、みたいなことはチーム内で往々にしてあるのでそれを伝える。

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

デイリースタンドアップは主に開発チームのものなので、ステークホルダーは参加しても良いけど過度な口出しは無用です。

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

3つ目の質問などで上がってきたゴール達成の課題が他チームとの連携を必要とするものであれば、連携する。あるいは、4つ目の質問として「他チームとの連携に置いて不安なことはあるか」を加える。

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

以下をいれたボードを作ります。
・TODO/WIP(細め)/DONE
・レトロスペクティブのアクション
・チームのワーキングアグリーメント
・バーンダウンチャート
・インピディメントリスト

ふりかえりについて

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

プロダクトオーナー視点での振り返りも当然必要なので、PO,SM,Dev全員が揃ってやることが理想。ステークホルダーは参加してもよいが、チームの心理的安全性を害さないかに要注意。害される場合、チームの本当の悩みをさらけだせなくなる可能性があるので良くない。

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

日頃の状況を見て、確認する。というか、健全な状態なら正しく振り返りができるし、明らかに取り上げるべき問題がチームの振り返りででてきていないならそれはスクラムマスターとして拾い上げるか、なぜ出てこなかったかに注視する。

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

・KPT
・YWT
・闇鍋
・Good, Bad, Tech & People Quadrant

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

レトロスペクティブの手法を色々紹介。アジャイルについての勉強会を開いたりしている。

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

アクションアイテムを選びすぎてるなら数を絞る。行動できない理由を聞く。忘れてしまうだけならスプリントバックログにチケットとして載せたり、あるいはアクションを見える形にしてスプリントボードに貼ったり。

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

アクションアイテムの内容によってはスプリントボードに貼ってタスク化してしまう。それ以外は1週間スプリントならとりあえず次のレトロまで待って、実際にできたかどうかの確認をする。できていないものはなぜできていなかったかをチームで話し合ってもらって、それも込でレトロを進める。

***

以上で38の質問は終わりです。この質問自体もアップデートされるべきだな、と答えていて思いました。前回の回答をロストしてしまったので比べられないのがちょっと残念ですが……来年度末かどこかでまた答えて自分の答えの変遷を辿れたら楽しそうだなーと思ってます。

では来年度もよろしくお願いします。良きアジャイルライフを！