4
Help us understand the problem. What are the problem?

More than 1 year has passed since last update.

posted at

updated at

Organization

30分フラクタルスプリントの実験と効果

30分フラクタルスプリントの実験と効果

チーム「オキザリス」では、今週から30分フラクタルスプリントへの実験を試みています。

image.png

チームの中からも「やりやすい」「疲れない」「達成感がある」といった意見も出ており、1週間だけでもかなり効果を感じています。

この記事では、30分フラクタルスプリントの方法や効果、そこに至る背景などを説明していきます。
なお、30分フラクタルスプリントを流行らせたい、という意図はありません。自分たちの環境に合わせて、よいやり方を模索してみてください。

前提知識

スクラムに関する知識。また、モブプログラミング・モブワークに関する知識。ここの記事では説明しません。
また、この記事はScrum Fest Osaka 2020にチームで参加した私たちのチームはモブワーク+フラクタルスプリントにTryすることになりましたをお読みいただいた後だと、より理解が深まります。

環境

image2020-10-28_11-28-38.png

アジャイルチーム

PO兼Dev 1名(私)
SM兼Dev 1名
Dev 3名

マーケティングチーム

PO兼Dev 1名
Dev 1名

の計7名。

ファシリティ

  • フルリモート開発
  • Jiraによるプロダクトバックログ管理
  • Miroによるスプリントバックログ管理
  • Mattermostによるチャットコミュニケーション
  • Zoomによる常時接続

30分フラクタルスプリントの概要

image.png

スプリントの最小単位は30分です。
これを1時間、3時間、1日、1週間というサイクルで回します。

30分スプリント

02分 スプリントプランニング
20分 開発
02分 スプリントレビュー
01分 ふりかえり
05分 休憩

スプリントプランニングでは、20分の開発で実装するプロダクトバックログの実現方法を話し合います。ここで、5分〜20分のタスクに分割します。

開発では、モブワークによりインクリメントを作り込みます。モブの切り替えタイミングは任意です。

スプリントレビューでは、その時点でのスプリントの成果や、受入条件の達成状況をJira, Miroに記載します。勿論、インクリメントが開発時間内に完成した場合は、その都度Jira, Miroに記載しているため、次のスプリントへのインプットを確認するための活動になっています。

ふりかえりでは、Mattermostの「ふりかえりチャット」にふりかえり内容を記載していきます。2-3行書いたらおしまいです。

休憩時間は、トイレに行ったり、雑談したりします。

1時間スプリント

30分スプリント×2を以下のように組み合わせます。

スプリント1

02分 スプリントプランニング
20分 開発
02分 スプリントレビュー
01分 ふりかえり

スプリント2

02分 スプリントプランニング
20分 開発
02分 スプリントレビュー
01分 ふりかえり

休憩

10分 休憩

30分に一度細切れで休憩を取るより、1時間に一度まとめてとった方がよい、というカイゼンが行われた結果、このような形となりました。

3時間スプリント

1時間スプリント×3で行います。
10:00-12:00+13:00-14:00の3時間と、14:00-17:00の3時間です。

前半の3時間スプリント、後半の3時間スプリントで、(兼務の関係で)開発を行うメンバーが入れ替わります。

3時間スプリントごとに、ふりかえりの中で「午前のふりかえり」「午後のふりかえり」という単位でふりかえりを行い、次の3時間に向けたアクションを話し合います。

1日スプリント

1日は30分スプリント×12で出来ています。

最初の30分スプリント

1日の最初のスプリントプランニングでは、1週間のスプリントゴールを確認し、今日1日のスプリントゴールを作ります。
そして、プロダクトバックログを30分単位の価値ある単位に分解します。
事前にプロダクトバックログリファインメントにより、3時間未満のサイズにプロダクトバックログは分解されているため、この作業は5分-15分程度で終わります。

不確実性や変化への対応のため、1日分の計画は10スプリント分程度にしています。12スプリント全てを埋めるような計画はしません。

間の30分スプリント

30分スプリント、1時間スプリントのサイクルにしたがって開発を行います。

最後の30分スプリント

予定された開発が終わっていれば、明日のための1日分のスプリントプランニングを事前に行います。開発が終わっていなければ、通常の30分スプリントの動き方で動きます。

今のところ、開発が終わっているパターンと終わっていないパターンとで、半々くらいの確率です。

最後のふりかえりでは、1日のふりかえりと、次の日に向けたカイゼンを話し合います。

Delivery Sprint

30分スプリント、1時間スプリント、3時間スプリント、1日スプリントのサイクルに合わせて、月曜、火曜、水曜、金曜午前(3時間分)の計21時間分を開発に費やします。

木曜午前はグループの定例会で活動はありません。午後はアジャイルチームとマーケティングチームが合流して、Marketing Sprintを行っています。こちらも、30分、1時間、3時間スプリントのサイクルで、マーケティングに関する活動を行います。

マーケティングチームは、木曜日以外は2人チームで別途30分、1時間、3時間、1日スプリントのサイクルで活動を行っており、木曜のみチームが合流して活動します。

Discovery Sprint

金曜日午後(14:00-17:00)をプロダクトのディスカバリのための活動として定義しています。

  • 30分 プロダクトバックログリファインメント
  • 30分 プロダクトバックログリファインメント
  • 30分 スプリントレビュー
  • 30分 プロダクトバックログリファインメント
  • 30分 プロダクトバックログリファインメント&スプリントプランニング
  • 30分 ふりかえり

プロダクトバックログリファインメントでは、通常の1週間スプリントで行う活動と同じイメージです。

スプリントレビューでは、1週間に一度、ステークホルダーを呼んで1週間のインクリメントと今後の活動について話し合います。

