スクラム始めて半年が経った

今年６月に現在のチームにjoinし、あっという間に半年が経ちました。
素晴らしいチームメンバーとユーザに恵まれ、充実したスクラムライフを送っています

もともとアジャイルやスクラムの経験はなく、書籍での知識しかありませんでした。
振り返ると、当初抱いていたイメージが大分変わったと感じます。

初心を忘れない為にも、感じたことを忘れないうちにメモしていきます。
「こんなことも知らなかったのか。。」と思う所もあるかもしれませんが、
私のようにこれからスクラムを始める方の参考になれば幸いです。

まだまだ勉強不足ゆえ、ご指摘等コメントいただけると嬉しいです

素敵だと思ったこと

スクラムマスターに依存しない

スクラムマスターはチーム全体を俯瞰し、理想的なスクラムの実施を促し、その支援に責任を持つ役割です（『正しいものを正しくつくる』より）。

一方、開発チームは成果物の完成に責任を持ちます。スクラムマスターが開発を手伝うということは基本的にありません。

スクラムマスターはあくまで「役職」であり、開発チームとはフラットな関係です。
ウォーターフォール開発でいうプロジェクトマネージャーやリーダーとは異なり、「奉仕的なリーダー（サーバントリーダー）」と表現されます。

スプリントが思うように進まないとき、それはスクラムマスターの責任ではなく
チーム全体の責任であることを理解することが大切です。

褒める文化

ふりかえりやデイリースクラムなどでお互いを褒めることで、
信頼関係を創りコミュニケーションが円滑に行われるようになります。

お互いを尊重し、感謝を伝えることは意識しないとなかなか実践できないかもしれません。

ふりかえりは確実に行う

スプリント毎にふりかえりの時間を確保し、メンバー全員でTryを考えます。
議論が長引いてしまう時も適当に切り上げることはせず、最後まで全員で頭を悩ませます。

良いTryが出なかったとしても、「ふりかえりが続けられていること」自体が重要です。
ふりかえりを定期的に行うことでスプリントのリズムを生み出し、フレッシュな気持ちで新しいスプリントに臨むことができているなと感じます。

ふりかえりのフレームワークは星の数ほどある

「ふりかえりカタログ」には71ものフレームワークが紹介されています。
面白そうなフレームワークを皆んなで選ぶのも楽しいです。

miroverseにもオリジナルのワークシートが
世界中から公開されています。個人的にハリーポッターが気になります↓

ふりかえりは「KPT」が最も有名ですが、初心者には少し難しいなと感じて書いた記事がこちら↓

意外だったこと

スプリントゴールの達成 ≠ バックログの完了条件の達成

各スプリントでは「スプリントゴール（スプリントで達成したいこと）」を定め、これに基づいてバックログを選択します。
そして、各バックログの「完了条件」は、開発チームが作業を開始できるレベルまでに明確化し、合意をとった上で決める必要があります。
「バックログの完了条件をこなしていけば、スプリントゴールが達成できる」段取りではありますが、実際はなかなかそう上手くいきません。。

作業を進める中で「この完了条件ではユーザーストーリーを達成できないのではないか？」という場合は、都度メンバーと相談し、完了条件を調整することも必要です。
目の前の完了条件だけでなく、一歩引いてスプリントゴールを意識することが大切です。

POのスクラム理解度が高くて柔軟な開発ができている

今回のスクラムチームでは、ユーザー企業側にプロダクトオーナー（PO）がいらっしゃいます。
（PO:バックログの整理やプロダクトの価値を高めることに責任を持つ役割）
プロダクト開発やスクラムについての知識はもちろん、開発チームと同じ目線に立っていただいています。
例えば、リファクタリングの重要性を理解した上で開発の提案したバックログを採用していただいたり。。

ウォーターフォール開発の場合、ユーザー側はリリースに間に合わせる為開発チームに発破をかけるなど、
ともすれば対立構造になりがちかと思います。
今回のようなユーザー=POのスクラム開発の場合、そうしたプレッシャーが無く、非常に開発のしやすい環境で感謝が止まりません。

横文字慣れるまで時間かかった

スクラムイベントは横文字が多いです。
スプリント、リファインメント、レトロスペクティブ、
ストーリーポイント、スクラムポーカー、、、
初めのうちは次から次へとやってくるイベントに付いていくのに必死でした。
私の場合は慣れるまで1~2か月かかりました。
各イベントの目的をしっかり理解して準備することが大切です。

アジャイルとはマインドである

「アジャイル」と「スクラム」は微妙に異なります。
アジャイルとは手法というよりマインドセット。
スクラムはその中の開発手法の１つで、他にも「XP」、「カンバン」などがあります。

アジャイルは「軽量、理解が容易、習得は非常に困難」と説明されるように、実践を通してその心を学んでいくことが重要です。

オンラインイベントやSNSで気軽にコミュニティに参加できる

Agile Japanは日本中にアジャイルの価値を浸透させ、日本の変革を促進することを目指すイベントです。
業種・業界を超えたアジャイルコミュニティも多くあり、勉強会に参加し気軽にアウトプットできるのも魅力です。界隈で有名とされている方々と気軽に繋がれて、共に日本のアジャイル文化を創っていける環境が広がっています。

https://connpass.com/
https://www.doorkeeper.jp/
Discord
Slack
Twitter
etc.

難しいと感じたこと

設計・テストがおろそかになりがち

プロダクトによってはスピード＞品質のトレードオフが求められます。
短い期間で設計～開発～テスト～リリースを繰り返すスクラムでは、リリース回数が増えれば当然バグが発生する可能性は上がります。また、詳細な設計ドキュメントは作成せず、手を動かしながら開発を進める場合もあります。

とはいえ、ある一定の品質は保証するべきです。
リリーススピードと品質を両立するためにも、下記スキルは非常に重要、、むしろ必須とも言えます。

テスト自動化(単体、E2E)
serverless
クラウド(AWS,Azure,,,)
コンテナ,Docker

属人化

スクラムチームにおける人数は3~10が推奨されており、少人数でコミュニケーションパスを減らすことが良いとされています。
また、アジャイルソフトウェア開発宣言に「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェア」とあるように、
プロダクトに関するドキュメント作成よりコミュニケーションが優先されると、属人化が起こりやすくなってしまいます。
メンバーのスキルの可視化には星取表の作成、ドキュメントも全員が更新しやすい方法を考えるなど工夫が必要です。

今後の目標！

認定スクラムマスター（CSM）研修
来年１月に受講予定です。体系的に学ぶことのできる良い機会なので、４日間の長丁場ですが
楽しみたいと思います。
社内の勉強会でアウトプットする
具体的なネタは未定ですが、、
自分の言葉で説明できること＝アジャイルマインドを習得している
ことにもなるので、年度内の開催を目指しています！

スクラム開発を半年やって感じたこと