価値提供のリードタイムを短くするための戦術としてのチーム替え「流動チーム体制」に取り組んでいたら実はLeSSでのモブだったお話 / Our way of Dynamic Reteaming was just a "mob" of LeSS

by nako418

Slide 1

Slide 1 text

-:$PSQPSBUJPO 価値提供のリードタイムを短くするための戦術としてのチーム替え「流動チーム体制」に取り組んでいたら実はLeSSでのモブプロだったお話 LINEヤフー株式会社中井菜⼦新⽥了仁 @RSGT2024

Slide 2

Slide 2 text

Slide 3

Slide 3 text

-:$PSQPSBUJPO ⾃⼰紹介中井菜⼦ / Saiko Nakai（@nako418） LINEヤフー株式会社 2018年4⽉〜プロダクトオーナーとしてスクラムに関わりはじめる 2020年7⽉〜とある社内プロダクトたちのプロダクトオーナー新⽥了仁 / Akinori Nitta LINEヤフー株式会社 2018年4⽉〜新卒⼊社 2018年10⽉〜とある社内プロダクトチームに開発者として参加

Slide 4

Slide 4 text

-:$PSQPSBUJPO • わたしたちのチームの状況と、その課題を解決するための戦術「流動チーム体制」 • 「流動チーム体制」誕⽣の背景となった取り組み • 戦術を編み出して実現するまでと、実際に試してみた結果 • プロダクトオーナーと開発者それぞれの⽴場で考えていたこと • 取り組みや、プロダクト、チームの状況をそれぞれどう捉えていたのか • わたしたち流の Dynamic Reteaming がうまくいったワケ今⽇のおはなし

Slide 5

Slide 5 text

-:$PSQPSBUJPO • Reteamingは良いぞというお話 • あくまでも⼀つの⼿段と捉えているので、これを推奨したいというお話ではない • 昨年のRSGTでお話した運⽤とスクラムの続き • 運⽤⾃体はなくならないので、昨年のお話はそのまま今回のお話の仕組みの中でも⽣き続けています今⽇おはなししないこと

Slide 6

Slide 6 text

-:$PSQPSBUJPO • エピック • プロダクトとして解決したい課題のうち、単体のバックログアイテムでは解決できない粒度のもの • 複数のバックログアイテムによって構成される価値提供の単位⾔葉の説明バックログアイテム価値提供の単位 = エピック価値提供の単位 = エピック

Slide 7

Slide 7 text

-:$PSQPSBUJPO 1. はじめに 2. 成⻑したLeSSチームが抱えていた課題 3. 「流動チーム体制」 4. 「流動チーム体制」をふりかえる 5. まとめもくじ

Slide 8

Slide 8 text

-:$PSQPSBUJPO 1. はじめにわたしたちのチームとプロダクトの状況

Slide 9

Slide 9 text

-:$PSQPSBUJPO • LeSSチームとして3年間プロダクト開発 • プロダクトオーナー1⼈、スクラムマスター1⼈、3つの開発チームで構成 • 新旧２つのプロダクトを担当わたしたちのチームとプロダクト新プロダクト旧プロダクト移⾏中衰退期の後半利⽤者はまだまだ多いので保守運⽤はサボれない成⻑期真っ只中旧プロダクトからの移⾏が進み利⽤者は急増中

Slide 10

Slide 10 text

-:$PSQPSBUJPO • プロダクトの課題が増え続ける • 旧プロダクトから新プロダクトへの移⾏のために必要な開発 • ステークホルダーからの要求の増加 • ⽇々の運⽤業務の増加 • 技術的負債の返済 • ⼀つのエピックが完了するのに時間がかかる • ⼤きなエピックを複数の開発チームで順に開発すると⼿戻りが発⽣しやすい • 複数の課題に同時に取り組んでしまい、インクリメントを作るリードタイムが⼤きくなる • どの課題もなかなか解決できず、期末に駆け込むわたしたちのチームで起きていたこと

Slide 11

Slide 11 text

-:$PSQPSBUJPO わたしたちのチームで起きていたことエピックがなかなか終わらない。もっと細かくプロダクトの価値提供がしたいけどできていない。難産な案件が多くてつらい。来期の後半には⼤きな案件があるし、もっと⼤変になることわかっているのにどうしたらいいの・・︕︖ っていうか期末に駆け込んでいる状況ってアジャイルじゃないし︕ 開発チームをまたいでアイテムを引き継ぐの⼤変だな。連携するのに複雑になっているな。折⾓、優秀なメンバーが集まっているのに、うまく価値提供につながらないの勿体無いな。

Slide 12

Slide 12 text

-:$PSQPSBUJPO もっと継続的に価値提供をし続けたい写真︓Rowen Smith on Unsplash

Slide 13

Slide 13 text

-:$PSQPSBUJPO 「流動チーム体制」の導⼊により解決を狙った写真︓Riccardo Annandale on Unsplash

Slide 14

Slide 14 text

-:$PSQPSBUJPO 「流動チーム体制」という⼤胆な施策を選択する上で、そもそも「流動チーム体制」がどういう経緯で⽣まれ、どんなことをやったのか。そのきっかけとなった施策を⾏った約1年前に遡る

Slide 15

Slide 15 text

-:$PSQPSBUJPO 2. 成⻑したLeSSチームが抱えていた課題「流動チーム体制」の前⾝の取り組み

Slide 16

Slide 16 text

-:$PSQPSBUJPO • 開発メンバーのLeSSの熟練度 • 守破離で例えると「破」 • 開発メンバー同⼠の関係性 • 協⼒と相互のサポートが重要性を経験から体感している • 楽しく価値のある仕事をしたい • ユーザへプロダクトが提供する価値を⾼めたい • メンバー個⼈としてもスキルアップもしたい • 結果にもこだわりたい • 余裕のあるチームでありたい開発メンバーが考えていること開発メンバー

Slide 17

Slide 17 text

-:$PSQPSBUJPO 開発メンバー写真︓Raphael Rychetsky on Unsplash 2022年9⽉ビッグイシューを解決したい旧プロダクトの規模、LeSSチームの規模も⼤きくなったな今期はチームのさらなる成⻑と結果のためにも、ビッグイシューを解決したいな旧プロダクトで保守運⽤コストが増加している。解消するには、抜本的な改修が必要そう。今期のビッグイシューはこれになりそうだ。

Slide 18

Slide 18 text

