スクラム開発の初挑戦でスクラムチームを立ち上げていく中で、スクラムマスターとしてやってみたことや考えたことの主な3つをまとめてみた。もちろんスクラムマスターとしても初挑戦なので、実は間違っている内容や、他にもっとやるべきこと、やってみたけど将来的に失敗と判断することなどもあるかもしれない。その時は今後の投稿で学びとして改めてまとめ直すことにします。

バーンダウンチャートの更新

最初のスプリントはだいたいうまくいかないと言われているが案の定うまくいかないので、バーンダウンチャートを日々更新して状態を可視化する。開発チームはリズムに乗るまで大変なので日々の状態の可視化はスクラムマスターが頑張る。リズムに乗ってきたら開発チームにまかせても良いかもしれない。

バーンダウンチャートの作り方やそこから何を読み取るかは、@ryuzee さんの資料を参考にした。

slide.meguro.ryuzee.com

ひとまずすぐに取れそうな以下のメトリクスを追加して日々の状態を可視化し、仮説を立てながらチームの状態を分析して必要ならアクションを起こすようにする。スクラムマスターがあまりに事細かく状況を聞いたり、何でもかんでも口を出すと開発チームが疲弊してしまうので、気になるところを中心にポイントを絞ってアクションを起こしたり、気になるメトリクスをチーム内に共有して早めに対策できるようにする。

開発チームのメンバーの稼働時間
- そもそも開発に時間を取れているか
- メンバーがプロジェクト外の作業や会議などの割り込み作業に時間を取られていないか
- 想定通り稼働しているのにタスクが消化されていないならスキルや見積もり精度など別の課題がありそう
コミット件数
- 一定のチェックポイントを設定して作業が進んでいるかを把握する
- 稼働が取れているのにコミットが少ない場合は事前調査などで手が止まっている可能性がありそう
マージコミットの件数
- タスクが完了していくペースを把握する
- レビューの頻度と捉えることもできる（レビューがボトルネックになっていないか）
- 稼働が取れていてコミットもしているのにマージされていないならタスクの完了条件が曖昧なのかもしれない

イベントの進行

まずは必要なイベントを確実にこなしたいので率先してイベントを進行するか、誰かに任せる場合は明確にお願いして主導権を渡す。例えばスプリントレビューはPO主導で進めてもらいたいので事前にそのことを伝えておく。必要に応じてだと思うが、当面はPOも開発チームもイベントの中身の手順を覚えたり学ぶことが多いので、スクラムマスターがなるべく進行役を担当してイベントの中身の作業に集中させてあげたほうが良さそう。

スクラムチーム全体がイベントに慣れていないのでその場でいきなり「○○さん進めて下さい」は絶対にしない。事前にそのイベントで何をするか考えて取り組めば、たとえうまくいかなかった場合でもふりかえって次回スプリントで改善できる。

妨害リストを作る

スクラムで言われている妨害リストにいきなり取り組むのはやってみた感じではおそらくアンチパターン。ただ、妨害の排除はスクラムマスターに与えられた重要な役割の１つなのでリストを作ってチームで共有しておくこと自体は必要と感じている。また、はじめのうちは漠然とした不安も含めた課題がチームのあちこちで出て来るので、ウォーターフォール型開発で言うところの課題一覧を整理するような形でいったん気になる課題をスクラムマスターが集めてリストアップしておくのはそれなりに意味はありそう。スクラムチームに足りないもの、すぐに手を打ったほうが良いことの優先順位を決めて整理するのに役立つ。

もちろんプロダクトバックログやスプリントバックログを完了させていくことが最も大事なのでそれらを疎かにして妨害リストを管理するのは本末転倒。当面はスクラム開発のリズムを作ることを重視しつつ優先順位を考えて妨害排除に取り組み、やりすぎない、管理しすぎないほうが良さそう。スクラムマスターが妨害リストばっかり見ていると思われないようにする。スクラムチームのリズムができてきたら、メンバーにも積極的に妨害リストに追加してもらいチーム全体で妨害排除に取り組める雰囲気を作っていく。

将来的に目指すべき妨害リストの運用についてはRSGT2018の以下のスライドを参考にイメージしている。

speakerdeck.com

ふりかえりとの違いはチームの外に目を向けて前提を変えられることにある。

注意する点