これはNE Advent Calenderの21日目の記事です！毎年会社のアドカレに参加していますが、書く記事を2021年から+2ずつ増やしていき、2023年、ついに7日分の記事を書くことになりました。7日間あすみアドベントカレンダー的には3日目の記事です📚

「この1年、スクラムマスターとして活動していた自分の間違っていたことをふりかえっていくぞ〜〜！！」＆「あの頃読んで好きだった本のOSUSUME〜〜！！」を7日間通してやっています💪

来年一人アドベントカレンダーやるぞ！！！
— あすみ (@asumikam) 2023年12月20日

▲ ひょんなことから来年は1人アドベントカレンダーをやることになりました。やりてえな〜、ってにわかに思っていたことなので、このタイミングで宣言できたのはアツいですね。マジで来年たくさんブログ書くぞ。というか毎月ちゃんとネタを貯めていかなきゃ！！！

1/1から…？
— ちゃちい (@chatii) 2023年12月20日

▲ それにしても、このおにいさん、意地悪すぎやしませんか。

では、気を取り直してやっていこう〜〜🍥

「スプリント内に終わらない」は観察不足

どんな罪か

これは題名の通りなのですが、スクラムをやっていって中盤を超えたあたりから「スプリント内に終わらない」ことが段々増えてきました。スプリントプランニング時点では「このくらいの開発タスク量だったらいけるな...！」となっているのですが、いざやっていくとスプリント終盤でいわゆる"考慮漏れ"だったり"追加対応"が出てきて結局スプリント内にインクリメントが出るところまでいかないのです。 1番まずいな、と思ったのは、「スプリント内で終わらないぞ」となった開発者たちがスプリント最終日のどっぷり夜中まで開発しているのを発見した時です。もちろん開発者たちもそれをするのはまずいと分かっていながらも、連続してインクリメントが出せていないプレッシャーと、良いものを作りたいという感情からこの行動に出たのです。健全なチームを作れてないことにめちゃくちゃ大反省しました...。

レトロスペクティブでもこの課題は取り扱い、Next Actionは出るのですが「スプリントプランニング時点では"できる"となっているのにそれが完了できないのは、大部分が"実装力"に所以するところが多いのでは」という雰囲気がチームに漂っていました。

ただ、あることをきっかけにその考えは変わりました。

きっかけ: ツールを変えてみる

どっぷり夜中までやったスプリントのレトロスペクティブで、Problemとして「スプリントをやっていってるとタスクの全体感が見えにくい」のような話がでました。ここでいう"全体感"とは、全部のタスクが見えてないというよりかは、なんというか、全体図としてタスクを掴めない、タスクの構造が掴みにくい、みたいな感覚です。（うまく伝えられない.....）

私たちのスプリントバックログはAsanaで管理しています。スプリントバックログを分解して、それを1つのレーンにどばーっと並べ、タスク間の依存を考慮しながら上から1つずつこなしていく方式でやっていました。確かに、1つのレーンに上から下で並んでいる状態だと頭の中で構造化したタスク構造は見えにくいか、と思いました。

そこで、タスク管理の方法をMiroでやってみることにしたのです。...やってみる、というか、元々Miro上で必要そうなスプリントバックログアイテムをバーっと並べてみてそれをAsanaに入れて進捗を管理をする、と言う形をとっていたのですが、Asanaに入れるのをやめてみました。正直「よくなるからそうする」と確信していたというより、「もうなんか面倒だからこのままタスク管理すっか」くらいの気持ちでした。

▲ 「進捗中のやつには名前を振ろう」「終わったやつは黄色→黄緑にしよう」「終わりかけのやつは黄色→緑にしよう」「後回しでいいやつは次の週でやろう（2週間スプリント）」「マジで忘れちゃいそうなことはピンクのふせんで目立たせておこう」とか、必要なタイミングでチームでの定義を作ってタスクを進めていきました。

全体が見えることで毎回俯瞰してみやすいのと、ふせん（タスク）が増えた時は「昨日見ていたタスクの構造の図」と違ったので認識しやすいなという感覚がありました。