-:$PSQPSBUJPO 開発メンバー写真︓Raphael Rychetsky on Unsplash 2022年9⽉ビッグイシューを解決したい旧プロダクトで保守運⽤コストが増加している。解消するには、抜本的な改修が必要そう。今期のビッグイシューはこれになりそうだ。今期はチームのさらなる成⻑と結果のためにも、ビッグイシューを解決したいな旧プロダクトの規模、LeSSチームの規模も⼤きくなったな

Slide 19

Slide 19 text

-:$PSQPSBUJPO 「イシューからはじめよ」より、イシューとは。 A. 2つ以上の集団の間で決着のついていない問題 B. 根本に関わる、もしくは⽩⿊がはっきりしない問題イシューとは

Slide 20

Slide 20 text

-:$PSQPSBUJPO 価値のある仕事は、「イシュー度」と「解の質」の両⽅が⾼い必要がある。 - 「イシュー度」 - ⾃分の置かれた局⾯でこの問題に答えを出す必要の⾼さ - 「解の質」 - そのイシューに対して、どこまで明確に答えを出せているか価値のある仕事とはイシュー度解の質⾼⾼低低価値のある仕事イシューの⾒極め解の磨き込み

Slide 21

Slide 21 text

-:$PSQPSBUJPO 「ビッグイシュー」: 「イシュー度」が⾼く、解の質次第で⼤きく価値のある仕事になる問題。メリット︓ - 問題の答えを出すことで、抜本的な解決が狙える - 周辺の⽐較的に⼩さい課題もまとめて解決できるデメリット︓ - 今まで解いていないイシューのため、実現難易度は⾼いことが多い（技術⾯・作業コスト⾯が⾼い）ビッグイシューとはイシュー度解の質⾼⾼低低価値のある仕事ビッグイシューイシューの⾒極め

Slide 22

Slide 22 text

Slide 23

Slide 23 text

-:$PSQPSBUJPO LeSSチーム開発メンバー写真︓Huzeyfe Turan on Unsplash チームメンバーが⽴て続けに3⼈卒業 2022年11⽉

Slide 24

Slide 24 text

-:$PSQPSBUJPO LeSSチーム開発メンバー写真︓Huzeyfe Turan on Unsplash チームメンバーが⽴て続けに3⼈卒業 2022年11⽉このままでは、ビッグイシューにコミットできない︖

Slide 25

Slide 25 text

-:$PSQPSBUJPO • メンバー卒業により起こったこと • 旧プロダクトの知⾒を持っているメンバーが減ってしまった • メンバー卒業による懸念点 • 着⼿できるメンバーが減ることで開発チームをまたいで品質を担保する必要が出てきた。 • アイテムの優先度が⾼い状態でも、各開発チームでは完了できないため、着⼿できない。ビッグイシューにコミットできないこのままでは、ビッグイシューにコミットできない︖

Slide 26

Slide 26 text

-:$PSQPSBUJPO 旧プロダクトのスキルセットを持っているメンバー旧プロダクトの知⾒を持っているメンバーが減ってしまったメンバー卒業により起こったこと旧プロダクトの知⾒を持っているメンバーが減ってしまった 3⼈ 3⼈ 2⼈

Slide 27

Slide 27 text

-:$PSQPSBUJPO 開発チームまたぎで品質を担保する必要が出てきた着⼿可能ビッグイシュービッグイシューメンバー卒業による懸念点１ビッグイシューは技術⾯・作業コスト⾯が⾼いが、各開発チームで着⼿できる予定だった。

Slide 28

Slide 28 text

-:$PSQPSBUJPO 開発チームまたぎで品質を担保する必要が出てきたメンバー卒業による懸念点１ビッグイシューは技術⾯・作業コスト⾯が⾼いが、各開発チームで着⼿できる予定だった。着⼿できるメンバーが減ることで、開発チームをまたいで品質を担保する必要が出てきた。レビューするチームはプランニングに参加していないので、レビューコストが予測不能。ビッグイシュービッグイシュー情報量が多すぎて、レビューが⼤変考慮もれがあるから、ちゃぶ台返しレビューお願いします着⼿可能だけど、品質に⾃信がないから別チームにもレビューを貰おう予期しないコストで、着⼿アイテムが未完に

Slide 29

Slide 29 text

-:$PSQPSBUJPO アイテムの優先度が⾼い状態でも着⼿できないメンバー卒業による懸念点２各開発チームで⾃分たちのチームが、⾃分たちのスプリントのバックログアイテムを完了させることにコミットしていた。ビッグイシューは技術⾯・作業コスト⾯が⾼いため、着⼿できるメンバーが減ることで、アイテムの優先度が⾼い状態でも着⼿できない。着⼿不可ビッグイシュー着⼿不可着⼿不可

Slide 30

Slide 30 text

-:$PSQPSBUJPO ビッグイシューにコミットできるような仕組みを追加この状態は、LeSSチームとしてビッグイシューにコミットできていないのでは︖ 着⼿不可ビッグイシュー着⼿不可着⼿不可

Slide 31

Slide 31 text

-:$PSQPSBUJPO ビッグイシューにコミットできるような仕組みを追加着⼿不可ビッグイシュー着⼿不可着⼿不可この状態は、LeSSチームとしてビッグイシューにコミットできていないのでは︖ LeSSチームとしてビッグイシューにコミットできる状態になるように、チームメンバーの配置を変えれば、コミットできる良いのではビッグイシュービックイシュー着⼿可能︕

Slide 32

Slide 32 text

-:$PSQPSBUJPO LeSSチームとしてビッグイシューにコミットしたい START やったこと「スプリント中に次のスプリントの作戦会議を⾏う」

Slide 33

Slide 33 text

-:$PSQPSBUJPO LeSSチームとしてビッグイシューにコミットしたい START やったこと「スプリント中に次のスプリントの作戦会議を⾏う」具体的には • 現在のスプリントの状況を共有現在のスプリントの進捗 Goal 現在のスプリントの進捗

Slide 34

Slide 34 text

-:$PSQPSBUJPO 次のスプリントに何をするのか認識合わせ LeSSチームとしてビッグイシューにコミットしたい Goal 次のスプリントの⽬標やったこと「スプリント中に次のスプリントの作戦会議を⾏う」具体的には • 現在のスプリントの状況を共有 • 次のスプリントでどのようなことを実施するのか確認

Slide 35

Slide 35 text

