スクラム開発チームをLessでスケールさせた話/Scaling Scrum team with Less

by A1

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■チームを分割することになった背景 1スクラムチームを鍛え続けるのが理想ではあるが… • 肥大化していくプロダクトバックログ • この機能がないと契約できない…（顧客） • この機能がないと競合他社と勝負できない…（営業） • 問い合わせを減らしたいので機能を直して欲しい…（CS） • 潜在顧客にリーチするためこの機能を早く提供したい…（PO） 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■大規模スクラムの手法 • 「スクラムガイド」は1チームでの状況が中心に扱われてる • SAFe/DAD/Nexus/Scrum of Scrumsなど、スクラムをスケールさせる手法がある • その中でLessを採用した 11 5th State of Agile Reportより引用 https://stateofagile.com/

Slide 12

Slide 12 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■Lessを採用した理由 • 我々のチーム規模に丁度よかった • 1チームスクラムとの差分が少ない • 役割、成果物、プロセスの追加が殆どない • 元々スクラムをやっているのでメンバーの負担が少ないと考えた • 単純明快さに惚れた • 公式サイトの「調整と統合」が秀逸 12 上司に紹介されてこの本を読んでいて、実はかなり前から導入を密かに狙っていました。ちなみにScrumの本としても良書ですただ話す -------------------- チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。 https://less.works/jp/less/framework/coordination-and-integration

Slide 13

Slide 13 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■Lessとは • 「Less is Scrum」なので、スクラムの原理・原則はそのまま適用される。 • 経験主義、透明性、自己管理チームなど… • 10の原理原則、フレームワーク、ガイド、実験で構成されている • More with Less • 役割やプロセスは少なくしてもっと多くのものを得る • 2～8チームでの開発に対応している。 • それ以上の規模は「Less Huge」が対応している。 13

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■Lessのルール（スプリント） • 各チームのスプリントのサイクルは揃える • 各スプリントの終りにはコードを統合する • スプリントプランニングの1部は複数チームで行う • スプリントプランニングの2部は基本、チーム別で • 関連のあるものは集まって行う • デイリースクラムはチーム単位で行う • スプリントレビューは全体で1つ • ふりかえりはチーム単位で行った後に全体でも実施 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■分割の方針 • 1チーム5名～6名の2チームに分割 • 戦力が偏って不公平感が出ないように配慮 • チームごとの作業や知識の偏りは防ぎたい • 運用については同列。当番制で両チームが担当する • 各チームは「得意分野・デフォルト担当機能」を持つが、その他の機能開発も実施する 18 ベテランベテラン中堅若手若手新卒若手新卒ベテランベテラン中堅 SM

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■デイリースクラム（朝会） • 他チームの様子を知るために「偵察」を送り込むプラクティスを紹介したが… • メンバーの意見を聞いた結果、全員参加することに • 全体共有→Aチーム朝会→Bチーム朝会の流れ • 最近はZOOMで実施していて物理的な制約がなく、短時間で済んでいるので2チームの間はこのスタイルで良いと思っている • 他のチームの話に割って入ってもOK • 「気になったことはどんどん質問しよう」と明確に言っている • チーム間の認識齟齬などは早い段階で発見したい狙い 24

Slide 25

Slide 25 text

Slide 26

Slide 26 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■スプリントレトロスペクティブ(ふりかえり) • 現在はMiroで実施している • 1チームスクラム時代にある程度慣れているのでやり方は任せている • ファシリテーターは持ち回り • KPTなど、手法はファシリテータが決めている • 大抵は下記の流れでやっている 26 1. チェックイン（ルールの確認など） 2. スプリント期間内の事実確認 1. 運用や障害対応はどれぐらいあった？ 2. 割り込みはどれぐらいあった？ 3. （片方のチームは）感謝を伝える 3. 付箋に記入 4. 話し合うものを投票で決める 5. 話し合い 6. ふりかえりのふりかえり

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■悩ましいところ • リーダを置くことのジレンマ • スクラム的にはリーダーという役割はない • スクラムチームが9人までというのはリーダーなしの限界が 9人だから（らしい） • 元々ある問題だったが、2チームになり調整ごとが増え、より顕著に • 経験年数、性格によってはリーダに頼りたい様子 • 今の自分達には、「リード役」がいないと難しいという事実を受け止め一旦はリーダーありの状態を許容している • 壁打ち相手になって「いいじゃない」という感じにしたい • 「決めて下さい」のような会話が多くないかは注視する 30

Slide 31

Slide 31 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■悩ましいところ • PO が実質Proxy 問題 • 現状はビジネス側のステークホルダーの意向をPOが確認していて一人の POという原則を守れていないのが課題 • プロダクトオーナーなのかプロジェクトマネージャなのか • POがプロジェクトマネージャ的な役割も一部担っている現状はこれで前に進むしかないが、POの仕事に集中することでスピード感アップしたい 31 事業部長製品企画 PO 開発組織ビジネス側優先順位や要件を確認

Slide 32

Slide 32 text

Slide 33

Slide 33 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■悩ましいところ • インフラがチームに入っていない • 情報格差や受け渡しのコストが掛かりやすい • 現状は同じチームに入れることは難しいので情報共有を小まめにやり、お互いの領域をカバーし合うしかない • デザイナーもチームに入っていない • プレゼンテーションナルなコンポーネントをStorybookに切り出して作業分担しやすいようにトライ 33

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

©2021 RAKUS Co., Ltd. #RAKUSMeetup  あ ■まとめ • 大きなギャップもなく2チーム制に移行できている • 2チームになったことで情報の受け渡しなどのオーバーヘッドが増えたことは間違いないが、必要なコストの範囲 • 3～4チームになると別の課題が出るとは思うが今の延長で行けそうな感触 • スクラムが出来ていればLessはやりやすい • 他の大規模スクラムのフレームワークと比べてLessは導入しやすい（と思う） 36

Slide 37

Slide 37 text