tuneの日記

アジャイル開発、組織変革、マネージメント、ファシリテーションについて学んだことの記録

Re: 最高のScrumキメた後にスケールさせようとして混乱した話

www.slideshare.net

Regional Scrum Gathering Tokyo 2020の講演で「あの時こうしておけばよかった」という考えを教えて欲しいと講演で話されていたので自分の考えをまとめました。

事例・講演の概要

1チームスクラムでモバイルアプリの開発を行い、顧客の信頼を得てプロダクト開発は成功した。そこで顧客から運用・データ分析含め3チームをすべてスクラム開発へ移行したいという要望が出た。 スクラムマスターでアジャイルコーチの藤村さんは機能開発と運用のチームを合わせた15人1チームスクラムを行い、慣れたところでチーム分割を行いScrum of Scrumを行おうとした。 結果はチームは機能せず、元に近い形に戻すことになった。

私ならこうする

チームを混ぜた上で最初からチームを分割する。

チームの人数が多すぎると協力を引き出すことが難しいです。経験的には5〜7人が良さそうで、9人を超えるとチーム内からコミュニケーションの不満が出ます。 ミーティングが長い、誰が何をやっているのか分からない、開発効率が悪いというコメントがふりかえりで出てきたら分割の時期だと思っています。

チーム分割はメンバー同士の話し合いに委ねるやり方もありますが、私はメンバーが備えるスキルセット、性格などを考慮して慎重に決めています。

機能開発と運用が分かれているのは悪手

チームを分割するときは機能開発と運用のメンバーを均等に2チームに分け、運用チームそのものをなくします。 運用チームは負債を返し続けるだけのチームなので雰囲気は自然と悪くなりがちです。 また機能開発チームも自分たちの作った負債にきちんと向き合わせないといいアーキテクチャ・メンテナンスしやすいコード・運用しやすいシステムは得られないでしょう。

複数プロダクトオーナーがいる場合はチームを組んでもらう。

PO同士が話し合って優先順位を決めるのは難しいと思っています。 とはいえ代表者1人を決めることも難しいのであれば、チームを組んでもらいチームとして要望を出すことを依頼します。

いきなりLeSSを入れる。

上記を遵守しているとLeSSに限りなく近い形になります。なので人数が増えてチームを分ける必要があるだけならLeSSが1番労力が低いです。 LeSSをやるとチーム・ステークホルダーに言わなくても、スクラムイベントを2チーム同じ場所で一緒にやるだけでも効果が見込めます。

パフォーマンスが落ちることをチームメンバー、ステークホルダー全員に繰り返し伝える。

当たり前ですが人が増え、やり方が変わると学びや試行錯誤が必要なのでパフォーマンスが落ちます。 スケールを希望するステークホルダーにはこのことを十分に理解してもらう必要があります。 自分の場合2〜4スプリントかかることを織り込んでおり、これでも改善の見込みがなければやり方がまずいと考えなんらかの手をうちに行きます。

少しずつ増やす

メンバーの1/3が新しく入るのがギリギリ、1/2になるとうまくいくかどうかは賭けだと思っています。 増やす時は数だけでなく、業務の性質(toC/toB、リリース間隔、スキルセット)、メンバーの性格(前向きに新しいことに取り組む、分からないことを聞くことを恐れない)をかなりよく考えて決めるとよいです。

チーム数を増やすときは下記にそれぞれ壁があるのでメンバー・ステークホルダーと事前に話しておくと良いです。

  • 1→2 : スケールの最小限。チームが対等にコミュニケーションを取り、タスクをこなせるか。
  • 2→3〜8 : 1人のプロダクトオーナーの目が届く限界。チームが自律的に必要なコミュニケーションを取り、タスクをこなせるか。
  • 8→N : 責任者が全員の顔を覚えられなくなるであろう限界。プロダクトオーナーも複数人で責務を分担する必要がある。

組織を見ることは悪いことではない。

反省に含まれていましたが、私は悪いことではないと思っています。 単一チームのことをいつまでも気にかけることはできず、2人目を見出し、育てて任せないといけないはずです。

いいスモールチームであっても自律的に連携しない

複数のスクラムチームを育てることと、それらが連携して1つの成果を出せるかは別問題であり、その解決のためにスケーリングアジャイルフレームワークが存在していると認識しています。なのでチーム同士のコミュニケーションを律するなんらかの仕組みは必要だと思います。

おわりに

f:id:tune:20200112085831p:plain

しくじりの反省としてでていた上記スライドですが、よく読むとスケールすることのメリットはちゃんと出ています。

  • プロジェクト全体の俯瞰
  • 作業の分担、余裕
  • 属人化の解消、ペアプロ・モブプロ

今回はしくじり事例とのことでしたが、ぜひまたスケーリングにチャレンジして学びを共有して欲しいです。 今年もアジャイルのスケーリング一緒に悩んでいきましょう!