Nexus and LeSS #rsgt2016

©2016 Kenji Morita

Nexus と LeSS の

概要説明、比較

キヤノン株式会社守⽥憲司株式会社ガイアックス⽊村卓央

©2016 Kenji Morita

守田憲司

Kenji Morita

キヤノン株式会社デジタルシステム開発本部主幹研究員

@wsfjp

Nexus Guide 共訳

©2016 Kenji Morita

本日のテーマ

開発チームが１０人

超えたらどうする？

©2016 Kenji Morita

３人

3

©2016 Kenji Morita

６人

15

©2016 Kenji Morita

9人

36

©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出典：9TH ANNUAL State of Agile™ Survey (Version one)

使われているスケール手法の割合

Scrum / Scrum of Scrum 69%独自手法 25%SAFe 19%

＝＝＝＝＝＝＝＝＝＝＝LeSS 3%Nexus 未掲載

＊複数回答

©2016 Kenji Morita

「スクラムガイド」より

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

©2016 Kenji Morita

「スクラムガイド」より

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

©2016 Kenji Morita

コンウェイの法則

アーキテクチャは組織にしたがう組織はアーキテクチャにしたがう

©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

NexusThe 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


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

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 GaiaxCo.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_takubonhttp://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 FrameworklLeSS Rules(January 2016)

n２つのスケーリングフレームワークlLeSSØ2~8チーム(それぞれ8名)

lLeSS HugeØ1プロダクト数千⼈まで


LeSSの構成nガイドとルールlLeSS FrameworklLeSS HugelLeSS 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 Hugen８チーム以上に適したLeSSの第２のフレームワーク

n概念的には、LeSSフレームワークの上に複数のLeSSフレームワークを積み重ねてスケールアップされる

n基本的にはLeSSのフレームワークと同じ


LeSS RulesnLeSS Frameworkの定義が書かれているn最新版は 2016年1⽉版

nLeSS Framework RuleslLeSS StructurelLeSS ProductlLeSS Sprint

nLeSS Huge Framework RuleslLeSS Huge StructurelLeSS Huge ProductlLeSS 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 FrameworklLeSS Rules

n２つのスケーリングフレームワークが存在するlLeSS (2~8チームまで)lLeSS Huge (1プロダクトで数千⼈規模)

nLeSS = スケールしたScrum



LeSS まとめn⼤規模であるがための⼯夫lチームの代表者が参加するイベントが存在するØ スプリントプランニング第１部Ø スプリントレビュー

lスクラムには無いイベントが定義されているØ 全体的なプロダクトバックログリファインメントØ 全体的なレトロスペクティブ

l協調と統合Ø オブザーブØ コミュニティと監視者(guardians)を構成するØ スクラムオブスクラムØ マルチチームのミーティングØ ボトルネックを活⽤し、壊し、スキルを⽣み出す

旅⾏者(経験豊富な技術の専⾨化)Ø 主導的なチーム

©2016 Kenji Morita

Nexus と LeSS の比較

©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


Nexus

毎日

LeSS

オプション他チームにオブザーバー参加（時間をずらす必要あり？）

©2016 Kenji Morita


Nexus

課題特定アクション決め

スプリント終了

スプリント終了

LeSS

(次スプリントの早い時期に実施)

©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/

Technology

Nexus and LeSS #rsgt2016