それデイリーやない。レイニーや。
はじめに
こんにちは。学園アイドルマスターにハマっているスクラムマスターの池永です。
レバテック開発部ITSプロダクト開発グループに所属しており、日々チームが強く、楽しくなれるように試行錯誤しております。
先日、以下の記事を投稿したのですが、他のスクラムイベントにもあるあるはあるよなと思い、デイリースクラムのあるあるも早く言いたくなりました。
こちらも何か参考になる情報がありましたら幸いです。
話すこと
- スクラムにおけるデイリースクラムのあるある
- あるあるに対して自分がやったこと
- そのアプローチをとってどうなったか
話さないこと
- スクラムにおけるデイリースクラムの詳細な目的
- デイリースクラムの具体的な進め方
では早速...
例に漏れずあるあるを早く言いたいので、挙げていこうと思います。
1. ただの進捗報告会になりがち
スクラム導入間もないチームでは、デイリースクラムがただの進捗報告会になってしまいがちです。
自分が初めてスクラムマスターとして参画させていただいたチームでは、
各メンバーのやったこととこれからやることを報告してもらい、ファシリテーターが「はい。承知しました。本日もよろしくお願いします。」と言ってデイリースクラムを終えてしまっていました、、、、（大反省）
このようになってしまうと各人で抱えている問題などに気づくのが遅れ、スプリントゴールの達成がどんどん難しくなってしまいます。
やったこと
- デイリースクラムのルールに以下の内容を明記した
- 共有する内容は以下の3点
- 前回のデイリースクラムの後、自分は何をしたのか？
- 次回のデイリースクラムまでの間、どんな作業をする予定なのか？
- 進捗の妨げとなる障壁は何か？
- 共有する内容は以下の3点
〜一定期間後に〜
- デイリースクラムの前に「ムードメーター」の共有を行うようにした
自身の場合、書籍「エッセンシャルスクラム」を参考にこのルールを設定しました。ルールを設けることで、各人で抱えている問題への検査・適応を行える状態にしたかったのです。
しかし、ただ「問題も共有してください！」と決めるだけでは なかなか共有は難しいもので問題を共有しても良いと思わせる心理的安全性を築く必要がありました。
自身の場合はアイスブレイクとして面白そうであったムードメーターを導入しました。
どうなったか
各メンバーから、困っていることの共有も挙がり始め、スプリントバックログを適応させる動きが見られるようになりました。
ムードメーターに関しても思ったよりメンバーがノリノリで話してくれたことで、メンバーの今まで見えなかった一面も見えるようになり、心理的安全性の構築という観点で寄与してくれたように思います。（メンバーに恵まれました）
2. タイムボックス守れなくなりがち
デイリースクラムをやっているとメンバーの誰かが困っていること（問題）を挙げてくれることがあります。
自分が参画させていただいたチームでは、その問題に対して、どのように適応していくかの議論が発散しすぎてしまい、規定の時間（15分）をオーバーしてしまっていました。
議論が発散している間、その問題に関係していないメンバーがデイリースクラムに参加している場合もあるので、そのメンバーはただ聞いているだけの時間になってしまいます。
また、問題の解決にステークホルダも巻き込む必要がある場合、デイリースクラムにステークホルダは参加しないことが多いため、解決がそもそもできない場合もあります。
メンバーが順番に共有するデイリーでは、1つ目の問題の議論が長引くことで、メンバーが会議が間延びしてしまっていることに気を遣い、自分が抱えている問題の共有をやめてしまうかもしれません。
やったこと
- デイリースクラムのルールに以下の内容を明記した
- 報告の上がった問題の解決は「しない」
問題に対して適応していくことはもちろん必要なのですが、デイリースクラムの一番の目的はチーム内の現状を把握することであるので、その議論に時間を割くよりは全員から現状の共有をしてもらうことに集中しましょう。
どうなったか
各メンバーの共有がスムーズに行われるようになり、時間に余裕ができたことで、デイリースクラムで検査することができた問題に対してのアプローチも考えられるようになりました。
例えば、
Dev「さっき〇〇さんが共有してくれた、〜がわからない件なのですが自分が知っているのでデイリーの後話すお時間いただいていいですか〜？」
PO「〇〇さんの〜の仕様で相談したい件、この後ステークホルダー招いてMTGセッティングしちゃいますね！」
などです。
一度、確実にチームの現状を把握することで必要に応じた適応ができるようになりました。
3. 他のメンバーの共有の内容を聞かなくなりがち
各メンバー（特に開発者）が、デイリースクラムで共有する内容は上述した対策により漏れがなくなり、デイリースクラムもうまくいくようになってきたな。と思っていたところでした。
ある日、私は「あれ、なんか適応のスピードが遅くなってきたな、、、、、、、」と気づきました。
メンバーの話を聞いてみたところ、私達のチームの場合は「バラバラのタスクに取り組んでいるためデイリースクラムという短い時間での共有だけでは結局何をやっていて何に困ってるかわからないからあんまり聞いていない」という意見があがりました。
各人がそれぞれ別のプロダクトバックログアイテムのタスクを進行している、つまりチームで同時に着手しているプロダクトバックログアイテムが多すぎる状態になってしまっていたのです。
この状態になってしまうとそれぞれのプロダクトバックログアイテムや知見が属人化してしまい、誰かが遅れてしまっただけでスプリントゴールの達成が危ぶまれるなどの問題が発生してしまいます。
やったこと
- WIP制限を設けた
- チームで同時に並行して進めるPBIを（メンバーの数-2）個までにした
- ペアプロ・モブプロなどのプラクティスを積極的に導入した
どうなったか
チームで同時に着手しているプロダクトバックログアイテムが減ったことで、チームが現在取り組んでいることへの理解が高まり、デイリースクラム後の適応がスムーズになりました。
各メンバーが互いにフォローしたりできるようになっていて、嬉しかったです。
終わりに
本記事では自身の経験をもとにデイリースクラムでの「あるある」に対してどのようなアプローチをとったかを紹介させていただきました。
これらの実践をしていく中で、デイリースクラムでの会話の質が大いに上がったのを感じることができました。
デイリースクラムはチームメンバー全員が話し、毎日行う大切なスクラムイベントですので、ここが上手くいくかどうかでチームメンバーのモチベーションもアウトプットも大きく変わってくるのでは？と自分は思っております。
実際デイリースクラムを改善してから、スプリントゴールの達成率は大きく向上しました。
メンバーからも、
「デイリースクラムで共有した問題が解決するまでが早くて開発が楽になった」
などといったポジティブな意見もいただきことができました。
たった15分の会議でも侮ってはいけないですね！！！！🔥🔥🔥🔥
まとめ
今回のあるあるの改善に取り組んでみて、学べたことをまとめます。
- デイリースクラムはただの進捗報告会ではなく、検査と適応にまで寄与する大事なイベント
- 無理にその場で解決するのではなく、情報を集めて変化に気づくことのほうが優先
- デイリースクラムの異変に気づくことで、大きくなってしまいそうな問題も早めに対処できることがある
以上です。参考になったものが一つでもあると嬉しく思います。
ひとつだけ宣伝...
6/27に開催される「Agile Effect MeetUp vol.1 「なんちゃってスクラム開発からの脱却」」に登壇させていただくことになりました！
自身は「ベロシティはそもそもなぜ測るのか」というテーマでお話させていただこうと考えております！
- これからスクラムを始めようとしている方や始めたばかりの方
- スクラム開発を始めたは良いけど間違った進め方をしていないか不安な方
- なんちゃってスクラム開発をしているなぁと思う方
- スクラム開発に明確な課題を持っている方
- スクラムマスターをしている（これからする）方
上記のような方におすすめのイベントとなっておりますので興味がありましたら参加の検討をお願いいたします！
参考
記事：いまの状態を「100の感情」から選び言語化する習慣で、パフォーマンスが最大化する理由
書籍：エッセンシャルスクラム
記事：デイリースクラムの進め方
記事：スクラムにおけるデイリースクラムとは？アンチパターンや失敗例も解説
書籍：アジャイルプラクティスガイドブック
レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech
Discussion