Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フルリモートワークでのスクラムのスケール
Search
Kenji Morita
January 09, 2024
Research
2
1k
フルリモートワークでのスクラムのスケール
3人から、3年間で30人6チームまでのスケールした時の課題と、Scrum@Scale及びLeSSのプラクティス適用
Kenji Morita
January 09, 2024
Tweet
Share
Other Decks in Research
See All in Research
クリック率を最大化しない推薦システム
joisino
42
14k
Cross-Media Information Spaces and Architectures
signer
PRO
0
120
F0に基づいて伸縮された画像文字からの音声合成 [ASJ2024春]
nehi0615
0
120
10-ot-generic-bio.pdf
gpeyre
0
140
論文紹介 DISN: Deep Implicit Surface Network for High quality Single-view 3D Reconstruction / DISN: Deep Implicit Surface Network for High quality Single-view 3D Reconstruction
nttcom
0
120
ランサーズエージェント_フリーランスエンジニアの年収・キャリアの実態調査2024
lancers_pr
0
110
Weekly AI Agents News!
masatoto
12
3.6k
自己教師あり学習による事前学習(CVIMチュートリアル)
naok615
2
1.4k
媒介分析と疫学
kingqwert
0
100
How to Perform Manual Classification for Deep Learning Using CloudCompare
kentaitakura
0
660
Deep State Space Models 101 / Mamba
kurita
9
3.6k
Azure Arc-enabled Serversを利用した ハイブリッド・マルチクラウド環境の管理 / Managing Hybrid Multi-cloud Environments with Azure Arc-enabled Servers
nttcom
0
210
Featured
See All Featured
Making the Leap to Tech Lead
cromwellryan
125
8.5k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
The Illustrated Children's Guide to Kubernetes
chrisshort
32
46k
Done Done
chrislema
178
15k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
323
20k
Practical Orchestrator
shlominoach
183
9.7k
The Invisible Side of Design
smashingmag
294
49k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
33
6k
Learning to Love Humans: Emotional Interface Design
aarron
267
39k
Typedesign – Prime Four
hannesfritz
36
2.1k
The Art of Programming - Codeland 2020
erikaheidi
43
12k
Transcript
3人から、3年間で30人6チームまでのスケールした時の課題と、 Scrum@Scale及びLeSSのプラクティス適用 フルリモートワークでのスクラムのスケール 守田憲司 Preferred Networks, Inc.
守田 憲司 2 共訳 1991~2018 Canon Inc. 2018~ Preferred Networks,
Inc 社内Agile Coach Scrum X Scale Hardware Research AI
最新の研究成果を、早く、高い品質で 研究成果を早く高品質に届けたい 3 Research/AI/Hardwareを含めたScrum 複数チームのScrum
Matlantis (対象プロダクト) バーチャル実験 汎用原子レベルシミュレータ 高速に材料探索 ~1万回オーダ 有望な 材料 結果・考察 フィードバック
次の バーチャル実験 リアル実験 触媒 潤滑油 吸着材 合成燃料の触媒探索 添加剤の鉄表面への作用 MOFへの水吸着 新たな研究開発サイクルによる開発期間短縮 適用事例 高い 成功確率 4
Matlantisの特徴 5 ブラウザ上で すぐに使用可能 従来手法の 10,000倍以上 高速 72元素の 組み合わせに 対応
LeSSとScrum@Scale 6 ----- ----- ----- ---- 9チームまで1チームのように CPO PO PO
PO PO PO LeSS Scrum@Scale
• 成功するか分からない • リソース不足 • 激しいスキルと知識の乖離 スタート時(3年前)の状況 研究者 コア技術 サービス開発
?
• 成功するか分からない • リソース不足 • 激しいスキルと知識の乖離 スタート時(3年前)のRetrospective 研究者 コア技術 サービス開発
Daily 無駄では?
• 1チームをキープ • クロスファンクショナルチームで共通言語を作る • MVPしか作れない ⇨ Jupiter notebookのシミュレーション環境 1チームをキープ(3年前のスタート時)
研究者 コア技術 サービス開発
Problem-Solution Fit の感触 • 少しずつ顧客が増えていく • チームも徐々に成長 Problem-Solution Fit 10
• どうやっても全体は1チームに収まらない。 1年後の状況 研究者 コア技術 サービス開発 ?
• どうやっても全体は1チームに収まらない。 1年後のRetrospective 研究者 コア技術 サービス開発 Daily 無駄でしょ!
LeSSとScrum@Scale 13 ----- ----- ----- ---- 9チームまで1チームのように CPO PO PO
PO LeSS Scrum@Scale 依存関係を少なく分割する
• Backlog, Meeting(Sprint Review以外) 分割 • 研究者チームはScrum離脱、Product Backlogだけ共有 • Scrum@Hardwareでエンジンと胴体作ったらこんな感じかも?
専門性で分割(スタートから1年後) 研究者 コア技術 サービス開発 数ヶ月での 技術革新 研究成果を仕上げる のに時間がかかる 日~週単位でリリース 最先端 独自性 精度評価、確認 過去との互換性担保 車輪の再発明しない OSS活用して効率よく リズムの違い 価値観の違い ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
• サービス開発チームが成長 ◦ 多すぎるよな~ ◦ 不満がでるまで待ってみよう スタートから2年後の状況 研究者 コア技術 サービス開発
? ? ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
スタートから2年後のRetrospective 研究者 コア技術 サービス開発 Dailyの共有はSlackで、、 ちょっと待って ----- ----- ----- ----
----- ----- ----- ---- ----- ----- ----- ---- 起きていたこと • ミーティングが長く感じる • チーム内の事を把握しきれない
LeSSとScrum@Scale 17 ----- ----- ----- ---- 9チームまで1チームのように CPO PO PO
PO LeSS Scrum@Scale 依存関係を少なく分割する
• サービス開発をLess的に分割 • 1、2週間で当たり前になって、皆楽そう(ふりかえり難しい) • チーム名はBlueとOrange、責任の分割無し ◦ PO、Product Backlogは共通 ◦
Muralのポストイットの色に対応させた(一つのKanban) ◦ 結果としては、インフラよりとUXよりのチームができた スタートから2年後の分割結果 研究者 コア技術 サービス開発 ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
• サービス開発は2チームでも厳しい感じに • コア技術のチーム人数多め • 研究者チームとは、少し疎な良い関係 さらに成長(半年前くらいの状況) 研究者 コア技術 サービス開発
? ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
• チームの意味を理解 • チーム分割を理解 半年前くらいのRetrospective 研究者 コア技術 分けてみよっか? サービス開発 LeSS的にいきますか。
----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
• サービス開発は3チームへ分割 • コア技術のチームも試しに分割 現在の状態 研究者 コア技術 サービス開発 • 3つのProduct
Backlog • 1つのSprint Review • 5つのDaily Scrum ----- ----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
スケールと役割の分離 22 PdM EM PO PdM EM CPO PO PO
PO EM PO PdM EM CPO PO PO EM PO PO EM EM PO PdM CPO 少人数 チーム毎のPO EM 追加 EM分離 PdM, CPO 分離 全体 Green Team Orange Team Blue Team Purple Team 1人
現在のミーティング (1週間Sprint) 研究者 コア技術 サービス開発 Daily Daily Daily Daily Daily
Planning Part 1,2 Planning Part 1,2 Review準備 Review準備 Sprint Review Planning 3 Planning 3 Planning 3 Planning 3 Planning 3 Retrospective Retrospective Retrospective Retrospective Retrospective 全体Retrospective 全体 Backlog Refinement Refinement Refinement Refinement Refinement Refinement
• 人数が多すぎる ◦ Dailyが長くて退屈 ◦ Daily Slackで済ませたい ◦ ミーティングがムダ ◦
全部理解しきれない ◦ Kanbanが縦に長い チーム分割まとめ 24 • リズムが合わない ◦ Deploy頻度 ◦ Reviewの反応 • 価値観が合わない ◦ 車輪の再発明は避けたい ◦ 最先端技術を創りたい LeSS的に分割 Scrum@Scale的に分割
非言語コミュニケーション 困ったときの相談 偶発的な会話 リモートワークで失われたこと 25 常に課題に上がる事 • ミーティング時間のムダ • コミュニケーション不足
偶発的な会話を増やすために考えたこと 26 リモートワークの有利な点 • 会議への移動のロスが少ない。 起こりがちな事 • ミーティングの参加者が増える • 会議の数を減らす
意識した事 • ミーティングの数を増やす • 参加者を絞る
ミーティングの数と参加人数 27 多くの参加者 少ないミーティング 多くのミーティング 少ない参加者 2倍の発言量 一人当たり同じミーティング時 こうなりがち
様々な場を通じて、豊かな会話を 28 経営陣 PO & 経営陣 PdM POs Biz Biz
& Service 開発 研究 コア 技術 研究& コア技 術 サービ ス 開発 ステー クホル ダー PO & ス テークホ ルダー サービス 開発 & ス テークホ ルダー 場をたくさん作る • チーム内と代表者 ◦ 参加者は絞って
リモートワークとスケールまとめ 研究者 コア技術 サービス開発 リズムと価値観で大きく分割 (Scrum@Scale) 8~10人になったら責任分担なく分割(LeSS) リモートワークの特性を活かし 会議を増やして、人数を絞る -----
----- ----- ---- ----- ----- ----- ---- ----- ----- ----- ----
Making the real world computable