スプリントプランニングでは、次の1週間に向けてスプリントゴールを設定したり、プロダクトバックログを選択したりします。

ふりかえりでは、1週間分のふりかえりと、チームの実験やアクションについて話し合います。

1週間スプリント

Delivery Sprint + Discovery Sprint (+Marketing Sprint) で1週間のサイクルを回します。

背景

1時間フラクタルスプリントを2ヶ月程度続けてみて、サイクルには慣れていたところでした。
ただ、「最近エクストリームな実験をあまりしていない」「モブのやり方はもっとカイゼンできそう」「不確実性や変化にまだまだ対応しきれていない」という課題感から、単位を変えてみようということで30分スプリントへの変更を行いました。

スプリントサイクルの変遷

2日スプリント

image.png

最初は2日から。稼働日は水・金のみに集中。

3時間フラクタルスプリント(2日)

image.png

2日を3時間単位で区切り、フラクタルに。

1時間フラクタルスプリント(2日)

image.png

3時間を1時間単位で区切り、フラクタルに。
ここからMarketing Sprintが入って、実際の稼働日自体は水・木・金の3日間。

1時間フラクタルスプリント(4日)

image.png

チームメンバーが増えたことにより、動き方を再編。
稼働日は月・火・水・金(アジャイル)+木(マーケティング)の1週間。
頻繁にメンバーが入れ替わるようになり、カオス(混乱)が生じた。

30分フラクタルスプリント(4日)

image.png

1時間フラクタルスプリントに慣れてきた。1時間を30分に。

稼働日

30分フラクタルスプリントの効果

変更当初の狙いとしては、以下を考えていました。

  • プロダクトバックログの分割がもっと上手になる
  • モブのドライバー、ナビゲーターの切り替えがよりシームレスになる
  • タイムボックスをより意識できるようになる

実際に実験してみて得られた効果は以下の通りです。

プロダクトバックログの分割がうまくなるだけでなく、プロダクトバックログへの理解が深まる

チームに10月に入ったばかりの若手の開発者は、技術的背景や経験が(他メンバーに比べると)弱く、プロダクトバックログへの理解が甘い部分がありました。プロダクトバックログリファインメントの時に、理解を説明してもらったり、モブの切り替えを頻繁にして不明点をすぐに見えるような工夫をしていましたが、今回の30分スプリントにより、理解度がぐんと向上したように思います。

ドライバー/ナビゲーターの切り替えのロスが減る

これまではMobsterというポモドーロタイマーツールを使っていましたが、30分スプリントの導入により、切り替えのタイミングすらもったいない、という状態になりました。強制的に「自発的にドライバー/ナビゲーターを切り替える」必要が出てくるため、各自が自発的にドライバーを奪いに行ったり、手放したりする動きが出てきました。

分散作業が上手になる

「関係者にチャットを出す」「チケットを更新する」「メールを出す」「調べ物をする」といった「バラバラにやった方が効率が良い」作業を、全員が今まで以上に自発的に探し、動くようになりました。
基本的にはモブで動きつつも、要所要所で分散して動くという動き方ができるようになってきました。

強制的に止まりやすくなった

1時間スプリントの頃は10分間のポモドーロタイマーを使っていて、切り替えのタイミングごとに時間がずれていったり、その場ですぐに止まらず作業をやり続けてしまう、ということが見られました。

今回は、スプリントプランニングと開発合わせて22分でタイマーをセットして、22分経ったら強制的にその場でストップします。1時間スプリントの時と比べると「あと何分?」「じゃあここまではやろう」みたいな会話になりやすく、必ず停止して状況を確認するスキームが出来上がりました。

疲れない

1時間スプリントだと、1日の後半は結構ばてていました。問題が発生した時や、うまくいっていないときに、強制的に区切られ、ふりかえりでリセットされることで、精神的なストレスもたまりにくくなりますし、なにより問題を解決するスピードが速くなった気がします。
1時間スプリントと時間の使い方自体は一緒なのですが、時間を組み替えて、30分単位にスプリントの活動をすることで、ここまで変わるんだなという実感が得られています。

実験をするマインドが加速した

1時間スプリントに変化するときはチームの心理的抵抗がかなり大きかったと思いますが、今回はほぼ0のように見えました。これなら「15分いけますね」という話がほとんどのメンバーから自発的に出てくるくらいには、前向きに挑戦しています。

状況が分かるようになった

スプリントに参加してなくても、ふりかえりのチャットを眺めれば何をやっていたのかがすぐに分かるようになりました。これまではメンバーが交代したタイミングで状況の同期に少し時間が取られていたのですが、それがさらに短くなりました。

交代しやすくなった

トイレに行ったり、急な割り込みでいなくなったり、というのが痛手にならないようになりました。
最低2人以上いれば、勝手にチームがうまく回っていっている状態になります。
(1人の場合はどうしてもさぼってしまったり、品質が落ちてしまったり、と相互作用の恩恵が受けにくくなります)

30分フラクタルスプリントのデメリット

あまりデメリットは感じていませんが、あえて挙げるとすれば、ふりかえりで色々な手法が試しづらくなったところです。今までは1時間スプリントの中で3分ふりかえる時間があったので、手法を選択してそのフォーマットでやってみる、みたいな動きが出来ていましたが、今は1分しかありません。
チャットでbotが「この形式でやろう」みたいに呟いてくれればそれはそれでいいのかも。

おわりに

今回、30分スプリントの話がチームメンバーから出てきたのがとても嬉しかったです。
この形もすぐに変化しそうな気がします。
今後の変化が楽しみです。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
4
Help us understand the problem. What are the problem?