はじめに
スクラムマスターを任されて1ヶ月半が経ったので、これまで実践したことやその狙い、参考にした文献をまとめたいと思います。同じような境遇のスクラムマスターや開発チームの方々の参考になれば幸いです。
開発組織について
- 会社名：株式会社スタジアム
- 開発しているプロダクト：オンラインコミュニティプラットフォーム
- 採用技術：バックエンド(Rails) / モバイル(iOS, Android) / フロントエンド(React) / インフラ（AWS）
- エンジニア数: ６人
スクラムマスターを任される前
約3年前からスクラムを採用し開発をしています。チームメンバーの入れ替わりや会社が分社化するタイミングで少しずつスクラムイベントや内容が変わっていきましたが、一貫してスクラムの原則に厳密に沿っているというよりかは、ゆるいスクラムとして運営していました。
長い年月が経った結果、スクラムを導入したメンバーやスクラムマスターの不在ということもあり、
- スプリントレビューはやったことをドキュメントにまとめて共有するのみ
- スプリントレトロスペクティブは毎回 KPT をとりあえずやる。次スプリントのチームとしての改善アクションが出ていない。
導入当時はいろいろなバランスをとってこの形になっていたのかと思います。しかし、今となってはその意図も明確ではなく、とりあえずこなしている状態になっていたのはチーム全体で感じていました。新しいメンバーも増え始め、これからさらに開発組織を強くしていくために、再度スクラムの運用を設計し直す必要がありました。
そこで僕がスクラムマスターとしての役割をもらうことで、スクラムの改善を行うこととなりました。
僕がスクラムマスターになってからのスクラム
スクラムチームの目標
「良いチームになって、良いものをつくり続ける」
これはチームで作った目標ではなく、僕が勝手に作った目標です。
僕はスクラムの考え方が好きです。特に好きなところは、プロダクトの質と仕事の進め方の改善を実現できるフレームワークとして設計されているところです。
スプリントレビューではプロダクトの振り返り(良いものをつくる)、スプリントレトロスペクティブではスクラムチームとしての仕事の進め方の振り返り(良いチームになる)をすることができるようになっています。いいものを作るためには、いいチームになることが必要だよね？という思想がスクラムのイベントの構成からも伝わってきます。
この意図を忘れないためにスクラムチームの目標として掲げ、スプリントイベントの度に思い出せるようにしています。
スクラムチーム構成
- スクラムチーム: 1つ
- プロダクトオーナー: 1人
- スクラムマスターと開発の兼任: 1人
- 開発チーム: 4人
僕自身はスクラムマスターと開発の兼任です。スクラムの本を読むと開発とスクラムマスターの兼任はアンチパターンとしてよく出てきますが、開発組織の規模と自分自身のキャリアパスとしてもこの形が現状はいいと思っています。実際に開発をしていることで俯瞰的にチームを見れていないと思う時もありますが、スクラムマスターとしての役回りを求められる場面ではスクラムマスターとしての意見やファシリテートをできるように意識しています。
スプリントイベント
- サイクル: １週間
- イベント: スプリントプランニング、デイリースクラム、スプリントレビュー(プロダクトの振り返り)、スプリントレトロスペクティブ(仕事の進め方の振り返り)、スプリントバックログリファインメント(不定期)
スプリントプランニング
最大30分の時間をとっています。
僕たちチームのスクラムではスプリントプランニングまでに各人がタスクの作成、ポイントの見積もりまで行ってもらうことにしています。スプリントプランニングはそれを各人がチームへ共有し、その内容を加味した上でスプリントゴールを決める、という場として利用しています。
バックログリファインメントで実行可能なタスクに分解、スプリントプランニングで新しいスプリントに取り組むタスクの決定と見積もりは開発チーム全員でする、というのが教科書的なスクラムですが、現在はそれに従っていません。理由としては、現状ではプロジェクトは同じでも担当範囲(iOS, Android, Rails等)を明確に区切っているからです。そうであるならば、それぞれがタスクの分解、見積もりをした方が早いですし、それを開発チーム全体でやるほどのメリットがそれほどないと現状は思っています。
タスクの管理はGithub Projectsを利用しています
デイリースクラム
最大15分の時間をとっています。
デイリースクラムは毎日10:00から行っています。デイリースクラムで話すことは型として決めています。
- 昨日やったこと
- 今日やる予定のこと
- スプリントゴールの達成に対して困っていること
デイリースクラムはスクラムチームの開発が順調かそうでないかを検査する場なので、上の３つのことを各人に話してもらえれば最低限必要なことは揃ってるかと思います。
スプリントレビュー(プロダクトの振り返り)
最大30分の時間をとっています。実際に動くものをレビューするというのを前提としています。
これも教科書的な話になるのですが、スプリント単位で出荷可能な成果物をレビューに持ってくるというのが本来の形です。しかし、新機能開発が１週間で終わるボリュームではないことが多いため、出荷可能な成果物をレビューというのは現状不可能に近いです。
そのためプランニングで決めたスプリントゴールに対して、現状はどうなっているのか？と言う視点で振り返るようにしています。また、プロジェクト外の方の客観的な意見をもらえる場としても機能していると思います。
スプリントレトロスペクティブ(仕事の進め方の振り返り)
45分と時間を設定していますが、日によっては1時間超かかってしまうこともあります。ここが今一番固まっていなくて試行錯誤中のところですが、なるべくならチーム全体での改善アクションをアウトプットとする場になるようにしています。
振り返りの手法はKPT等様々ありますが、スプリントの状況や、話し合いたい内容によって手法を変えています。
ずっと同じことをしていると飽きてしまったり、形骸化してしまうというのを経験していたのでここはいろいろ手法を入れ替えています。
一方で現在少し問題になっているのが、ちゃんとアウトプットを出そうと思うと45分だと全然足りず、1時間以上時間がかかってしまうということがあります。
１週間スプリントで毎回1時間チーム改善の為の話し合いというのは疲れるし、ネタ切れも近い将来発生しそうだなと感じていました。そこで、今後は少しレトロスペクティブのやり方を変えようと考えています。
具体的には、ちゃんと話し合ってアウトプットをしっかり出すレトロスペクティブと、チームビルディングを兼ねた軽めのレトロスペクティブを1週間交代でやることで、いい塩梅にならないかな？と考えています。一旦お試しでやってみて、その振り返りをして、スクラムチーム全体でいい方向に持っていければと思っています。
スプリントレトロスペクティブはMiroを利用しています
新しいスクラムで変えたこととその参考文献
スプリントレビューは実際に動くものベース
僕がスクラムマスターを任される前は↑でも書いたようにスプリントレビューはやったことをドキュメントにまとめて共有するだけでした。
現在のスプリントレビューは実際に動くものを見てもらうことを前提にしています。その方が無駄な資料を作らなくて済むし、動くものを見てもらった方が正確なフィードバックをもらえるからです。
参考文献
スプリントレビューの一般的なアプローチは、スプリントゴールの何を達成して何を達成していないかの概要を示し、出荷判断可能なプロダクトインクリメントのデモをして、プロダクトの現状について議論し、今後のプロダクトの方向性を適応させるというものである。
スプリントレトロスペクティブのアウトプットは開発チームとしての改善アクション
僕がスクラムマスターを任される前は↑でも書いたようにスプリントレトロスペクティブは毎回KPTをとりあえずやる。次スプリントのチームとしての改善アクションが出ていないという状況でした。ただ、チームメンバーのプライベートも含む近況が共有される場でもあったので、チームの雰囲気をよくするということに関しては効果があったと思います。
しかし、本来スクラムの振り返りの目的はチームとしての改善アクションを出し、次のスプリントでそれを実行することです。スクラムマスターとしてそれが実現できるように、レトロスペクティブのアクティビティやファシリテーションを工夫してやっています。
実際に出た改善アクションは以下のようなものです。全てのアクションは役職関係なく、チーム全員で話し合って決めたことです。
- スクラムイベントはスクラムチーム全員が参加できるようにする。
- スプリント途中に予定が大きく変わるような差し込みタスクをお願いしない。（スプリントが始まる前に相談する）
- ブログ祭りの開催(開発者ブログを集中的に書く日を設定する)
- エンジニアが全員出社する曜日を決める（現状は週1で木曜日）
参考文献
ゾンビスクラムでは、具体的な改善をしていない
2 週間スプリントから 1 週間スプリントに
僕がスクラムマスターを任される前は2週間スプリントでしたが、1週間スプリントに変更しました。スプリントが1週間になることでスプリントレビューとスプリントレトロスペクティブのサイクルが早くなり、プロダクトとチームの改善が早くなると考えたからです。
また、1週間という短い期間であれば、たとえ何かが失敗したとしてもすぐに修正や切り替えができるという利点もあると考えました。
一方で2週間スプリントの時よりもスプリントレビューがすぐに来るので、以前よりも常に急いでいる感はあります。これは切り替え直後の筋肉痛のようなもので、慣れてしまえばより強いチームになっているのではと思います。しかし、持続可能なペースで働くことが重要なので、タスクの見積もりやスプリントゴールの設定で調整できればと考えています。
参考サイト
したがって、慣れていないうちほど、改善の機会をたくさん用意した方がよく、短いスプリントの方がその機会は多くなります。
今後やっていきたいこと
自己組織化
スクラムの本を読んでいると、自己組織化がスクラムチームの１つのゴールであると書いてあります。スクラムマスターがチームに対して指示を出すのではなく、チームが自ら問題を見つけ、解決するための方法を見つけることが重要だという内容が書いてあります。つまり、自己組織化したチームにはスクラムマスターの存在がそれほど重要ではなくなります。
現状は僕はスクラムのイベントを設計して、ファシリテーションをして、プロダクトとチームが改善していくための環境を作ることに注力していますが、チームが自己組織化するための働きかけはまだできていないです。
今後は、チームが自己組織化するためにはどうすればいいのか？という視点でスクラムマスターとしての役割を考えていきたいと思います。
まとめ
まだスクラムマスターになって少ししか経っていませんが、少しずつ開発チームの働き方が改善されているように思います。スタジアムの開発チームは新しいことを導入した時も協力的に参加してくれるメンバーが集まっているので、スクラムマスターとしてとてもやりやすい環境が整っています。
これからもスクラムで改善を重ね、「良いチームになって、良いものをつくり続ける」という目標に向かっていきたいと思います。
おまけ
新米スクラムマスターを任されることになって情報収集のために使った本を紹介します。
まず最初に「SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発」を読みました。漫画と新人スクラムマスターがスクラムを実践していくというストーリー仕立てになっているので、スクラムの全体感を掴むのにとても良かったです。
次に「エッセンシャルスクラム」を読んで、スクラムイベントの詳細な内容を学びました。実際にスクラムを再設計する上で細かい部分まで書いてあるので、辞書的に利用していました。
次に「ゾンビスクラム」を読んで、スクラムのアンチパターンを学びました。スクラムの本を読んでいると、スクラムの理想論ばかりが出てきますが、避けるべきアンチパターンも知っておくことは重要だと思います。
実際にスクラムを運用していくフェーズになると、スプリントレトロスペクティブに利用できるアクティビティの種類を増やしたいなと思いました。そこで「アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き」を読んで、レトロスペクティブのアクティビティを学びました。
また、「アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット」も読みました。こちらの方が漫画形式であること、日本人著者であることから、読みやすかったのでおすすめです。
スクラムマスターってそもそも何するんだっけ？ということを知りたくなった時には「SCRUMMASTER THE BOOK 優れたスクラムマスターになるための極意――メタスキル、学習、心理、リーダーシップ」を読みました。自己組織化を促す為のスキル、知っておくべきことが書いてあります。
Discussion