読者です 読者をやめる 読者になる 読者になる

aspec7's garage

エンジニア生活の中で学んだことの備忘録

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

f:id:aspec7:20160318095017j:plain

Ryuzeeさんが参考訳として紹介されていたスクラムマスターを雇う時に聞いてみるとよい38個の質問について、頭の整理も含めて解答してみました。
なかなかこういうこと聞かれることもないので、良い経験になりました。
もっと多くのことを経験したら、また解答してみて今回の解答と比較してみたいです。

それでは早速。


スクラムマスターを雇う時に聞いてみるとよい38個の質問

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

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

マニフェストでは、プロセスやツールを否定しているわけではない。


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

スクラムマスターの必要性が薄れた、あるいは不要だと感じた時。


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

大きく2点。

  • 顧客満足度
    チームが実際に顧客の声には常に耳を傾け、より満足を与えられるように考えられるようになることが大切。
  • チームの満足度。
    前向きな取り組みは、自律なくして成立させるのは難しい。チームが不安・不満に思うことに耳を傾け改善への働きを試みるのは、スクラムマスターの仕事の一つ。


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

理由はいくらでも想像できるが、それはチームの外から見た一つの目線に過ぎないので、本当の原因が何であるかを判断するにはチームに聞いてみるしかない。
聞いた内容と、スクラムマスターから見えていた点を総合的に見て、話し合い仮説と検証を繰り返すのみ。


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

参加した方が良い。
技術的な価値観点から、顧客側、業務側との価値観点と意見交換するといったDtoDやDDDのようなワークショップが良い。


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

一つはボトルネックになりやすい構造であることをスクラムチームで認識すること。
もう一つはプロダクトオーナーに一人で仕事をさせないようにすること。
チームやステークホルダーと議論や意見交換など行ってもらい、プロダクトオーナーの能力に合わせて本来やるべき仕事に専念できるように調整する。


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

基本はステークホルダーとチームのファーストコンタクトの場を設けて、その中でアクセスできる方法を決めてもらう。
ただ、ステークホルダーが滅多にアクセスできないような超多忙な場合は、それなりの権限を委託された比較的アクセスが容易な代表者を用意してもらうなどを検討してもらう。
(状況次第ではチームにエレベーターピッチ的に短時間で交渉できるようなスキルを身につけてもらう必要もあるかな)


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

まず最初に強要はしない。
開発側がスクラムフレームワークを使って、どのように仕事をするのかを理解してもらう。
そして、必要に応じて異なる部署にアジャイルのエッセンスを伝えたり、それに合わせたやり方を検討する。
とにかく、スクラムやアジャイルについて、まずは説明会など開き理解を得るところから始める。


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

(紹介する目的によるけども・・・)
プロダクト開発が難航しているしている状況と仮定すると、まず現状の問題点を説明し、一つの改善案としてスクラムを提案する。
(もちろんそれがスクラムで解決できそうであれば)


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

話す。納得いくまで話し合う。
お互いの考えや進め方、なぜ反対なのか。


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

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

優先度など何も考慮せずに行っているのであれば問題。
契約ゲームは避けたい。


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

リリースされたものであれば、その後の反応や成果について。
今後の計画に関することであれば、バックログの中身を知るための情報は常に透明化してもらう。


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

スクラムチームの中でなら、プロダクトオーナーとチームメンバー。
それ以外を含めるなら、ステークホルダーなども書けるのが望ましい。


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

プロダクトをストーリーとして語れるようなもの。
1つ1つのストーリーは、主語と目的、理由がハッキリできているもの。


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

チームが自力でスタートできるような要素全て。


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

作業時間はチームや状況により左右されるため、ストーリー自体の規模は表すには不適切。
ストーリーの粒度も大きいほどブレが大きくなることから、絶対値で測ることにあまり意味はない。


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

プロダクトオーナーが必要だと判断して追加されたもの自体何も問題はない。
200個のチケットを捌けるかは別の話。
なので、見積りして捌けないとわかればアイデアを削るのか、全て達成するための施策を投入するのかプロダクトオーナーが判断すれば良い。


スプリント計画について

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