-:$PSQPSBUJPO 最終的な結果 LeSSチームとしてビッグイシューにコミットしたい Xの技術に詳しいメンバーが、あと⼀⼈いればコミットできる Xの技術わかるので、ヘルプ⼊るよ次のスプリントこれなら、コミットできるやったこと「スプリント中に次のスプリントの作戦会議を⾏う」具体的には • 現在のスプリントの状況を共有 • 次のスプリントでどのようなことを実施するのか確認 • 着⼿する開発チームを決めて、対象の開発チームが、コミットできるような状態になるために話し合い、移動するメンバーを決める Goal 次のスプリントの⽬標

Slide 36

Slide 36 text

-:$PSQPSBUJPO 36 写真︓NASA on Unsplash 取り組みの結果

Slide 37

Slide 37 text

-:$PSQPSBUJPO (poem)かっこいい写真のうえに、「皆の尽⼒でビッグイシューを解決」を配置したい皆の尽⼒でビッグイシューを解決写真︓NASA on Unsplash メンバーの尽⼒でビッグイシューを解決

Slide 38

Slide 38 text

-:$PSQPSBUJPO ポジティブ • 毎スプリント、チームメンバー全員で作戦会議をするため、共通認識を持ちやすくなった。 • どのようにしてビッグイシューを解決するのか • 現在の状況はどうなっているのか • 次のスプリントはどのようにすれば、 LeSSチームとしてコミットできるのか • バックログアイテムを完了させることよりも、いかに価値を出すために前進させるかの議論ができた • 必要なスキルセットを持つメンバーでプランニングに臨むため、考慮漏れが起きにくくなった • 必要なスキルセットを持つメンバーで1スプリントをこなすため、1チーム内でレビューが収まりやすくなったネガティブ • 会議体が増えた • 次スプリントの予定を事前にまとめるなどの、事前準備によってやることが増えた取り組みの効果

Slide 39

Slide 39 text

-:$PSQPSBUJPO 前⾝の取り組みを図⽰⽬指したい状態制約条件戦術⼈プロダクトイシュー環境チーム何をどう変えると⽬指したい状態にできるかを考えるビッグイシュー 3⼈卒業ビッグイシューにコミットしたいチームメンバーが 3⼈卒業 LeSSチームとしてコミットできるように⼈を移動させる

Slide 40

Slide 40 text

-:$PSQPSBUJPO パターン化⽬指したい状態制約条件戦術何をどう変えると⽬指したい状態にできるかを考える XXX YYY XXX ? YYY ⼈プロダクトイシュー環境チーム

Slide 41

Slide 41 text

-:$PSQPSBUJPO • プロダクトが置かれる状況 • 期の後半にビッグイシューが控えている • 旧プロダクトから新プロダクトへの移⾏が本格化し、発⽣する課題への対応バックログが増えるこのさき訪れるプロダクトとチームの状況ビッグイシュービッグイシュー ︙ ︙ 期の後半期のはじめビッグイシューに着⼿可能になる移⾏が本格化課題課題

Slide 42

Slide 42 text

-:$PSQPSBUJPO • プロダクトが置かれる状況 • 期の後半にビッグイシューが控えている • 旧プロダクトから新プロダクトへの移⾏が本格化し、発⽣する課題への対応バックログが増える • チームが置かれる状況 • 期の後半には新卒やインターンが来て育成コストがかかるこのさき訪れるプロダクトとチームの状況ビッグイシュービッグイシュー ︙ ︙ 期の後半期のはじめビッグイシューに着⼿可能になる移⾏が本格化課題課題

Slide 43

Slide 43 text

Slide 44

Slide 44 text

-:$PSQPSBUJPO パターンにあてはめる⽬指したい状態制約条件戦術何をどう変えると⽬指したい状態にできるかを考えるプロダクトの価値提供をし続けたい後半にビッグイシューがある⼈の増減により育成コストが増える継続的な価値提供ビッグイシュー育成コスト ? ⼈プロダクトイシュー環境チーム

Slide 45

Slide 45 text

-:$PSQPSBUJPO パターンにあてはめる⽬指したい状態制約条件戦術何をどう変えると⽬指したい状態にできるかを考えるプロダクトの価値提供をし続けたい後半にビッグイシューがある⼈の増減により育成コストが増える継続的な価値提供ビッグイシュー育成コスト流動チーム体制⼈プロダクトイシュー環境チーム

Slide 46

Slide 46 text

-:$PSQPSBUJPO 3.「流動チーム体制」導⼊によって得られたこと

Slide 47

Slide 47 text

-:$PSQPSBUJPO 「流動チーム体制」とは

Slide 48

Slide 48 text

-:$PSQPSBUJPO 価値提供のリードタイムを短くするための戦術写真︓JESHOOTS.COM on Unsplash

Slide 49

Slide 49 text

-:$PSQPSBUJPO • LeSSチーム • プロダクトオーナー、スクラムマスター、複数の開発チーム • 流動チーム体制 • LeSSの構成はそのままに、開発チームのメンバーを毎スプリント⼊れ替える「流動チーム体制」とはスプリントN スプリントN+1

Slide 50

Slide 50 text

-:$PSQPSBUJPO • 3種類のチームをつくる • 注⼒チーム • 注⼒対象のエピックに取り組み、その課題を解決することに注⼒するチーム • Opsチーム • 運⽤業務全般を請け負いながら、チームの運⽤の質を上げていくチーム • PBIチーム • 注⼒対象のエピック以外のバックログアイテムを進めるチーム「流動チーム体制」とは注⼒対象のエピックに関するアイテム（注⼒対象になったタイミングで注⼒チームが着⼿する）注⼒対象のエピック以外のアイテム（PBIチームが着⼿する）エピック1 エピック2 エピック3 バックログ全体

Slide 51

Slide 51 text

Slide 52

Slide 52 text

-:$PSQPSBUJPO • 注⼒対象のエピックに関するアイテムは優先順が⼀番⾼い位置に配置 • 将来的には注⼒対象のエピックとして取り組むエピックに関するアイテムは優先順を低くする • いまは着⼿しない判断をしているため、優先順が低い • 注⼒対象のエピック以外のアイテムや運⽤保守関連のアイテムは優先順に配置バックログの扱い⽅注⼒対象のエピックに関するアイテムそれぞれの注⼒チームのスプリントバックログに⼊る注⼒対象のエピック以外のアイテムや保守運⽤関連のアイテム主にPBIチームのスプリントバックログに⼊る将来的に注⼒対象のエピックとして取り組むアイテム優先順は低いので着⼿されない注⼒対象エピック1のアイテム注⼒対象エピック2のアイテム注⼒対象エピック2のアイテム注⼒対象エピック1のアイテム注⼒対象エピック1のアイテムバックログ注⼒対象エピック3のアイテム注⼒対象エピック3のアイテム ︙

