チームでスクラムをはじめた1年のふりかえり

スクラムを導入してどうだったかを振り返ってみようと思います。

スクラム以前

長いこと同じプロダクトの開発に関わっていますが、マネジメント手法は都度見直し改善を行なってきました。

• WBS管理による管理

  • リリースまでの3〜4ヶ月のWBSを引いていた
  • 見積もりするのはチームリーダー（+コアメンバー）
  • WBSを見ながら朝会で進捗報告
  • 機能ごとに担当者がアサインされ数週間から数ヶ月その機能を開発していくので他の担当者の作業はあまり分かっていない

• WBSの改善
  途中で開発する機能が増減することも多いですし、そもそも長い期間の正確な見積もりは難しい上に労力にも見合わないので、直近の2週間だけ詳細な計画をたて、それ以降は粗い計画にとどめておく手法に切り替えました。
  この頃から将来的にスクラムをすることを意識していました。

• カンバンで「見える化」
  WBSに記載がない割り込みタスクが多く状況が見えづらい問題を解消するために、カンバンのプラクティスを導入して「見える化」を行いました。
  同時にWIPの数が可視化されることで作業が特定の人に集中していることも可視化され改善されました。

なぜアジャイル開発なのか

アジャイルでなければ解決できないものばかりではありませんし、やり方が悪いだけだろと言われたらそれまでですが、抱えていた課題感とアジャイルがマッチしていると感じて導入しました。

• 属人化・他の人が何やっているか分からない

  • 今まではとにかく終わらせることを重視し過ぎていたと思っていて、得意な人に得意なところを担当させるアサインをしていた。短期的に見るとそれでも成果が出るので表面上は問題ないように見えるが、長期的には他の人からはブラックボックスな機能が増えるし他のメンバーが何をやってるか分からないのが問題であった。

• 優先度の高いものから開発していない

  • 3〜４ヶ月スパンで開発していると必ず開発スコープの変更が入ります。優先度順には作業していないので途中での優先度の高い要望の追加は開発期間に収まらない傾向がある

• フィードバックを受けるタイミングが遅い

  • すべての機能を結合テストした後、まとめてステークホルダーへ確認依頼を出していました。そのタイミングでフィードバックをもらっても対応する時間もなく「今更そんな変更無理」みたいな状況になりがちでした。
    幸いリリースができない程の認識齟齬を起こしたことはありませんが、爆弾を抱えていたと思います。
    そこで、出来上がった単位にレビュー依頼をあげる試みをしてみましたがうまく根付かせることができていなかった。

• 開発にリズムがない

  • 長いスパンで作業していると、今進んでいるのか遅れているのかが分かりにくいし、ゆっくりとマージンを食いつぶしていってることがありました。

• ドキュメントによる意思疎通はコストがかかる割に効果が低いと感じている

よく誤解されてますがアジャイルと言っても開発速度が速くなる訳ではないのでそれは目的には入ってません。
動くものを早く見せられるという部分がアジャイルなのかと思っています。

スクラムを導入してやったこと

導入期

「Scrum Boot Camp The Book」をチーム全員に読んでもらい、スクラムに対する基本的な理解を持ってもらいました。

最初の数スプリントは、今までのWFの「工程」に基づいたタスクはそのままにイテレーションの部分だけで導入しました。
いきなり全てのプラクティスを無理に導入して拒否反応を持たれるよりは、やりやすいところから導入してよかったと思っています。

体制

• プロダクトオーナー
  • 開発マネージャー
• スクラムマスター
  • 私です
• スクラムチーム
  • 8人のメンバーで構成
• ステークホルダー
  • 社内の企画・サポートの人たち

デイリースクラム

ファシリテーターは開発チーム全員でローテーションで回しています。
うちのチームは朝夕で2回行なっています。
マイクロマネジメントしたい訳じゃなくて単純にコミュニケーションの回数を増やすことが目的です。
いつもデイリースクラムが長引くことはなく5分ぐらいで終わっているので2回やっても負担にならない間は良いのかなと思ってます。

スプリント

水曜日はじまり火曜日おわりの1週間でやっています。
よくやられていると思いますが日本は月曜日の祝日が多いので安定して実施できる水曜日をはじまりとしています。
スプリント期間が1週間だと短いと言われることもありますが、最初は1週間でも正確な計画を立てるのが難しいので1週間スプリントが1番難易度が低いと思っています。
あるアジャイルコーチに聞いた話、練習すれば1週間は正確に見積もれるようになるし、それができれば2、3ヶ月は見積もれるようになるそうです。
現に、うちのチームも最初は過小見積もりをしてしまうことが多かったですが、繰り返すこと見積もりの精度は向上してきていますので同じ長さのタイムボックスで見積もりを繰り返して行うのは非常に効果的だと感じています。

ある意味毎週締め切りが来るので、余裕がない計画を立てて疲弊してしまわないように気をつけています。

スプリントプランニング