チームが、作業のやりやすさだけで作業順を考えていないか様子を見る。
もしそういう状況であれば、なぜプロダクトバックログの順序を無視するのか聞く。
それがチームの判断であるようであれば、プロダクトオーナーと話し合いをしてもらう。


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

満足度など、顧客目線で計測されたわかりやすいもので判断。
見積り工数など、価値に繋がらないメトリクスは全て受け入れがたい。


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

プロダクトバックログの優先順について理解が足りていないのであれば、プロダクトオーナーに改めて説明してもらう。
チームが効率性を考えての優先度変更の話であれば、理由をプロダクトオーナーに話してもらい、スプリントのスコープを整理してもらう。


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

スプリントの20%程度(1週間スプリントで1日)。
期間が適切かどうかは、メンバー&プロダクトオーナーと要相談。


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

そうすることのメリットとデメリットについて尋ねる。
無意識であればチームに任せるよう促し、明確な理由があるようであれば、チームに対して説明してもらい合意を取ってもらう。


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

弊害がないうちは、放っておく。
より優先度の高いもので、undoneなど発生した場合は、つまみ食いの件も含めて議論の場を設ける。
(プロダクトオーナーも、議論の場にいると良さそう)


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

確定が伸びることや初日から計画も作業もできないことで、Undoneが発生した場合のリスクについて問う。


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

スプリントプランニングについての目的と役割について、メンバー内で認識のすり合わせをしてもらう場を設けてもらう。
その中で、なぜ無駄だと感じているのか、参加したくないと感じているのか話し合ってもらう。
もし理由が、そのような場で話しにくい内容であれば、別途他のメンバーのいないところで、理由を聞き改善に向けた話し合いを試みる。


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

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

薦める。


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

期待しない。
定例のタイミングを待たずに、リアルタイムで共有するよう促す。


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

特に何も。
(ただチームの雰囲気見て、その状況について満足しているかは聞くかな)


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

チームが結果を出せているなら気にしない。
ただ無駄だと思う理由について聞くことは最低限する。


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

特にスタンドアップに毎回出席の必要はないと思っている。
なので、参加がないことを特に問題視しない。
(できれば参加したいと考えているのに)参加を躊躇うネガティブな声が聞こえれば、ヒアリングして改善は心みたい。


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

1チーム内の分散で、物理的なロケーションの問題であればオンラインによるビデオチャットのようなものは検討する。
複数チームの分散であれば、基本的に各チームの代表者揃えて短時間となるように実施。


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

なるべくシンプルに。

  • ストーリーベース
ToDo InProgress Done
     
  • タスクベース
InProgress Done
   

ToDo列は、必要であれば設ける程度。
(基本的にはチームが自分たちで作ったToDoの溜まり場があるならそれを使うという方針。)
Doneの隣にUndone列作っておくのも良いかなぁ。


ふりかえりについて

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

必須:開発チーム
必須:スクラムマスター
任意(状況次第で必須):プロダクトオーナー
任意(必要に応じて):ステークホルダー


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

健全な状態かどうかは、振り返りの中だけで判断するのは難しい。
普段の状況から見て、健全だと感じれない部分があれば、それについて振り返りのテーマとして投げかけてみることはするかもしれない。


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

  • KPT
  • CRT(CRT)
  • 5Whys
  • System Thinking


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

防げてはいないけど、、発生したらメンバーと理由と原因について話し合い改善案を共に考える。
改善案のために、他のチームのメンバーで実施している内容など聞いて回ってアイデアは確保しておく。


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

(チームに対して)
1. まずは、なぜ行動できていないのかを聞く。 1. そして、なぜそのアクションアイテムを選んだのか聞く。 1. 行動の結果、うまくいった/うまくいかなかったことを想像させ、どういう変化があると思うのかを聞く。 1. 最後に、そのアクションをやるのかどうか聞く。


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

アクション後の検証を行ってもらう。
その際に、やっていないということであれば理由を聞く。
それに応じて、必要なフォローアップを薦める。



スクラムやってる人たちは色々な経験されてる方が多いので、著者の違う色々なスクラム本を読んでみることをお勧めします!