↑の記事を読んでいて、自分も自分なりの考えを書いておきたいと思ったので、今回は、「スクラムマスターを雇う時に聞いてみるとよい38個の質問」の「スクラムマスターの役割について」に関する質問に答えてみます。
アジャイルマニフェストでは「プロセスやツールよりも個人と対話を」といっている。プロセスを守らせるスクラムマスターは、それとは反対のことをしているのではないか？
アジャイルマニフェストで宣言していることを守るため、プロセスはスクラムチームに守らせるべきである。このプロセスを守らせないと、アジャイルマニフェストが目指している状態が実現できなくなってしまうかもしれない。例えば、各個人がプロセスに対して独自の意見で好きなように活動してしまい、個人と対話をすることが困難になる恐れがある。
自分の組織でアジャイルがうまくいっていることを示す兆候は何か？また自分の働きが成功している兆候は何か？
開発チームは問題点を自分たちで見つけ、改善策を考え、実行している状態であり、スクラムチーム全員がプロダクトの現状と将来について意見を出して議論している状態であること。
追跡しないといけないメトリクスはあるか？もしそうだとしたら何の目的でどのメトリクスを追跡するか？
スクラムには追跡しないといけないメトリクスは定義されていない。ただ、スクラムチームが良い状態になっているか、各役割がスクラムで定義されたそれぞれの責任を果たしているか、を評価するためにメトリクスを見つける必要がある。プロダクトオーナーであれば、プロダクトのRoIになる指標を、開発チームであれば生産性と呼ばれる指標を追跡する。これらの指標がどういったものになるかは、業務内容やプロダクトのドメインによって変わるが、その文脈に適したメトリクスを見つけることもスクラムマスターの役割の1つである。
あなたのチームのパフォーマンスは常にコミットメントを達成できておらずベロシティも安定していない。考えられる理由はなにか？そして問題をどのように指摘するか？
PBIやタスクの粒度が大きく、オーバーコミットしている場合は、
タスクベースでPBIが切られているのならば、ユーザストーリマッピングなどを作成して、ユーザに提供する機能単位でPBIを切るようにする
保守, 運用, バグ修正などスプリント中の差し込み作業が多く開発に当てるリソースがプランニングの時に想定していたものよりも少なくなっている場合
開発以外の時間の概算を算出して、スプリント中の非開発作業の割合を出してみる
自動化できるものがないかレトロスペクティブで話し合ってもらう
コードの品質が低い(テストがない, コードが読みづらい, コメントがない)ことによって開発業務に支障がでている場合
問題を抱えたままチームに共有していないメンバーが生まれている場合
製品のディスカバリープロセスにスクラムチームは参加してよいか？その場合はどのようにするか？
参加した方がよい。プロダクトオーナーはプロダクトのRoIを検討する上で製品が解決する課題や、求められているニーズを把握する必要がある。また、開発チームはプロダクトを開発するだけではなく、プロダクトバックログの優先順位に対して意見を表明したり、自分たちで優先順位を決めることができるのでプロダクトについて知っておく必要がある。(ただしプロダクトバックログに対する責任はプロダクトオーナーのもの)
設計上プロダクトオーナーの役割はボトルネックになる。価値が最大になるよう、どのようにプロダクトオーナーをサポートするか？
プロダクトオーナーがどういった問題を抱えているかをヒアリングを通して把握する。 プロダクトが抱える課題や背景が不明なのであれば、ユーザヒアリングやユーザストーリーマッピングなどを行い判断材料を集める。 プロダクトバックログアイテムの切り方がわからないのであれば、そのチームのバックログアイテムとして適切な切り方を数スプリント回してみて検証してみてはどうかと助言する。
どのようにスクラムチームがしかるべきステークホルダーにアクセスできることを保証するか？
スプリントレビューへの参加理由をステークホルダーに説明し、必ず参加してもらうよう伝える
どのように複数の異なる部門にまたがってアジャイルのマインドセットを広げるか？ITじゃないステークホルダーをコーチするのにどんな戦略をとるか？
上級管理職にどのようにスクラムを紹介するか
問題が解決できるかどうかはチームの能力次第
検査、適応、透明性が柱になっており、ごまかすことはできない
現実を可視化できるので、優先順位や本当に注力すべきポイントについて議論することができる