このように管理した結果、なんと、このスプリントはスプリント内に終わったのです。久しぶりにやりたいことが終わったスプリントでした。

ふりかえり、反省する

固定概念を作ってしまい、観察を諦めていた

今ふりかえってみると「プロセス・ツールに問題がある」からできていなかった面があるのですが、今までうまくいっていたプロセス・ツールだったのでそこに問題がある、と疑えず「実装力が足りないから、実装力をあげるしか無い」と 観察を諦め固定概念を自分の中で作っていました。スクラムマスターとしてチームをめちゃくちゃ観察していかなきゃいけないのに、それを諦めて、自分自身で超えられない壁を作ってしまっていたのです。

あとそもそも「スプリントバックログは変化していく」という感覚が自分の中で足りていなかった面もあります。タスクが増えるたびに「これが最初のプランニングで出られないのは何故だろうか...」という気持ちになっていました。その考えをめちゃくちゃ改めるきっかけとなったのが今日紹介する本に書いてあったことなので、この後の「Today's Osusume Books」を楽しみにしていてください。

また、プロダクトオーナーとの期待値調整ができていなかったところもありそうです。「ちょっと間に合わなそう」となった時点で「プロダクトオーナーと相談してスコープ削る、方向転換する」というのもとれたのですが、前述の「スプリントバックログは変化するもの」という考えが足りなかったことから初回に作ったものをやっていかなきゃいけない、と思っていました。

あの頃は「打つ手なし」と絶望してしていましたが、今考えると、まだまだできることはめちゃくちゃあるな......と改めて痛感します。

まとめ

"観察する"ことがスクラムマスターの役目だけど、その領域は割とフリーダムなので、ある意味自由に考えて動く必要があるからすっごく難しいなぁって今でも思ってます。スクラムマスターのしなきゃいけないことってなんだかんだマジでなんでもやる人すぎて、「何をやる人ですか？」に一言で答えられないがちです。

ただこの経験があるからこそ、次壁に当たった時も「まだ何かできることがあるはず」と思えるマインドは形成できたかな、と思います。

もっともっともっと！！！！！観察、していくぞ。

あと、全然関係ないんですけど、2日に分ける予定だったものを1日にまとまってしまった。ネタをもう1つ捻出する必要があります。頑張れ俺。

Today's Osusume Books

ユーザーストーリーマッピング

これーーーーーーーーー。わたしの考え方をガラッと変えてくれた2023年、あすみらぶち本にセレクションする本です。1番好きな本です。（アジャイルサムライと同率で！！！！！！！！！）

ソフトウェア開発の古いやり方では、後で（すでにリリースの期日を推計したり、約束した後で）そういった新しい仕事が見つかると、それらをスコープクリープと呼ぶ。しかし、私はスコープ（仕事の範囲）がクリープ（知らない間にふくらむ）することはないと思っている。単に理解が進んだだけだ。そしてストーリーマップを作りながら見つかるのは人々の理解に空いた穴だ。

(p.49 / 2.3 いつでも仕事は多すぎる)

マジで人生を変えてくれた文章です。

今日の大罪にも書いたように、わたしはそれらを"考慮漏れ"と思っていました。「中盤からうまくいかなくなった」というのも、最初の方は領域が小さかったから"見えている"ものが多かった、開発が進んでいき領域が増えることで"見えている"べきものが増えていったんだなあ、とめちゃくちゃ解釈一致しました。

"理解が進んだ"という視点は、今までの"考慮漏れ"をポジティブな認識に変えてくれました。私たちは完璧じゃない、不完全なチームだからこそ、"理解が進む"瞬間は必ずある。チームとしての成長の余地なんだ、と思えるようになりました。

まぁもちろん、"見えている"ものが今より増えたらそれは最高ではあるので！！そこは！！！！目指しますよ！！！！！！！！！！！！！やるぞ！！！！！！！！！！！！！！！！！！！！！！！！！