Nexus and LeSS #rsgt2016

©2016 Kenji Morita
Nexus と LeSS の
概要説明、比較
キヤノン株式会社守⽥憲司
株式会社ガイアックス⽊村卓央

©2016 Kenji Morita
守田憲司
Kenji Morita
キヤノン株式会社
デジタルシステム開発本部
主幹研究員
@wsfjp
Nexus Guide 共訳

©2016 Kenji Morita
本日のテーマ
開発チームが１０人
超えたらどうする？

©2016 Kenji Morita
12人
66
メンバーか9人を超えた場合は、調整の機会
が多くなってしまう。また、チームの規模が
大きいと、経験的プロセスの管理が複雑に
なってしまう。（スクラムガイド）

©2016 Kenji Morita
大人数で
開発するには
分割が必要

©2016 Kenji Morita
出典：9TH ANNUAL State of Agile™ Survey (Version one)
使われているスケール手法の割合
Scrum / Scrum of Scrum 69%
独自手法 25%
SAFe 19%
＝＝＝＝＝＝＝＝＝＝＝
LeSS 3%
Nexus 未掲載
＊複数回答

©2016 Kenji Morita
SAFe (19%)
http://www.ogis-ri.co.jp/solution/1210904_6793.html

©2016 Kenji Morita
「スクラムガイド」より
「複数のスクラムチームが同じプロ
ダクトの作業をすることがよくある。
そうした場合、プロダクトの作業は1
つのプロダクトバックログに記述す
る。また、アイテムをグループにま
とめる属性をプロダクトバックログ
に追加する。」

©2016 Kenji Morita
コンウェイの法則
アーキテクチャは組織にしたがう
組織はアーキテクチャにしたがう

©2016 Kenji Morita
チーム分けで考慮すべきこと
組織
プロセス
アーキ
テクチャ