Slide 53

Slide 53 text

-:$PSQPSBUJPO • 注⼒対象のエピックに関するアイテムは優先順が⼀番⾼い位置に配置 • 将来的には注⼒対象のエピックとして取り組むエピックに関するアイテムは優先順を低くする • いまは着⼿しない判断をしているため、優先順が低い • 注⼒対象のエピック以外のアイテムや運⽤保守関連のアイテムは優先順に配置バックログの扱い⽅注⼒対象エピック1のアイテム注⼒対象エピック2のアイテム注⼒対象エピック2のアイテム注⼒対象エピック1のアイテム注⼒対象エピック1のアイテムバックログ注⼒対象エピック3のアイテム注⼒対象エピック3のアイテム ︙ 注⼒対象エピック1のアイテム注⼒対象エピック2のアイテム注⼒対象エピック2のアイテム注⼒対象エピック1のアイテム注⼒対象エピック1のアイテム注⼒1チーム注⼒2チーム PBIチームスプリント

Slide 54

Slide 54 text

-:$PSQPSBUJPO 1週間（1スプリント）のスケジュールセレモニーデー（⽔曜⽇） 1⽇⽬（⽊曜⽇） 2⽇⽬（⾦曜⽇） 3⽇⽬（⽉曜⽇） 4⽇⽬（⽕曜⽇）セレモニーデー（⽔曜⽇）スプリントプランニングリファインメントリファインメントスプリントレビューチームレトロスペクティブ全体レトロスペクティブ

Slide 55

Slide 55 text

-:$PSQPSBUJPO 1週間（1スプリント）のスケジュールセレモニーデー（⽔曜⽇） 1⽇⽬（⽊曜⽇） 2⽇⽬（⾦曜⽇） 3⽇⽬（⽉曜⽇） 4⽇⽬（⽕曜⽇）セレモニーデー（⽔曜⽇）スプリントプランニングリファインメントリファインメントスプリントレビューチームレトロスペクティブ全体レトロスペクティブ「流動チーム体制」を実施するにあたって内容変更があったイベント

Slide 56

Slide 56 text

-:$PSQPSBUJPO 1週間（1スプリント）のスケジュールエピックリファインメントセレモニーデー（⽔曜⽇） 1⽇⽬（⽊曜⽇） 2⽇⽬（⾦曜⽇） 3⽇⽬（⽉曜⽇） 4⽇⽬（⽕曜⽇）セレモニーデー（⽔曜⽇）リファインメントリファインメントスプリントレビューチームレトロスペクティブ全体レトロスペクティブエピックリファインメント準備チーム編成「流動チーム体制」を実施するにあたって増えたイベントスプリントプランニング

Slide 57

Slide 57 text

Slide 58

Slide 58 text

-:$PSQPSBUJPO • 注⼒対象にするエピックはリファインメントの中で、チームメンバー全員で決める • 新しいエピックに注⼒しはじめる頃のリファインメントで次の注⼒対象を決める • エピックはたくさんあるが、優先順をつけて今注⼒するべきエピックを選択するリファインメントで注⼒対象のエピックを決める価値コスト⾼⾼低低エピックを完了させることによって提供できる価値とそれにかかる⼤まかなコストを元にプロットしながら優先順をつけた優先して注⼒対象にしたいエピック

Slide 59

Slide 59 text

-:$PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめたエピックリファインメントの準備

Slide 60

Slide 60 text

-:$PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめたエピックリファインメントの準備このときの作戦会議と同じことを実施している

Slide 61

Slide 61 text

-:$PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめたエピックリファインメントの準備・はじめは開発メンバーのみんな、エピックリファインメントは⼿探り状態。・注⼒チームのメンバーは解像度が⾼く、他のチームメンバーの解像度のズレが課題に。・スプリントを重ねる間に、引き継ぐための型が⽣まれたりと、意図や経験値の共有を意識して動けるようになった。

Slide 62

Slide 62 text

-:$PSQPSBUJPO • 注⼒チーム内でエピックを⾒直す時間 • エピックのゴールまでの道のりを確認し、次スプリントにやるべきことはなにか整理する • エピックリファインメントで、他の開発メンバーに対して説明ができるようにする • 開発メンバーが⾃主的に実施しはじめたエピックリファインメントの準備スクラムガイド記載のこれらをPOから開発チームに委譲できてありがたい・プロダクトバックログアイテムを作成し、明確に伝える。・プロダクトバックログアイテムを並び替える。・プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。

Slide 63

Slide 63 text

-:$PSQPSBUJPO • 注⼒対象のエピックを対象としたリファインメント • 注⼒チームが次のスプリントでエピックのゴールに近づくための⼤まかな計画を⽴てる • そのためにどれくらいの⼈数/スキルセットが必要かを確認 • 開発メンバー全員が参加する • チームの知⾒を結集することで、⾒落としなどを防ぐ • 全員が情報をキャッチアップできるので、スプリント中に⽀援しやすくなるエピックリファインメント

Slide 64

Slide 64 text

-:$PSQPSBUJPO • 次のスプリントにチームでコミットするための体制を決める • チームの枠組みと実施内容、スキルセットなどを⾒ながらメンバー編成 • 個々に⾃分がどのチームに参加したいかを検討して宣⾔ • スキルセットや引き継ぎの観点で全体のバランスを⾒て、⼀部⼊れ替えなどの調整「流動チーム体制」チーム編成実際のチーム編成ボード

Slide 65

Slide 65 text

-:$PSQPSBUJPO • 編成開始前「流動チーム体制」チーム編成 Opsチーム PBIチーム注⼒チーム1 注⼒チーム2 まだチームが決まっていない⼈スプリントN 2-3⼈ 2-3⼈ Xの技術スキル

Slide 66

Slide 66 text

