フラクタルスプリントのモヤモヤを考案者のkyon_mmさんと解消してみたよ
DevOps Days Tokyo 2024でkyon_mmさんとの廊下トークを通して学んだ内容です。フラクタルスプリントのモヤモヤをふせんを使って一問一答形式で解消できました。kyon_mmさん、本当にありがとうございました!
フラクタルスプリントとは?
通常多くのチームで採用している1~2週間スプリントに、15分、1時間などより短い期間のスプリントと、1ヶ月などより長い期間のスプリントを組み合わせる手法です。それぞれのスプリントの構造は同じものが集まって全体を構成しています。
本家kyon_mmさんのブログ記事や、森さんのQiitaがとても参考になります。
モヤモヤその1:スプリントを短く・小さくすると、ムダが大きくならない?
Q: スプリントを短く区切ってその中にスクラムイベントを組み込むことで、必要ないイベントが増えすぎないかな?
また、15分スプリント内のレビューではレビューするほどの成果物が作りきれてなくない?
A: まずフラクタルスプリントの前提として、問題が表面化する前に予防することに重きを置いているよ。
問題が発生する前にできるだけ早いタイミングで予測して検知して予防することがモチベーションだよ。
自分たちにとって新しいこと(新メンバーの追加、新しい技術要素の追加など)があると実際にやってみるまで予測することが難しい。
後で問題に気づいて手戻るムダを極力無くしたいよ。また、各スクラムイベントは必要なければスキップでもOKだよ。
モヤモヤその2:1ヶ月間、3ヶ月間のスプリントなど、通常よりも長い期間のスプリントは必要?慣れ親しんだ1週間スプリントだけで良い?
Q: 通常より長い方のスプリントの目的はビジネスとのアラインだよ。
基本的にPOやPdMのようなビジネスに責任を持つロールではQ毎のタイミングでリソース(お金、人、時間)、収益を検査して適応したり、計画を見直しているよ。
なので、通常採用しているような1週間や2週間といった周期と時間軸が合わない。イケてるPOやPdMはそれを理解してい、1ヶ月ごと、3ヶ月ごとに開発とビジネスを同期させる場を持たせるが、それを経験則や暗黙知にするのではなく、仕組みに落とし込んだのがこれだよ。
まとめ&所感
ざっくりした目的はイメージがつくものの、当初はなぜフラクタルスプリントなのか?その価値はなんなのか?が曖昧だったところで、対話を通してフラクタルスプリントに対する解像度が爆上がりしました。
さっそく私たちのチームでもやってみようと考えています。
kyon_mmさん本当にありがとうございました!
DevOpsDays Tokyo 2024で意図しない出会いと発見の場を作っていただいたことに感謝です。