やってみて気づいたこと

スクラムマスターの仕事は「スクラムチームを改善する」ことに尽きると思った。その観点で次の事が特に大事だと気づいた。

「スクラムチームの改善」は「プロダクトの改善」と同じ
- スクラムチームを一種のプロダクトだと考えて、課題見つける→PBIにする→解決する
- SMはスクラムチームの改善において、いわゆるプロダクトオーナー的な役割である
  - 司会・議事録係・ミーティング調整役ではない
まずはとにかく透明性をあげる
- プロダクトオーナー(PO)、BizDev、エンジニア、デザイナー、ドメインエキスパート、SM、etcのやってることや頭の中を見える化する
- コミュニケーション量や回数を増やすことは見える化に重要
  - コミュニケーションが生まれやすい仕組みをどんどん試してみる
  - わからないことは率先して質問しまくってチーム内のコミュニケーション潤滑油にする
改善結果はスクラムイベントに組み込む
- 改善したものは仕組み化して継続していきたい
- そのために可能な限りスクラムイベントに組み込んで、自然と継続できる形にするとよい

取り組んだこと

色々やったけど、特に良かったなと感じたものをざっと書き出しておく。

スクラムガイドを読み直した
- SMになったときに何をすれば良いのかわからなかったのでスクラムガイドを読み直した
- 読み直したけど、やっぱり抽象的でよくわからなかった
- けど、↓を読んでスクラムチーム自体の改善をするとよさそうかな〜とぼんやり思った
チームにKeep/Changeアンケートを投げた
- 具体的にどんな改善をすればいいのかわからなかったので、アンケートを投げてインプットをもらった
スクラム改善を見える化した
- カンバンを作成して、アンケート内容をPBIとして積んでいった
- 毎週一人リファインとプランニングをしている
スクラム改善の進め方を考えた
- 全部一気には無理なので、1スプリント(1week)で1改善を目安にすすめることにした
- 当初は初速を重視して、改善の実務はSM単独でやることにしてみた
やりたいPBIをみんなで話した
- 積んだPBIを元にメンバー数名と各自がやりたいPBIを話した
- 結構バラけたので、参考にしつつまずは何に取り組むかをSMとして意思決定した
プロダクトオーナーとチームOKRについてめっちゃ話した
- OKRの背景、達成のための登り方、現在の状況、エピック、スプリントゴール、将来の展望などなど
- 1on1で話した後、チームメンバー全員呼んで1onNでも話した
- このチームOKRについて話す会は毎週行うようにした
マーケットの調査や検証のタスクもPBIにするようにした
- こういうタスクはPOやBizDevがやってるけど、チームへの共有にばらつきがあった
- PBIにすることで見える化され、チームへの共有はもちろん、リファインメントやプランニングでも扱えるようになって透明性がめっちゃあがった
スクラム改善で消化したPBIをチームの定期MTGで共有
- どんな改善をしたか、次どんな改善をしたいかを共有して、インストールとフィードバックを得る
リファインメントのチートシート作成
- リファインメント時に重要な点をチートシートにして、認識揃えたり議論するのを忘れないようにするため
- まだブラッシュアップは必要そう
リファインメントではWhy・Whatに集中して、Howはあまり話さないようにする
- これは僕がやったというか以前からPOが意識してたけど、それをより意識するようにしていった

次にやりたいこと

SMとしての動きについてチームメンバーからのフィードバックは好評だった。一方で次に改善すべき点も色々見えてきたので、それを試していきたい。

具体的なHowの検討をより良い感じにしたい
効果検証・学習・スプリントレビューなどの検査周りを良い感じにしたい
可能な限りチームメンバー全員でSM業務をやれるようにしたい
- 理由: 一人で改善するより全員で改善するほうが、視点や解決策などが多様になって強くなるはずだし、自己組織化にも有益そうだから
- スクラムイベントの司会や議事録業務をチーム内で回す
- スクラムチーム改善をチームメンバーも消化できるようにする
  - そのためにはスクラムチーム改善の型を作る必要がありそう
  - スクラムチーム改善もスクラムで回せるようにして、SMがそのPOをするようなイメージ