-:$PSQPSBUJPO • 編成開始前 • 各メンバーはおやすみなどを宣⾔ • ⼀部メンバーはチームが決まっている • 特定のスキルセットが必要な場合は明⽰「流動チーム体制」チーム編成 Opsチーム PBIチーム注⼒チーム1 注⼒チーム2 Opsチームはローテーションであらかじめメンバーが決まっている（交換可能）引き継ぎコスト等を考慮し、注⼒チームは誰かが残留するケースが多いまだチームが決まっていない⼈⽉曜休みスプリントN 2-3⼈ 2-3⼈注⼒チームは⼈数の⽬安があるエピックを確実に進めるために必要なスキルセットがある場合はあらかじめ提⽰する Xの技術スキル

Slide 67

Slide 67 text

-:$PSQPSBUJPO • 編成開始前 • 各メンバーはおやすみなどを宣⾔ • ⼀部メンバーはチームが決まっている • 特定のスキルセットが必要な場合は明⽰「流動チーム体制」チーム編成 Opsチーム PBIチーム注⼒チーム1 注⼒チーム2 Opsチームはローテーションであらかじめメンバーが決まっている（交換可能）引き継ぎコスト等を考慮し、注⼒チームは誰かが残留するケースが多いまだチームが決まっていない⼈スプリントN 2-3⼈ 2-3⼈注⼒チームは⼈数の⽬安があるエピックを確実に進めるために必要なスキルセットがある場合はあらかじめ提⽰する⽉曜休み Xの技術スキル

Slide 68

Slide 68 text

-:$PSQPSBUJPO • メンバーみんな新しい取り組みに前向き • Slackのリアクションもつくられた「流動チーム体制」スタート前向きにチャレンジできてよかったし、それができるのはいいチームだなぁープロダクトの価値提供にも期待︕ 取り組むと決まったからには、結果につなげたい︕

Slide 69

Slide 69 text

-:$PSQPSBUJPO 「流動チーム体制」がもたらしたもの

Slide 70

Slide 70 text

-:$PSQPSBUJPO 成果とチームの変化

Slide 71

Slide 71 text

-:$PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4スプリント「流動チーム体制」によって得られた成果スプリント 1エピックを完成させるまでにアイテムに着⼿していないスプリント

Slide 72

Slide 72 text

-:$PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4スプリント • より短い期間でエピックを完了できた • 1エピックを完了させるまでにかかったスプリント数︓12.9スプリント → 8.6スプリント「流動チーム体制」によって得られた成果スプリント 1エピックを完了させるまでにかかったスプリント

Slide 73

Slide 73 text

-:$PSQPSBUJPO • 注⼒したエピックを確実に進められた • 1エピックを完成させるまでにアイテムに着⼿していないスプリント数︓6.4 → 1.4 • より短い期間でエピックを完了できた • 1エピックを完了させるまでにかかったスプリント数︓12.9スプリント → 8.6スプリント「流動チーム体制」によって得られた成果成果につながってよかった︕

Slide 74

Slide 74 text

-:$PSQPSBUJPO • LeSSチームとしてのまとまりが出た（ポジティブ） • 注⼒チームが注⼒できるようにみんなでサポート • エピック全体に⽬を向けられるようになった • スプリント間の引き継ぎがスムーズになった • 最新の情報がキャッチアップしやすくなった • 開発メンバー同⼠のコミュニケーションが増えた • 単体の開発チームや個⼈の観点では課題もあった（ネガティブ） • チームレトロスペクティブの活⽤が難しくなった • 個⼈の成⻑の観点での課題が⾒えてきた「流動チーム体制」によってチームにおきた変化

Slide 75

Slide 75 text

-:$PSQPSBUJPO • これまで • LeSSの各開発チーム内で取り組むバックログアイテムに集中しがち • ほかの開発チームからのレビュー依頼への対応が後回しになる • 障害が発⽣するとみんなで対処する注⼒チームが注⼒できるようにみんなでサポートレビューお願いします⼀緒に確認します︕ 障害⻘チームあれっ、障害︖ ⿊チーム緑チームレビューの前に⾃分のチームのバックログアイテム進めないと…

Slide 76

Slide 76 text

-:$PSQPSBUJPO • 変化後 • 注⼒チームのレビューは他レビューに⽐べて優先度⾼く⾒るようになった • 障害などが発⽣しても、Opsチームが担当してくれるので注⼒チームは変わらず注⼒できる注⼒チームが注⼒できるようにみんなでサポート障害障害発⽣したので対処しておきます︕ レビューお願いしますはい喜んで︕ 注⼒チームは注⼒対象のエピックに注⼒できる PBIチーム注⼒チーム Opsチーム

Slide 77

Slide 77 text

-:$PSQPSBUJPO • これまで • バックログアイテム単体に⽬が⾏きがち • ACは達成できているけれど、エピックのゴールに達するには次スプリントでのカバーが必要エピックの全体像に⽬を向けられるようになった

Slide 78

Slide 78 text

-:$PSQPSBUJPO • 変化後 • バックログアイテムではなく、エピックに注⼒するため、エピックの全体像に⽬を向けられる • スプリント中に新たな事実が判明したら適宜やることを変更 • スプリントゴールやエピックのゴールを達成するための「最短経路」を探し続けられるエピックの全体像に⽬を向けられるようになった

Slide 79

Slide 79 text

-:$PSQPSBUJPO • これまで • 特定のエピックのバックログアイテムを複数チームが順に担当することで、スキルの継承や知⾒の共有に課題ありスプリント間の引き継ぎがスムーズになったエピックAのアイテムエピックAのアイテム次スプリントでは別のチームが担当エピックAのアイテムエピックAのアイテムスプリントN スプリントN+1

Slide 80

Slide 80 text

-:$PSQPSBUJPO • これまで • 特定のエピックのバックログアイテムを複数チームが順に担当することで、スキルの継承や知⾒の共有に課題あり • 必要なスキルを⾝につけるためにスプリントの前半を利⽤するなどが発⽣スプリント間の引き継ぎがスムーズになった次スプリントでは別のチームが担当特定のエピックに紐づくバックログアイテムを別チームが担当すると、引き継ぎがうまくいかずスプリントのはじめに調査が必要なケースもエピックAのアイテムエピックAのアイテムエピックAのアイテムエピックAのアイテムスプリントN スプリントN+1

Slide 81

Slide 81 text

-:$PSQPSBUJPO • 変化後 • 全員でエピックリファインメントを⾏うことで、チーム全体で知識を共有 • 必要なスキルセットを持つメンバーを注⼒チームにアサイン • ⼀⼈は残留することで前スプリントの経緯を継承スプリント間の引き継ぎがスムーズになった次スプリントのメンバーはチーム替えで決まるスキルあり残留エピックAのアイテムエピックAのアイテムエピックAのアイテムエピックAのアイテムスプリントN スプリントN+1