©2016 Kenji Morita
スケール階層と手法自体の大きさ
２階層３階層
SAFe
LeSS
（２∼８チーム）
LeSS Huge
(９∼チーム）
Nexus
(約３∼９チーム）
Nexus+
(約10∼チーム）小さい
大きい
手法自体
の大きさ

©2016 Kenji Morita
Nexusの概要

©2016 Kenji Morita
Nexus ガイド
•無料公開されています。
•短いです。(10ページ)
英語版 2015年8月公開
日本語版 2015年12月公開
開発：Ken Schwaber and Scrum.org
翻訳：角征典、守田憲司
https://www.scrum.org/Resources/The-Nexus-Guide
Nexus ガイドにもとづいて説明します。

©2016 Kenji Morita
Nexus
The exoskeleton(外⾻格) of scaled Scrum

©2016 Kenji Morita
スコープ
l約３〜９スクラムチーム
l１つのプロダクトバックログ
「チームが３つ以上になると、さらに事
態は複雑になる」

©2016 Kenji Morita
スクラムチーム
lチーム間の依存関係が少なくなるように
分割する
l関連する以下の要素をチーム内にそろえ
る
• 要求
• ドメイン知識
• ソフトウェアやテストの作成物

©2016 Kenji Morita
ソフトウェアプラクティス
l多くのソフトウェアプラクティスが必要
である。
l大規模な環境では特に自動化が必要であ
る。

©2016 Kenji Morita
Nexusの説明

©2016 Kenji Morita
NEXUSの役割

©2016 Kenji Morita
Nexusの役割
Nexus統合チーム
約３〜９のスクラムチーム
プロダクトオーナー（全体で１人）
スクラムマスター（兼任可）
チームメンバー（兼任可）
適切な代表者
（特に定義されてないが）
スクラムマスター

©2016 Kenji Morita
Nexus統合チーム
lすべての作業の統合を成功させる最終的
な責任がある。
lチーム間の技術的・非技術的な制約を解
消する。
l依存関係やチーム間の問題に対する認識
を高める。
lコーチング、コンサルティングを行う。

©2016 Kenji Morita
Nexus統合チームの
プロダクトオーナー
lNexus全体で１人のプロダクトオー
ナー
l統合インクリメントの価値を最大化する。
lプロダクトバックログの順番とリファイ
ンメントに最終的な責任を持つ。

©2016 Kenji Morita
Nexus統合チームの
lNexusが理解され、実施されることに
責任を持つ。

©2016 Kenji Morita
Nexus統合チームメンバー
l（３ではなく）１人以上
lスクラムチームが獲得、実施、学習でき
るようにコーチングや指導をする。
• プラクティス、ツール、開発、インフラ、
アーキテクチャ標準

©2016 Kenji Morita
NEXUSのイベント

©2016 Kenji Morita
イベント
lNexusスプリントプランニング
lNexusデイリースクラム
lNexusスプリントレビュー
lNexusスプリントレトロスペクティブ
lリファインメント

©2016 Kenji Morita
Nexusスプリントプランニング
l代表者
l各チームで

©2016 Kenji Morita
Nexusスプリントプランニング１
l各スクラムチームの代表者が
作業の順番を確認・調整する。
lNexusスプリントゴールを作
成する。
l成果物
• Nexusゴール

©2016 Kenji Morita
Nexusスプリントプランニング2
l各スクラムチームでスプリン
トプランニングを実施する。
• 他のチームと情報交換する。
• 同じ場所で実施すると新しく発
見した依存関係が共有できる。
l成果物(チーム毎)
• スプリントゴール
• スプリントバックログ

©2016 Kenji Morita
Nexusデイリースクラム
lチームの代表者（毎日）。
l各スクラムチーム

©2016 Kenji Morita
Nexusデイリースクラム１
l３つの質問
ü 昨日の作業はうまく統合された
か？うまく統合されていなけれ
ば、それはなぜか？
ü 新たに特定された依存関係は何
か？
ü Nexusのチーム間で共有が必要
な情報は何か？
l特定された作業は各スクラム
チームのデイリースクラムに伝
えられる。

©2016 Kenji Morita
Nexusデイリースクラム２
lNexusデイリースクラムで特定
された統合の問題を解決できる
ように、その日の計画を立てる。

©2016 Kenji Morita
Nexusスプリントレビュー
lすべてのチームがプロダク
トオーナーのもとに集まり、
統合されたインクリメント
をレビューする。
l全ての機能をレビューでき
ないかもしれない。
Ø上手くやってね♪

©2016 Kenji Morita
Nexusスプリントレトロスペクティブ
l代表者
• 共通課題の特定
l各スクラムチーム
• 個別に実施
l代表者
• 必要なアクションの見える化、
追跡について合意する。

©2016 Kenji Morita
Nexusスプリントレトロスペクティブ
l全てのレトロスペクティブで扱うべき議
題
• 完成していないものはあるか？Nexusは技
術負債を作り出していないか？
• 作成物（特にコード）は、（できれば毎
日）頻繁に統合されているか？
• 未解決の依存関係が蓄積されない程度に、
頻繁にソフトウェアがビルド・テスト・デ
プロイされているか？

©2016 Kenji Morita
リファインメント
1. 十分に詳細になるまで分解する。
• 担当するチームを予測するために必要にな
る。
2. 依存関係を特定して見える化する。
• 作業順番や割り当てを見直し、チーム間の
依存関係を最小化するために、これらの情
報が必要となる。

©2016 Kenji Morita
NEXUSの作成物

©2016 Kenji Morita
プロダクトバックログ
l全体で１つのプロダクトバックログ
lPBIがNexusスプリントプランニングに
向けて（Ready）準備完了とは？
• スクラムチームによって選択可能
• 依存関係は排除または最小化されている。
• そのスクラムチームだけでプラクトバック
ログアイテムを完成できなければいけない。

©2016 Kenji Morita
Nexusスプリントバックログ
lNexus統合チームのスプリントバック
ログ
• 「スクラムチームのスプリントバックログ
にある全てのプロダクトバックログアイテ
ムをまとめたものである。」
lスプリントにおける依存関係や作業の流
れを強調するために使用する。
l少なくとも毎日更新する。

©2016 Kenji Morita
バックログとスプリントゴール
Nexus
スプリントバックログ
Nexus
スプリントゴールスプリントゴール
スプリントゴール

©2016 Kenji Morita
統合インクリメント
l完了した「統合された作業」すべての総
和である。
l利用可能でリリース判断可能なものでな
ければいけない。
l「完成」の定義を満たしていなければい
けない。
lNexusスプリントレビューで検査する。

©2016 Kenji Morita
作成物の透明性
l技術的負債が許容不可能になる前に、依
存関係を検出および解消しなければいけ
ない。
l許容不可能な技術的負債かどうかは、結
合する時にはじめてわかる。

©2016 Kenji Morita
「完成」の定義
lNexus統合チームは「完成」の定義に
実行責任を持つ。
lチーム独自の「完成」の定義は、インク
リメントの完成の定義より緩い基準を適
用してはいけない。

©2016 Kenji Morita
Nexusについて質問等

©2016 Gaiax Co.Ltd,. ©2016 Kanataku,LLC.
LeSS(Large-Scale Scrum)
http://less.works/

Certified Scrum Professional®/Scrum Developer®/ScrumMaster®/Scrum Product Owner®
Project Management Professional (PMP)®
EXIN Agile Scrum Foundation 認定講師
アジャイルサムライ横浜道場主催(休眠)
PMI⽇本⽀部アジャイルプロジェクトマネジメント研究会会員
TOCfE横浜塾主催
LeSS Study主催
Fearless Changeアジャイルに効くアイデアを⼈めるための48のパターン共訳
木村卓央
KIMURA Takao
R&D PMO
@tw_takubon
http://facebook.com/kimura.takao
http://about.me/tw_takubon

http://www.gaiax.co.jp/

LeSS Study
https://www.facebook.com/groups/less.study/
https://less-study.doorkeeper.jp/

絶賛翻訳中・・・
PBI = 75

おことわり
ただいま、翻訳中かつ、less.workの内容も変わるこ
とがあります。
今回使⽤した⽤語について、今後変わることもあり
ます
まだまだ理解が⾜りていないところもあるかも…

LeSS アジェンダ
nLeSSの構成と特徴
nLeSSのフレームワーク
l役割
lイベント
l作成物

LeSSの構成
http://less.works/

LeSSの構成
nLeSSは、複数チームのコンテキストにスクラムを
適⽤するためのガイドとルールのセットからなる
lLeSS Framework
lLeSS Rules(January 2016)
n２つのスケーリングフレームワーク
lLeSS
Ø2~8チーム(それぞれ8名)
lLeSS Huge
Ø1プロダクト数千⼈まで

LeSSの構成
nガイドとルール
lLeSS Framework
lLeSS Huge
lLeSS Rules
n実験(秘訣)
l原則(Principles)
l構造(Structure)
lマネジメント(Management)
l技術的優位性(Technical Excellence)
l採⽤(Adoption)

＆フィーチャーチーム
スプリントレビュー
レトロスペクティブ
全体的な
デイリースクラム
プロダクト
バックログ
スプリント
バックログ
スプリント
プランニング 1
スプリント
プランニング 2 協調
LeSS Framework
http://less.works/

全体的な
プロダクト
バックログ
スプリント
バックログ
スプリント
スプリント
プロダクト
オーナー
出荷可能な
プロダクトの
インクリメント
LeSS Huge
http://less.works/

LeSS Huge
n８チーム以上に適したLeSSの
第２のフレームワーク
n概念的には、LeSSフレームワークの上に
複数のLeSSフレームワークを積み重ねて
スケールアップされる
n基本的にはLeSSのフレームワークと同じ

LeSS Rules
nLeSS Frameworkの定義が書かれている
n最新版は 2016年1⽉版
nLeSS Framework Rules
lLeSS Structure
lLeSS Product
lLeSS Sprint
nLeSS Huge Framework Rules
lLeSS Huge Structure
lLeSS Huge Product
lLeSS Huge Sprint

Large-scale Scrum
はスクラム
透明性
より少ない労⼒で
⼤きな成果を
プロダクト全体に
フォーカス
顧客中⼼
完成に向けた
継続的改善
リーン思考
システム思考
経験的プロセス
コントロール
待ち⾏列理論
原則
http://less.works/

フィーチャーチーム
組織構造
チーム
顧客価値による
組織化
コミュニティ
構造
構造
http://less.works/

LeSS での組織構造
プロダクト
グループ⻑
フィーチャー
チーム #1
フィーチャー
チーム #2
フィーチャー
チーム #n
未完了に
対応する
部⾨
プロダクト
オーナー
(チーム)
プロダクトグループ⻑
(Head of the Product Group)
全てのチームの階層的なマネージャー
彼らは現場主義によってチームをサポートし、それら
が障害の除去し、チームが成⻑するのを助けます
(Feature teams)
開発作業を⾏う
各フィーチャーチームは、スクラムマスターとクロス
ファンクショナル(機能横断的)、⾃⼰組織化なチーム
プロダクトオーナー(チーム) プロダクトマネジメント
チームとプロダクトオーナーの関係が対等である
未完了に対応する部⾨
(Undone department)
未完了作業(Undone Work)に対応する
理想的には存在しない
彼らは最初からチームに統合されるべき
http://less.works/

マネージャーの役割
現場主義
問題解決の⽅法を教える
⾃⼰組織化
改善サービス
スクラムマスターとしての
マネージャー
マネージメント
マネジメント
http://less.works/

技術的優位性
技術的優位性
http://less.works/

3つの原則
継続的改善
採⽤マップ
開始
コーチング
採⽤
採⽤
http://less.works/

基本は1チームのスクラムと同じ
スクラムのプラクティスとアイデアを保持
n1つのプロダクトバックログ
n1つの完成の定義
n各スプリントの終わりに出荷可能な成果物を
n1⼈の(全体の)プロダクトオーナー
nクロスファンクショナル(機能横断的)なチーム
nスプリント
lLeSSでは、全てのチームが共通のスプリントで
共通の出荷可能な成果物をデリバリーする

協調と統合(Coordination & Integration)
nとりあえず話す
nコードで会話する
nデイリースクラムにオブザーバーを送り込む
nコミュニティと監視者(guardians)を構成する
nスクラムオブスクラム
nマルチチームのミーティング
nボトルネックを活⽤し、壊し、スキルを⽣み出す
旅⾏者(経験豊富な技術の専⾨化)
n主導的なチーム

全体的な
プロダクト
バックログ
スプリント
バックログ
スプリント
スプリント
LeSSのフレームワーク
http://less.works/

LeSS での役割
nプロダクトオーナー
l全体で1⼈のプロダクトオーナー
nスクラムマスター
nチーム
基本的には１チームのスクラムと同じ

nプロダクトバックログの管理者
n開発チームの成果を検証する
nプロダクトバックログの優先順位付け
lビジネス上に関する情報を収集し分析する
nプロダクトバックログアイテムの明確化
l振る舞いの詳細化、品質、ユーザーエクスペリエ
ンス、その他設計上の問題を明確化する

明確化よりも優先順位付け
n優先順位付けは、ひとりのプロダクトオーナー
n明確化は、チームで協業する
lユーザー／顧客とチームとの直接会話することを
奨励する
lその場を提供し、場をつなげる役割としてのプロ
ダクトオーナー
nメリット
lプロダクトオーナーは全体像を描くことに集中す
ることができる
lチームが直接顧客と協⼒することで、モチベー
ションや、顧客への共感を向上させる

nチームにプロダクト全体を意識するよう働きかける
l⼤きなプロダクトグループの⼈々の相互作⽤、遅
延、原因、ポテンシャル（潜在リスク）などの
各個⼈の考えの範囲を超えてサポート
lプロダクト全体の狙いをチームに意識付けをおこ
なう
n透明性を保つよう働きかける
nフルタイムで専任
n場合によっては３チームまで兼務は可能

チーム
n⾃⼰組織化
nクロスファンクショナル(機能横断的)
n全てのチームの作業に共同で責任を負う
nチームのゴールを持つ
nコンポーネントチームではなく
n外部のチームや⼈々との関係を管理する責任を負う

プロダクト
バックログ
顧客中⼼
フィーチャー
フィーチャーチーム:
- 安定かつ⻑寿命
- クロスファンクショナル
(機能横断的)
- コンポーネント横断
出荷可能な
プロダクトの
チームは、エンドツーエンドの顧客中⼼のフィーチャーを完了するために
必要な知識とスキルを持っています。
ない場合は、チームが学ぶか、必要な知識とスキルを獲得することが
期待されます。
http://less.works/

LeSS でのイベント
nスプリントプランニング(1部、２部)
nデイリースクラム
nスプリントレビュー
nスプリントレトロスペクティブ
n全体的なスプリントレトロスペクティブ
nプロダクトバックログリファインメント
n全体的なプロダクトバックログリファインメント
n(スクラムオブスクラム)

初期の
プロダクトバックログリファインメント
nプロジェクト最初に⾏う
n基本的にはプロダクトバックログリファインメント
と同じ
nビジョンを定義する
n完成の定義を作成する

スプリント
n1つの統合的な出荷可能なプロダクトのインクリメ
ントのために、1つのプロダクトレベルのスプリン
トがある

チームの
代表者
2hタイムボックス
2hタイムボックス
マルチチーム
スプリントプランニング
第２部
選ばれたプロダクト
バックログアイテム
選ばれたプロダクト
バックログアイテム
スプリント
プランニング
第2部
チームの
代表者
スプリント
プランニング
第１部
スプリントプランニング
http://less.works/

スプリントプランニング第1部
nタイムボックス:1時間/1週間スプリント
n参加者:各チーム毎に2名＋プロダクトオーナー
nチームの代表者たちは、依存関係を特定し、連携を
議論することによって、⾃分たちでプロダクトバッ
クログの割り振りを決定する

スプリントプランニング第2部
n各チーム毎に実施する
nチーム間の連携に課題がある場合
l他のチームのミーティングをオブザーブ出来る
nマルチチームスプリントプランニング第2部
l２つのチームが似たようなフィーチャーに取り組
むまたは、同じコンポーネントに影響を与える場
合に実施する

n各チーム毎に実施する
n情報共有を⾼めるために
他のチームのミーティングをオブザーブ出来る

スクラムオブスクラム
n チームの代表者たちは、情報共有と連携を⾼めるた
めに、週に数回開催することが出来る
n 各チームの代表者(Not スクラムマスター)

全体的な
プロダクト
バックログ
プロダクト
バックログ
チームの
代表者
チームの
代表者
チームの
代表者
潜在的な
アイテム
マルチチーム
バックログ
潜在的な
アイテム
スプリントの5-10%短めで(4h)
http://less.works/

n実施内容
l⼤きなプロダクトバックログアイテムの分割
lプロダクトバックログアイテムの詳細化
l⾒積もり
n同じ場所にいるのであれば
l同じ時間、1つの⼤きな部屋で実施する
l各チーム別の壁を利⽤するなど
nいくつかのレベルで実施される
l全体的
lチームレベル
lマルチチーム

全体的な
n参加者:チーム毎に2名、プロダクトオーナー
n次回実施するであろうプロダクトバックログアイテ
ムの分割に集中する
l軽量な分析
l⾒積り
Øチーム間で共通した⾒積りのベースラインを確保
するためにクロスチームで⾒積もる
l強い関連のあるプロダクトバックログアイテムの
特定
Ø共同での作業
Ø共通的な作業の提案または調整

チームレベルの
nプロダクトバックログアイテムが1チームで
完結している
n他のプロダクトバックログアイテムと
強い関連が無い

マルチチームの
n参加者:全てのチームメンバーまたは、
チーム毎に2名(関連するチームのみ)
n同じ時間、同じ場所で⾏う
n共通のプロダクバックログアイテムまたは強い関連
のあるプロダクバックログアイテムの連携強化

1.5hタイムボックス2hタイムボックス
全体的な
スプリント
レビュー
〜レトロスペクティブ
1.5h
http://less.works/

n参加者:各チームごとに2名＋プロダクトオーナー＋
ステークホルダー
nスプリントレビューバザール
l複数のエリアがある⼤きな部屋で実施
lエリア毎にチームの代表が、そのチームによって
開発されたフィーチャーをデモし、議論する
lステークホルダーは興味のあるエリアに訪れ、
チームはフィードバックを記録する
n最初と最後は、全体的なフィードバックと整合性を
⾼めるために、全員で議論する

スプリントレトロスペクティブ
n全てのチームを妨げている障害は、組織の改善バッ
クログに挙げる

全体的なレトロスペクティブ
nタイムボックス:45分/1週間スプリント
n参加者:各チームごとに1名＋スクラムマスター
n次のスプリントの最初の早い時期に開催
nプロダクトや組織全体のための改善策の特定と改善
計画を⾏う。

LeSS での作成物
nプロダクトバックログ
nスプリントバックログ
n出荷可能なプロダクトのインクリメント

n1つのプロダクトバックログ
n良いプロダクトバックログは以下を備えている:
l全て⾒積もられている
l上位は粒度が細かく、下位は粒度が粗い
l優先順位が付いている

nプロダクトバックログアイテムから選択された、
チームがこなす必要がある作業のリストである。
nチーム毎に存在する

出荷可能なプロダクトのインクリメント
nスプリントのアウトプット
n全てのチームの作業が統合されている
n出荷可能
lソフトウェアの市場性または価値ではない
l技術的にプロダクトが出荷可能であり、現在実装
したフィーチャーに必要な作業が完了している
n完成の定義に依存する

完成の定義
nプロダクトバックログアイテムについて合意した、
満たす基準の⼀覧
lプロダクト全体のために、⼀つの完成の定義が共
有される
lNot 受⼊基準
Ø全てのプロダクトバックログアイテムに均⼀に適
⽤される
n最初の完成の定義は、初期プロダクトバックログリ
ファインメントで⾏われる
n各チームは、独⾃拡張した完成の定義を持つことが
できる

未完了作業(Undone Work)
＝出荷可能ー完成の定義
l 未完了作業が存在する場合は以下を決定しなくてはならな
い
Øどのように未完了作業を対処するのか？
Øどのように将来的に未完了作業を少なくするための改善を
⾏うのか？
l リスクと遅延を引き起こす
Ø遅延：未完了作業を⾏う⼿間が必要になる
• プロダクトオーナーは、市場のニーズや変化に対応出来
ない→柔軟性の⽋如につながる
Øリスク：透明性の⽋如の原因となる
• プロダクトのリリースに近くまで、⾏わないことのリス
ク(パフォーマンステスト等)

LeSSまとめ
nガイドとルールのセットからなる
lLeSS Framework
lLeSS Rules
n２つのスケーリングフレームワークが存在する
lLeSS (2~8チームまで)
lLeSS Huge (1プロダクトで数千⼈規模)
nLeSS = スケールしたScrum

LeSS まとめ
n⼤規模であるがための⼯夫
lチームの代表者が参加するイベントが存在する
Ø スプリントプランニング第１部
Ø スプリントレビュー
lスクラムには無いイベントが定義されている
Ø 全体的なプロダクトバックログリファインメント
Ø 全体的なレトロスペクティブ
l協調と統合
Ø オブザーブ
Ø コミュニティと監視者(guardians)を構成する
Ø スクラムオブスクラム
Ø マルチチームのミーティング
Ø ボトルネックを活⽤し、壊し、スキルを⽣み出す
旅⾏者(経験豊富な技術の専⾨化)
Ø 主導的なチーム

©2016 Kenji Morita
共通点
l１つのプロダクトプロダクトバックログ
l１人のプロダクトオーナー
l無料(PDF, Webs)
l複数(〜8 or 9)のスクラムチーム
lスクラムチーム内はスクラムで
l代表者が集まって、バックログリファイ
ンメントを実施する。
lスクラムマスターは複数チーム兼務可能

©2016 Kenji Morita
特徴的な言葉（抜粋）
lNexus
「スクラムフレームワークと同様に、Nexusの役
割・作成物・イベント・ルールは不変である。
Nexusの一部だけを導入することも可能だが、そ
れはNexusではない。」
lLeSS
「LeSSは、大きな複数チームやマルチサイト、
あるいはオフショアのアジャイル開発を先導する
のに上手くいくことが分かった追加のルールと秘
訣のセットである。これらの秘訣は伝統的なスク
ラムのコンテクストにおける実験である。」

©2016 Kenji Morita
全体的な違い
lNexus
• Scrum並みに小さい！10P
• 最もScrumっぽいスケール手法
• 最小限で実行必須な事が決められている。
• 少ない決め事の割にオーバーヘッドはありそう。
lLeSS
• 全部やれとは言っていない。
• 上手くいった事を集めている。
• マネージャーの役割にも言及している。

©2016 Kenji Morita
チーム分割
lNexus
• 依存関係の最小化
• それ以上何も教えてくれない。ww
• スクラム同様ソフトウエア開発にも適用し
やすい？
lLeSS
• 基本的にフィーチャーチーム推奨
• わかりやすい。
• 詳細に解説されている。

©2016 Kenji Morita
Scrumには無いチーム
lNexus
• Nexus統合チームが存在する。
• 必須、マネージャーチームではない。
lLeSS
• プロダクトグループ(マネージャー)
• Undoneチーム
• プロダクトオーナーチーム

©2016 Kenji Morita
Undoneへの対処
lNexus
• Scrumble(Nexus Guide外)
lLeSS
• Undone チーム
https://kenschwaber.wordpress.com/2015/09/28/scaling-the-nexus-and-scrumbling/
Sprint Sprint Sprint SprintScrumble
http://less.works/less/structure/organizational-structure.html
（理想ではない）

©2016 Kenji Morita
LeSSに有ってNexusに無い物
lマネージャーの役割への言及
「中間管理職の役割は、全体を見て、
素晴らしい製品を作れるよう組織の能
力開発を行うことです。」
lビジネスパーソンの役割への言及
「製品開発におけるプロダクトオー
ナーは、ビジネス側から来るべきで
す。」

©2016 Kenji Morita
Nexusに有ってLeSSに無い物
l依存関係の最小化への強いこだわり
• 10Pで「依存関係」という言葉が３５回！
• Nexus統合チーム
• Nexusスプリントバックログ
• 毎日Nexus（代表者）デイリースクラム
• ３パートのレトロスペクティブ
• リファインメントの目的も依存関係最小化
l最後はNexusを解消？

©2016 Kenji Morita
比較のまとめ
lNexus
• ドキュメントが小さいので読みやすい。
• 理想的にチーム構成できる時にはシンプル。
• 依存関係の最小化と見える化にコストを使う。
• 大規模チームを分割する方向に向かいやすい。
lLeSS
• 複数チームになってしまった時の改善策になる。
• よく起きる課題に対する現実的な解決策がある。
• マネージャー、ビジネスパーソンの役割がわかる。
• LeSS Huge(９チーム〜)も公開されている。

©2016 Kenji Morita
最後に
lチームが大きくなっても、変わらないマ
インドセットで、楽しくアジャイルに開
発しましょう。
l今後事例を持ち寄ったり、知識の共有を
進めていきましょう。
https://www.facebook.com/groups/ScaledScrum/

Nexus and LeSS #rsgt2016

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Nexus and LeSS #rsgt2016

Ähnlich wie Nexus and LeSS #rsgt2016 (20)

Mehr von Takao Kimura

Mehr von Takao Kimura (17)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Nexus and LeSS #rsgt2016