こんにちはOptimal Bizチームの伊藤です。 直近のプロダクトで開発メンバー約20名を3つのスクラムチームに分け、同時に回すことでプロダクトを開発しています。
複数チームのスクラムにはLeSSやNexusなどのフレームワークがありますが、私たちのチームはそのようなノウハウもないまま「短い期間にどんどん人数が増えていく」というプロセスをたどりました。
このときにぶつかった問題やその対処方法をいくつか紹介したいと思います!
1. 複数のスクラムイベントに参加しなければならない人がでてくる
複数のチームのイベントに参加してしまう人がいると各チームのベロシティやリズムが崩れてしまいがちです。
しかし、私達のチームでは職能・スキルの関係でどうしても複数のスクラムチームにまたがっている人が存在してしまいました。 (実際にそういった現場も多いのではと思っています。)
対処: 所属を明確にし、スプリントのリズムを大切にする
対症療法ですが、このチームでは以下の方針で進めました。
- 最も必要とされるチームに所属していることにする
- そのチームのベロシティは多少崩れることを許容する
- 他チームのプランニングやレビューには必要に応じて、その人の判断で出てもらう
- それぞれのチームのリズムは崩さないようにする
- プランニングの日付やスプリントの単位など
複数のチームのイベントに出る人はどうしてもベロシティが安定しないと思いますが、ベロシティの安定を犠牲にして、各チームのリズムを大切にしています
2. スクラムを同期させるのが難しい
3つのチームが活動していると、それぞれのチームに異なるリズムが生まれてしまいました。 例えば、、、
スプリントの単位時間が違う
- チームAは1週間
- チームBは2週間
プランニングの日が違う
- 火曜日にプランニングするチーム
- 木曜日にプランニングするチーム
本来であれば、揃えたいのですが、複数のチームにまたがって作業している人がいる状態でプランニングの日付を揃えてしまうと、各チームのプランニングに必要な人が出られないことがあります。
対処: リズムは揃えないが、代表者のデイリースクラムで同期する
現在は以下のような方針でやりくりしています。
- チームから代表者を選出し、その人達のデイリースクラムで課題・状況を共有する
各チームのリズムは異なりますが、毎日代表者が集まることで、チーム間の横の連携が崩れないように注意しています。 特に、依存する機能を開発している場合などは代表者のデイリースクラムだけでなく他のチームメンバーとの連携も促すようにしています。
3. スプリントゴールのイメージが揃わない
スクラムごとのメンバーの職能・スキルセットが異なっているため、主に専任のQAがいるチームといないチームでスプリントのゴールイメージが変わってしまいました。
- 機能テストの完了をゴールとするチーム
- 試験環境にデプロイすることをゴールとするチーム
これではリリーススプリントや、後半のスプリントでバグが頻発するチームが出てきます。
対処: QAができるだけチーム横断的なストーリーの検証を行う
- QAはそのリリースで最も重要な箇所のチームに入ってもらう
- できるだけストーリーに沿った検証を行い、他のチームの成果物も含めたストーリーで検証する
- 開発チームのメンバーは可能な限りテスト工程を手伝い、リリーススプリントに持ち越さないよう努力する
結局は「気をつける」以上のことはできていませんが、普段コードを書く人も検証実施に参加することで新しい視点も得られてチームに良い影響があると考えています。
4. チーム間の依存関係
「Aチームのバックログに着手するにはBチームのAPIが必要・・・」のようなケースがよく発生しました。
本来であればチーム間の依存関係はできるだけ少なくするため、そのチームのバックログが他のチームのバックログに依存しないようなチーム分けをするべきかもしれません。
しかし、私達のチームでは所属しているメンバーの職能・スキル・人数バランスの関係で現在のチームを変更するのは適切でないと判断しました。
対処: バックログのリファインメントで依存関係を検知する
- できるだけ、プロダクト全体のリファインメントの段階でひろう
- 全体の設計がイメージできるプロダクトオーナーのスキルで拾ってバックログ化するときに検知する
- 依存するバックログが発生した場合はチーム代表者でのデイリースクラムで共有する
- いつまでに必要かを判断し、その場でバックログを並び替えることもある
- 本来、スプリント中のバックログを変更するのは良くないが、ここでは許容する
最後に
オプティムでは楽しみながらスクラムに挑戦するエンジニア、大規模スクラムを果敢に改善していくスクラムマスター・プロダクトオーナーを募集しています!