Slide 82

Slide 82 text

-:$PSQPSBUJPO • 変化後 • 全員でエピックリファインメントを⾏うことで、チーム全体で知識を共有 • 必要なスキルセットを持つメンバーを注⼒チームにアサイン • ⼀⼈は残留することで前スプリントの経緯を継承スプリント間の引き継ぎがスムーズになったスプリントN スプリントN+1 次スプリントのメンバーはチーム替えで決まるメンバー残留や必要スキルセットの明確化により引き継ぎがスムーズにエピックAのアイテムエピックAのアイテムエピックAのアイテムエピックAのアイテムスキルあり残留

Slide 83

Slide 83 text

-:$PSQPSBUJPO • これまで • 情報を取得できていたバックログアイテムが限られていた • ⾃分が参加したリファインメントで扱ったもの、⾃分のチームが着⼿したもの • 情報取得が⼗分ではないバックログアイテムに関するレビューのコストが⾼い最新の情報がキャッチアップしやすくなったレビューに対応するために、バックログアイテムに関する情報収集から⾏う必要があったレビュー依頼なんのために⾏う変更だっけ︖ バックログアイテム

Slide 84

Slide 84 text

-:$PSQPSBUJPO • 変化後 • エピックリファインメントは全員参加のため、そこで全員が同じ情報を摂取できる • 注⼒チームに所属していなくても、状況が把握できる最新の情報がキャッチアップしやすくなった注⼒チームのバックログアイテムは全員が情報を共有しているためスムーズにレビューできるレビュー依頼エピックリファインメントでお話していた件だね優先的にレビューします︕ 注⼒対象エピックのアイテム注⼒対象エピックのアイテムバックログアイテム

Slide 85

Slide 85 text

-:$PSQPSBUJPO • これまで • 同じ開発チームのメンバーとのコミュニケーションは多い • 違う開発チームのメンバーとのコミュニケーションは少ない開発メンバー同⼠のコミュニケーションが増えたずっと同じメンバー

Slide 86

Slide 86 text

-:$PSQPSBUJPO • 変化後 • 毎スプリント違うメンバー構成なのでスプリントごとに違うメンバーとコミュニケーションができる • 結果的に、チーム全体でのコミュニケーションが増えた開発メンバー同⼠のコミュニケーションが増えたメンバー間のコミュニケーションの偏りが減り、コミュニケーション量も増えたずっと同じメンバー毎スプリントメンバーが⼊れ替わる

Slide 87

Slide 87 text

-:$PSQPSBUJPO • これまで • 同じメンバーでチームレトロスペクティブを実施 • チームの働き⽅のカイゼンを、スプリントごとに積み重ねていたチームレトロスペクティブの活⽤が難しくなった毎スプリント同じメンバーでカイゼンを積み重ねていく同じメンバーのチーム・・・

Slide 88

Slide 88 text

-:$PSQPSBUJPO • 変化後 • チームの働き⽅のカイゼン案を考えても、次スプリントはメンバーが⼊れ替わるため適⽤しにくい • 直接課題を感じたメンバーではないメンバーがカイゼン策だけ実施するよくわからない構図 • 個々で気をつけようになりがちチームレトロスペクティブの活⽤が難しくなった毎スプリントメンバーが⼊れ替わるチーム・・・このカイゼン策効果あるのかな個々⼈で気をつけられるといいね前のスプリントとチームのメンバー構成が変わるのでカイゼンの積み重ねができない

Slide 89

Slide 89 text

-:$PSQPSBUJPO • これまで • 開発チーム内の各メンバーの⽴ち位置は⼤きく変わらない • EMと相談しながら個⼈の成⻑を⾒据えた活動をしていた個⼈の成⻑の観点での課題が⾒えてきた同じメンバーのチーム・・・中堅中堅中堅中堅チーム内での役割が⼀定なのでその中で成⻑の軸を⾒つけられた

Slide 90

Slide 90 text

-:$PSQPSBUJPO • 変化後 • 毎スプリントチーム編成が変わるので⽴ち位置も変わるため、⼀定の環境下での挑戦がしにくくなった個⼈の成⻑の観点での課題が⾒えてきた毎スプリントメンバーが⼊れ替わるチーム・・・チームのメンバー構成が変わると求められる役割も変わる中堅若⼿シニア中堅

Slide 91

Slide 91 text

-:$PSQPSBUJPO 4.「流動チーム体制」をふりかえるうまくいったワケ

Slide 92

Slide 92 text

-:$PSQPSBUJPO なぜ「流動チーム体制」はうまくいったのか

Slide 93

Slide 93 text

-:$PSQPSBUJPO チーム全員で選択した挑戦だったから写真︓Duy Pham on Unsplash

Slide 94

Slide 94 text

-:$PSQPSBUJPO • ⼟台が整っていた • LeSSチームとして成熟していた • チーム全員で選択した挑戦だった • 先⾏事例があった • プロダクトとチームの状況を理解したうえで選択した • 挑戦できるチームだった • ダメだったらやめることを決めていた • 全員が施策のオーナーシップをもてた • スタートダッシュが決まった • あたりまえのようにカイゼンができたなぜ「流動チーム体制」がうまくいったのか

Slide 95

Slide 95 text

-:$PSQPSBUJPO • LeSSチームとして3年間プロダクト開発をしてきた • プロダクトオーナー、スクラムマスターは変わらず • スクラムやLeSSに対しての共通認識があった • メンバーの⼊れ替わりはあるが、常にフィーチャーチームでの開発をしていた • 扱うプロダクトに関する共通の基礎知識があった • 半年ごとにLeSSの開発チームのシャッフルをしていた • 開発チームごとの独⽴した最適化ではなく、LeSSチームとして最適化されていた • メンバーが⼊れ替わっても、チームビルディングまでに時間がかからない状態になっていた⼟台が整っていた

Slide 96

Slide 96 text

-:$PSQPSBUJPO 「流動チーム体制」誕⽣の流れ⽬指したい状態制約条件戦術何をどう変えると⽬指したい状態にできるかを考えるプロダクトの価値提供をし続けたい後半にビッグイシューがある⼈の増減により育成コストが増える継続的な価値提供ビッグイシュー育成コスト流動チーム体制 2023年3⽉⼈プロダクトイシュー環境チーム

Slide 97

Slide 97 text