２部構成で行なっています。1部で今週実現するユーザストーリーとデモについてPOと合意し、2部はPOは退席して開発チームでプラニングをします。
ユーザストリーから作業見積もりは開発チームが行います。
ホワイトボードに書きながら会話をすることで、チーム内で共通理解を作っていくのですが、これがすごい重要だと思っていて、チーム内の知識の偏りが平準化される効果もあります。（PBLリファインメントでやるのが良い気がしますが現在うちのチームはこのタイミングでやっています）
リーダーがタスクにアサインすることはありません、自分で担当するタスクを決めます。

スプリントレビュー

今まで完成したものを見せることに慣れているチームが、未完成なものを見せることには抵抗があったと思います。
理想は毎週ステークホルダーに動くことを見せることですが、なかなか難しくスキップすることも多かったですが、
よろしい状況ではないので、少なくともプロダクトオーナーへのレビューはするようにしています。

スプリントレトロスペクティブ

毎週必ず実施することで問題の可視化と高速な改善サイクルを回します。
その週の良かったこと悪かったことならすぐ思い出せますし不満を溜め込むことも少なくなると思っています。
生真面目に挙がった問題を全て対応しようとすると無力感や閉塞感が生まれてしまうので、必ずしもすべて対応する必要はないことをスクラムマスターとしては強調して開発チームに伝えるようにしています。
そのためにKPTAと言う手法を取り入れており、Tryは思いつくまま挙げるけどその中で本当に対応するべきものはActionとしてあげて改善するようにしています。

1週間に1つ問題を改善できたら自分たちを褒めるぐらいの感覚で良いと思います

KPTAはアジャイルコーチング読書会で@amapyonさんから頂いた本を参考にしました。この場を借りてありがとうございました。

• ダメふりかえりを撲滅する３つのヒント

見積もり

プロダクトバックログの見積もりは全員で実施しています。我々はこれを「見積もり大会」と呼んでいます。
やり方はGoogleスプレッドシートにみんなで同時に見積もりを記入して行っています。

見積もりに乖離が大きい場合は、見えているものが違うので会話することで認識のギャップを埋めていきます。

ペアワーク・モブワーク

必要に応じて実施することを推奨しています。
ちょっと慣れてない作業をすることきはペアで作業したり、
データモデルの設計など影響が大きい重要な作業をモブでワークすることで認識齟齬や手戻りを防ぐようにしています。

結果どうなったか

属人化・他の人が何やっているか分からない問題

優先度の高いものからチームで実装していく、ペアワークを取り入れることで少しずつ属人化が解消していっています。
お互いに何をやっているか分かりやすくなったし、タスクを皆で終わらせる意識が強まり、助けあいがしやすくなったと思っています。
スクラムとは関係ありませんが、今までは非エンジニアからの質問は詳しい人に直接されることも多かったですが、チャットに専用のチャンネルを設けてそちらに上げてもらうようしました。
回答する人を当番制にして、自分が詳しくない機能については自分で調べるか他のメンバーに聞いて回答することで、その人の知識になるようにしています。

優先度の高いものから開発していない問題

以前は、担当者のアサインの都合で作業順番を決めていたため、途中でスコープ追加が発生しても優先度の低い作業で工数を消化してしまっていますし先に書いた属人性の問題と相まり対応できないことがままありました。
優先度の高い作業から着手し少しずつ動くものを作っていくことが理にかなっていると思います。

フィードバックを受けるタイミングが遅い

スプリントごとにインクリメントを見てもらうチャンスがあるためフィードバックを早めにもらいやすくなってきたと思います。
そこでコメントをもらったことを次回のレビュー時に改善して見せることができるようになった。

開発にリズムがない問題

1週間というタイムボックスで作業することで、毎週自分たちで計画して終わらなかったことはふりかえり検証しますし、メリハリとリズムがついたと思います。

ドキュメントによる意思疎通はコストがかかる割に効果が低い

もちろん必要なドキュメントは作成しますが、今までは体裁で無駄なものを作っていることがあったと思います。
必要な物に絞ることで無駄を省けますし、意思疎通が目的であればドキュメントより対面のコミュニケーションの方がコストが低いし伝わりやすくなったと思っています。

他に良かったこと

対面のコミュニケーションが増えたことでチームの雰囲気が明るくなったし、やらされているのではなく自分ごととして作業してくれている様子が見られるようになりました。
スクラムはチームが自律的になるのを助ける良いプラクティスだと思います。

とはいえアジャイル開発は難しい

スクラムは軽量なプラクティスが故、理解は容易だが習得が難しいと言われていますがまさにその通りだと実感していて、アジャイル関連の本を読み漁りましたし、勉強会に参加して社外の方とたくさんの会話をして模索し続けた一年でした。

思えばウォーターフォール開発では1つ1つのプラクティスの意味を深く考えたことはなかった気がします。

アジャイルは開発プロセスではないですし、不確実なものに向き合うため考えたり学んだりすることが大事なんだろうと思います。

さいごに

先月、2日間の研修に行かせてもらって認定スクラムマスターを取得しました。

研修ですごく良い話を沢山聞いてきたのでチームと相談しながら自分たちが良いと思えるものは取り入れていきたいです。

アジャイルは手法ではなく価値観です。
Don't do Agile, Be Agile.を実践していきます。