アジャイル開発スクラム開発の初挑戦でスクラムチームを立ち上げていく中で、スクラムマスターとしてやってみたことや考えたことの主な3つをまとめてみた。スクラムマスターとしても初挑戦なので、実は間違っている内容や、他にもっとやるべきこと、やってみたけど将来的に失敗と判断することなどもあるかもしれない。その時は今後の投稿で学びとして改めてまとめ直すことにします。最初のスプリントはだいたいうまくいかないと言われているが案の定うまくいかないので、バーンダウンチャートを日々更新して状態を可視化する。開発チームはリズムに乗るまで大変なので日々の状態の可視化はスクラムマスターが頑張る。リズムに乗ってきたら開発チームにまかせても良いかもしれない。さんの資料を参考にした。slide.meguro.ryuzee.comひとまずすぐに取れそうな以下のメトリクスを追加して日々の状態を可視化し、仮説を立てながらチームの状態を分析して必要ならアクションを起こすようにする。スクラムマスターがあまりに事細かく状況を聞いたり、何でもかんでも口を出すと開発チームが疲弊してしまうので、気になるところを中心にポイントを絞ってアクションを起こしたり、気になるメトリクスをチーム内に共有して早めに対策できるようにする。一定のチェックポイントを設定して作業が進んでいるかを把握する稼働が取れているのにコミットが少ない場合は事前調査などで手が止まっている可能性がありそうマージコミットの件数タスクが完了していくペースを把握するレビューの頻度と捉えることもできる(レビューがボトルネックになっていないか)稼働が取れていてコミットもしているのにマージされていないならタスクの完了条件が曖昧なのかもしれないイベントの進行まずは必要なイベントを確実にこなしたいので率先してイベントを進行するか、誰かに任せる場合は明確にお願いして主導権を渡す。スプリントレビューはPO主導で進めてもらいたいので事前にそのことを伝えておく。必要に応じてだと思うが、当面はPOも開発チームもイベントの中身の手順を覚えたり学ぶことが多いので、スクラムマスターがなるべく進行役を担当してイベントの中身の作業に集中させてあげたほうが良さそう。スクラムチーム全体がイベントに慣れていないのでその場でいきなり「○○さん進めて下さい」は絶対にしない。事前にそのイベントで何をするか考えて取り組めば、たとえうまくいかなかった場合でもふりかえって次回スプリントで改善できる。妨害リストを作るスクラムで言われている妨害リストにいきなり取り組むのはやってみた感じではおそらくアンチパターン。妨害の排除はスクラムマスターに与えられた重要な役割の1つなのでリストを作ってチームで共有しておくこと自体は必要と感じている。はじめのうちは漠然とした不安も含めた課題がチームのあちこちで出て来るので、ウォーターフォール型開発で言うところの課題一覧を整理するような形でいったん気になる課題をスクラムマスターが集めてリストアップしておくのはそれなりに意味はありそう。スクラムチームに足りないもの、すぐに手を打ったほうが良いことの優先順位を決めて整理するのに役立つ。プロダクトバックログやスプリントバックログを完了させていくことが最も大事なのでそれらを疎かにして妨害リストを管理するのは本末転倒。当面はスクラム開発のリズムを作ることを重視しつつ優先順位を考えて妨害排除に取り組み、やりすぎない、管理しすぎないほうが良さそう。スクラムマスターが妨害リストばっかり見ていると思われないようにする。スクラムチームのリズムができてきたら、メンバーにも積極的に妨害リストに追加してもらいチーム全体で妨害排除に取り組める雰囲気を作っていく。将来的に目指すべき妨害リストの運用についてはRSGT2018の以下のスライドを参考にイメージしている。speakerdeck.comふりかえりとの違いはチームの外に目を向けて前提を変えられることにある。(1)リンク・転載は法令・公序良俗に反しない範囲で自由です/著作権は全て著作者に帰属しますはてなブログをはじめよう!radiocatさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。