-:$PSQPSBUJPO • プロダクトオーナーからスクラムマスターに課題提議 • 次の半期に⾃分たちのチームが置かれる状況を踏まえてどういうチーム体制にするのが良さそうか • スクラムマスターを中⼼にエンジニアリングマネージャーと相談チーム全員で選択した挑戦このままだと来期プロダクトとしてやりたいことができないかもたしかに、全体の⼈数も減ったし、チームを変えるにしても育成とかのバランス取るのも⼤変そうあとやっぱりPO的にはエピックがなかなかおわらないのが気になっている。そもそも単位が⼤きくなってしまっているというのもあるし、⼿戻りが発⽣することが多いのもある。来期の後半にはビッグイシューのエピックが控えている上、新卒などの育成コストがだいぶ取られちゃうと思うので、いまのままだと何も価値提供できなくなってしまうかもそれはそう。今期の旧プロダクトで⾏っていた取り組みは割と良かったと思うけれど、それを参考にしてみるのはどうだろう︖ PO / EM SM / EM

Slide 98

Slide 98 text

-:$PSQPSBUJPO • プロダクトオーナーからスクラムマスターに課題提議 • 次の半期に⾃分たちのチームが置かれる状況を踏まえてどういうチーム体制にするのが良さそうか • スクラムマスターを中⼼にエンジニアリングマネージャーと相談チーム全員で選択した挑戦 PO / EM SM / EM よさそう。あれは確実にエピックを終わらせることに注⼒できていたし、実際にゴールが⾒える状態まで進められていたベースのチームだけ作っておいて、注⼒するエピックに取り組む⼈だけ選出するような形式はどうだろうプロダクトの現状、チームの状況を踏まえて、来期の体制どうするか、チームメンバーに相談してみましょう。みんなの意⾒を聞いたうえで、どうするか決めようやってみるのはありかもしれない。ただ、EM的には、旧プロダクトの取り組みは結果は出ているが、結構⼤変だったというお話を1on1でも聞いている。実際に仕組みを変えたとして、それを実際にやるのは開発メンバーなので、みんなの意⾒は聞きたいですね

Slide 99

Slide 99 text

-:$PSQPSBUJPO プロダクトとチームの状況を理解したうえで選択した

Slide 100

Slide 100 text

-:$PSQPSBUJPO • チームに相談 • 次の半期にプロダクトや⾃分たちのチームが置かれる状況を説明 • スクラムマスターを中⼼にエンジニアリングマネージャーと相談して出した案を提案チーム全員で選択した挑戦今後のプロダクトとチームが置かれる状況を踏まえて、いまのままの体制でプロダクトの価値を届け続けられるんだっけ︖ということをSM / PO / EM で考えた。旧プロダクトで⾏っていた取り組みを参考に考えた、新しい体制を提案したい。 PO / EM SM / EM プロダクト

Slide 101

Slide 101 text

-:$PSQPSBUJPO • チームに相談 • 次の半期にプロダクトや⾃分たちのチームが置かれる状況を説明 • スクラムマスターを中⼼にエンジニアリングマネージャーと相談して出した案を提案チーム全員で選択した挑戦これをやりますという宣⾔ではなくて、案を聞いてどう思うかの意⾒が聞きたい。もしくは、別の案があればぜひ提案してほしい。実際にこの体制で動くのはみんななので、どんな感じになりそうかイメージしてみてほしい。中途半端に⼀部メンバーだけを都度移動するよりも、もっと⾃由度⾼く全部流動にしてしまえば良いのでは︖ 試してみても良さそう PO / EM SM / EM アグレッシブな案だけれど、他のメンバー的にはどうですか︖ ちょっと不安もあるかなおもしろそう新しい取り組みに前向きに挑戦できるチーム挑戦を楽しめるチーム

Slide 102

Slide 102 text

-:$PSQPSBUJPO チーム全員で選択した挑戦ちょっと極端で変化も⼤きいからという理由で提案をやめた案がでてきたぞ・・・やれるかな・・・元々の取り組みも開発メンバー発案だし、こういう提案が出てくるのはありがたいし、うちのチームの良いところだよなぁチームの各開発メンバーが、⽬的の達成を、主体性を持ちやすい形で、まとまりそうで良かったな。

Slide 103

Slide 103 text

-:$PSQPSBUJPO • スクラムマスターとエンジニアリングマネージャーで相談 • メンバーからのアグレッシブな提案を採⽤しつつも、チャレンジしやすくチーム全員で選択した挑戦アグレッシブなの来ましたねｗどうしましょう︖ せっかくメンバーから出てきた案だし、やってみるのもいいと思う。変化を受け⼊れられる、適応していけるチームだからできそう。たしかに。でもやるなら退路は⽤意しておきたいですね。うまくいくように仕組みのカイゼンはしてほしいけれど、失敗しても良いんだよっていうメッセージもセットにしたほうがチャレンジのハードルは下がりそう PO / EM SM / EM ですね。1ヶ⽉くらい経ったらでふりかえりをして、継続するか⽌めるかを決めよう

Slide 104

Slide 104 text

-:$PSQPSBUJPO • はじめての挑戦なので逃げ道を⽤意 • いきなりうまくいくわけない • カイゼンして仕組みを良くしていく活動はやる • それでもうまくいかなければ⽌める選択肢をはじめから提⽰ • 1ヶ⽉後くらいにチーム内でふりかえりをすることをあらかじめ決めたダメだったらやめよう⽴ち⽌まってふりかえり「流動チーム体制」継続固定の開発チームに戻すふりかえり・カイゼン

Slide 105

Slide 105 text

-:$PSQPSBUJPO ふりかえり・カイゼン • はじめての挑戦なので逃げ道を⽤意 • いきなりうまくいくわけない • カイゼンして仕組みを良くしていく活動はやる • それでもうまくいかなければ⽌める選択肢をはじめから提⽰ • 1ヶ⽉後くらいにチーム内でふりかえりをすることをあらかじめ決めたダメだったらやめよう⽴ち⽌まってふりかえり「流動チーム体制」継続固定の開発チームに戻すうまくいかなかったら、今まで通りのやり⽅に戻せばよいという道を⽤意することで挑戦しやすくした

Slide 106

Slide 106 text

