ざくっと当時のチームの状況を
- フルリモート
- 開発メンバーはスクラムマスター兼任の私含めて4人
- よくあるアプリ開発ではなく、社内アプリの運用をスクラムのフレームワークにそって推進
辛かったことを列挙する
メンバー
- 学びたがらない
- マニュアル作業を淡々とやりたい人がスクラムチームに来てしまった
プロダクトオーナー
- 何を実現したいか語らない
- 長期的な目標がなく、チームが外部（POの上司や関連部署）に振り回される
- 開発チームの実現方法に干渉する
- 議論すべきことが議論されず、技術的欲求を満たすために時間が使われてしまう
- スプリントの最中によくタスクが差し込まれる
- 計画がないため思いつきで、優先度が分からなくなる
- 自身が思い付いたアイデアを気に入っていてチームの意見を取り入れない
- PBIが明確になる前に着手せざるを得ない
- ネタが不足
- 情報も不足
- 忙しすぎてスクラムイベント以外でコミュニケーションが取れない
その他
- スプリントレビューにチーム外のメンバーを呼びたいが呼べない
- 社内アプリの利用者を呼びたいが、そもそも利用者が少ない。またスプリントレビューに対する理解がないので「スプリントレビューってのはスクラムのイベントで、スクラムってのは...」っていうところまで説明する気にはなれなかった
スクラムマスターとして頑張ったこと
-
自分の開発タスクを後回し、他のメンバーにやってもらう
- 慣れたスクラムマスターでも稼働時間の50%ぐらいはスクラムマスターの作業に費やすらしい。
- 特にチームを立ち上げたばかりの頃はやることが多い
- メンバーにスクラムの説明をする
- PBIのストックを用意する
-
デイリースクラムはあえて時間いっぱい行う
- やる気が低いメンバーは「特に困ってません」って言いがち。余った時間で特定メンバーのタスクをピックアップして進捗を詳しく聞いてみる。詳しく話をさせるとなんやかんや困ってて白状してくれる。何度か白状させるとデイリーで相談してくれるようになった。
-
メンバーがPOと話せる時間を作る
- 進行中のタスクに関する相談から、次スプリントの実施内容まで、何を話すかはその場で決めるけど、とにかくPOの空き時間を抑えて開発メンバーを集める
もし次スクラムマスターやるなら？
- チーム全員が（PO含めて)単一のプロジェクトに所属している
- スクラムマスターは開発メンバーと兼務しない
- 開発メンバーの選定を慎重に行う。もしもに備えて3ヶ月程度でリリースできるようにしておく
- スプリント0としてドキュメントの作り込みを入念に行う。ドキュメントやPBIが作れるまでスプリントを開始しない
- チーム外の関係者をうまく巻き込む