-:$PSQPSBUJPO • スクラムマスターとエンジニアリングマネージャーで相談 • メンバーからのアグレッシブな提案を採⽤しつつも、チャレンジしやすく • それに伴い変えないといけない仕組みを検討チーム全員で選択した挑戦 PO / EM SM / EM この⽅針で進めるってことは、エピックに焦点を当ててお話する場がほしいのと、それとチーム編成をいつ⾏うのかっていうのを決めないといけない。いままで固定の開発チームという前提で成り⽴っていたものを全部⾒直さないといけないですね・・・そうだった・・・・やりますか︕ キックオフまであと2⽇しかないけど・・・やるしかないですね。やりましょう︕

Slide 107

Slide 107 text

-:$PSQPSBUJPO 「流動チーム体制」誕⽣⽬指したい状態制約条件戦術何をどう変えると⽬指したい状態にできるかを考えるプロダクトの価値提供をし続けたい後半にビッグイシューがある⼈の増減により育成コストが増える継続的な価値提供ビッグイシュー育成コスト流動チーム体制 2023年4⽉⼈プロダクトイシュー環境チーム

Slide 108

Slide 108 text

-:$PSQPSBUJPO • プロダクトやチームの状況を理解したうえで、「流動チーム体制」に前向きに取り組めた • スタートダッシュを決めることができた • プロダクトにとって⼤事な要素であり、チームにとっての成功体験としても⼤事な要素になった全員が施策のオーナーシップをもてた 3つのエピックが完了チームとして⼿応えを感じられたはじめの6スプリント

Slide 109

Slide 109 text

-:$PSQPSBUJPO • プロダクトやチームの状況を理解したうえで、「流動チーム体制」に前向きに取り組めた • スタートダッシュを決めることができた • プロダクトにとって⼤事な要素であり、チームにとっての成功体験としても⼤事な要素になった • 「流動チーム体制」⾃体のカイゼンに取り組めた • 「流動チーム体制」内の各チームに対する期待値、⽬指す状態、ありたい姿のすり合わせ • 現在地の確認と、⽬指す状態やありたい姿に近づくには何をすればよいかの検討全員が施策のオーナーシップをもてたふりかえり・カイゼンありたい姿ありたい姿が⾒えることで、より⾏動につながった

Slide 110

Slide 110 text

-:$PSQPSBUJPO 「流動チーム体制」とはなんだったのか

Slide 111

Slide 111 text

-:$PSQPSBUJPO 「流動チーム体制」とは

Slide 112

Slide 112 text

-:$PSQPSBUJPO 価値提供のリードタイムを短くするための戦術写真︓JESHOOTS.COM on Unsplash

Slide 113

Slide 113 text

-:$PSQPSBUJPO • 「流動チーム体制」でやっていること • 注⼒対象のエピックで扱う課題の解決にチーム全体で注⼒「流動チーム体制」も1つの⼿段 εΫϥϜνʔϜ͸ɺΰʔϧʹ޲͚ͯՄೳͳݶΓਐḿͰ͖ΔΑ͏ʹɺεϓϦϯτͷ࡞ۀʹूத͢Δɻ 「スクラムガイド2020年度版」 Ken Schwaber＆Jeff Sutherland著 https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スクラムの価値基準の⼀つである「集中（Focus）」をチーム全体で体現するための仕組み

Slide 114

Slide 114 text

-:$PSQPSBUJPO • エピックという⼀つの課題に、メンバーが⼊れ替わりながら取り組んでいる • 課題は全員で共有されている • エピックは注⼒チームに紐づき、その課題を解決するために必要な⽬安の⼈数が明⽰されている「流動チーム体制」も1つの⼿段 LeSSにおけるMobの形の⼀つと⾔えるかもしれない

Slide 115

Slide 115 text

-:$PSQPSBUJPO 5. まとめ「流動チーム体制」を通して得られたこと

Slide 116

Slide 116 text

-:$PSQPSBUJPO • 価値提供のリードタイムを短くすると、プロダクトのインクリメントを作り続けられる • 注⼒対象を決めて、チーム全体でそこに集中しコミットできる体制を作ることが⼤切 • 前⾝の取り組みでは、LeSS内の開発チームの⼈の配置を⼀部調整してコミットできるようにした • 「流動チーム体制」では、仕組みで毎スプリントコミットできる体制を作ったプロダクトのインクリメントを確実に作り続けるために

Slide 117

Slide 117 text

-:$PSQPSBUJPO • プロダクトに関する共通知識とLeSSチームの基盤があれば、⼈の⼊れ替えも変数にできる • これはLeSSにおける⼀つのプラクティスと⾔えそう⼈を流動的に動かすのはLeSSの⼀つの選択肢

Slide 118

Slide 118 text

Slide 119

Slide 119 text

-:$PSQPSBUJPO • みんなで話して、みんなの意⾒を聞いて決めて、みんながオーナーシップを持つようにする • チームとしてのありたい姿をみんなでイメージしながら、そこにどうたどり着くかを考えるチーム全体でなにかにチャレンジするときのコツ対話オーナーシップありたい姿アクション現在地

Slide 120

Slide 120 text

-:$PSQPSBUJPO • 「流動チーム体制」は価値提供のリードタイムを短くするためのLeSSチーム内の取り組み • 「流動チーム体制」はDynamic Reteamingの⼀つの事例になり得る • Reteamingをおこなうことになった経緯や⽬的は異なるが、⼤事にしている要素は同じだった RSGT2024 Keynote “Dynamic Reteaming” を聞いて⽬的の明確化みんなで決めるオーナーシップを持つ RSGT2024 Keynote︓ https://confengine.com/conferences/regional-scrum-gathering-tokyo-2024/proposal/19401/dynamic-reteaming-the-art-and-wisdom-of-changing-teams

Slide 121

Slide 121 text

-:$PSQPSBUJPO • スクラムの検査と適応を、プロダクトだけでなく仕組みに対しても実践していくことで、アップデートしていける • 体制や働き⽅をアップデートするときには、チーム全体でありたい姿を具体的にしていくことで、より効果的に取り組めるさいごに

Slide 122

Slide 122 text

-:$PSQPSBUJPO Special Thanks Hiroki Fukasawa Keita Terada Shinichi Yanagido Taiki Yoshikawa Takumi Kataoka Tomonori Kawai Yoichi Nagamoto Yusuke Kondou Hiroshi Hayakawa Mayuki Ishikawa Shu Kutsuzawa Takayuki Ootani Tetsushi Kuma Tomoyuki Nakamura Yudai Moriya Yuya Miki And more...

Slide 123

Slide 123 text

-:$PSQPSBUJPO ありがとうございました