エンタープライズアジャイル勉強会 LeSS概要

Copyright© Kanataku,LLC Takao Kimura.
⼤規模スクラム（Large Scale Scrum)概要
エンタープライズアジャイル勉強会

Certified Scrum Professional® – ScrumMaster™ and Product Owner ™ and Scrum Developer®
Advanced Certified ScrumMaster℠ / Certified Agile Leadership I
PROFESSIONAL SCRUM MASTER™ I / Ⅱ and SCRUM PRODUCT OWNER™ I
PROFESSIONAL AGILE LEADERSHIP™ / EVIDENCE-BASED MANAGEMENT
Project Management Professional (PMP)® / PMI Agile Certified Practitioner (PMI-ACP)®
PMI⽇本⽀部アジャイルプロジェクトマネジメント研究会会員
LeSS Study主催
Agile Discussion!主催
Fearless Changeアジャイルに効くアイデアを広めるための48のパターン共訳
⼤規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを⼤規模に実装する⽅法共訳
木村卓央
KIMURA Takao
アジャイルコーチ
https://www.kanataku.com/ info@kanataku.com

LeSS Study
n⼤規模アジャイル開発のフレームワークである
LeSS Learge-Scale Scrum の勉強会です。
nLeSSのサイトである less.worksを翻訳しながら学び合う場と
して2015年から開催
n『⼤規模スクラム Learge-Scale Scrum(LeSS)』
が丸善出版より出版されたことを期に
読書会として進めることに。
LeSS Study doorkeeper
https://less-study.doorkeeper.jp/

⼤規模スクラムはスクラムである
Large-Scale Scrum is Scrum

⼤規模スクラムはスクラムである
nLeSS はスクラムと同様にバランスを取っている
l抽象的な原理・原則
l具体的なプラクティス
n⾃分たちの仕事の仕⽅を継続的に改善できるように
l徹底的な透明性の維持
l検査と適応のサイクルを重視
lスクラムに具体的な構造を追加

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

LeSSの⽅向性
n 少なくすることでもっと多く(More with LeSS)
l シンプルであるべき
Ø 余計な役割/成果物/プロセスを追加してしまう罠にはまらないよう
にする
n ⼤規模スクラムはスクラムである(Large-Scale Scrum is Scrum)
l スケールしたスクラム
Ø スクラムを理解した上で、同様の効果を⼤規模開発において実現す
る⽅法を模索する
n 削ぎ落しではなくスケールアップ(LeSS→LeSS Huge)
l 汎⽤的なフレームワークからスタートして削ぎ落としていく⽅法で
は、メタボなプロセスになる
Ø 常に「最⼩限」から始めて必要最低限のものをビルドアップ
10

LeSSはスクラムではない(LeSS is not Scrum)
このページは現在作成中です。
LeSS はスクラムの影響を強く受けていますが、まったく同じではありません。
LeSS とスクラム(2017)との主な違いをいくつか挙げます。
n スクラムチームという概念は、LeSS には存在しない
n スクラムでは開発チームと呼ばれているものは、LeSS では単にチームと呼ばれる
n ⾃⼰組織化チームは、⾃⼰管理チームと呼ばれる
n スプリントプランニングは、スプリントプランニング1と2に分かれている
n バックログリファインメントは、アクティビティではなくイベントである
n スプリントゴールは LeSS の⼀部ではないが、LeSS と併⽤すると役に⽴つプラクティスと考えられている
n スクラムマスターはフルタイムの役割であり、チームのメンバーではない
n プロダクトオーナーは、チームのデイリースクラムやレトロスペクティブの参加者として期待されてはいな
い
今のところ、スクラム(2020)は無視している。 https://less.works/less/framework/differences-with-scrum

LeSS complete picture
LeSSは原理・原則をコアにして、複数
チームのコンテキストにスクラムを適⽤す
るためのルールとガイドのセットからなる
n 原理・原則
l LeSSのコア
n フレームワーク
l ルールで定義している
n ガイド
l ルールを効率的に適応するためのもの
l 試す価値がある実験の集まり(経験知)
n 実験
l 限定的な環境で機能する

⼤規模スクラムは
スクラムである透明性
少なくすることで
もっと多く
プロダクト全体
思考
顧客中⼼
完璧を⽬指しての
継続的改善
リーン思考
システム思考
経験的プロセス
制御
待ち⾏列理論
原理・原則 - LeSSのコア
出典: https://less.works/less/principles/index.html

2つのフレームワーク
LeSSフレームワーク
２~８チームで開発するプロダクトに適⽤
LeSS Hugeフレームワーク
９チーム以上で開発するプロダクトに適⽤

LeSS ルール(2020 12⽉)
nフレームワークはルールによって定義されている
nシンプルなルールである
l意図的に不完全になっている
lスケールするために必要な部分のみが定義されている
nフレームワークごとに以下の構成で書かれている
l構造
lプロダクト
lスプリント
https://less.works/less/rules

LeSS フレームワーク
h/ps://less.works/jp/less/framework/index.html
2〜”8”チームで開発するプロダクトに適⽤します。

LeSS ルール︓LeSS の構造
n 実際のチームを組織の基本構成要素として組織を構成します。
n それぞれのチームは、（１）⾃⼰管理、（２）クロスファンクショナル、（３）同⼀ロケーション、（４）
⻑期間存続です。
n チームの⼤半は顧客中⼼のフィーチャーチームです。
n スクラムマスターは LeSS の導⼊が問題なく⾏われることに責任を持ちます。注⼒する対象は、チーム、プ
ロダクトオーナー、組織、技術的⼿法であり、１チームだけの改善に留まることなく、組織全体の改善を⾏
う必要があります。
n スクラムマスターは専任でフルタイムのロールです。
n １⼈のスクラムマスターが１〜３チームを担当することができます。
n LeSS ではマネージャーは必須ではありません。もしマネージャーがいる場合でも多くの場合、その役割は
おそらく変わります。マネージャーがフォーカスすべきことは、⽇々の作業の管理からプロダクトを開発す
るシステム全体の価値提供能⼒の向上に移ります。
n マネージャーの役割はプロダクト開発の仕組みの改善を促進することです。「現地現物」の実践、「⽌めて
直す」の推奨、「適合するよりも実験をする」ことを通じて改善を促進します。
n プロダクトグループは、「最初から」完全な LeSS の構造を適⽤します。これは LeSS を導⼊する際の肝と
なることです。
n プロダクトグループを越える、より⼤きな組織には、「現地現物」の考え⽅を使い、実験や改善があたりま
えとなる環境を作っていくことで段階的に LeSS 導⼊を進めます。

LeSS のスクラムマスター
n 基本的に１チームのスクラムと同じ
l 組織に対してスクラムを教え、コーチし、それが終わることはない
l スクラムチームが成功するための環境を作る
nチームにプロダクト全体を意識するよう働きかける
l ⼤きなプロダクトグループの⼈々の相互作⽤、遅延、原因、ポテン
シャル（潜在リスク）などの各個⼈の考えの範囲を超えてサポート
l プロダクト全体の狙いをチームに意識付けをおこなう
n 透明性を保つよう働きかける
n フルタイムで専任、場合によっては３チームまで兼務は可能
n 組織の完璧なビジョンに向かっていくために、レトロスペクティブと
改善を助け、⽀援する

フィーチャーチーム
n ⻑期間存続する
l チームはより⾼いパフォーマンス
を発揮するために、⼀緒に居続け
る。そして時間を掛けて新しい
フィーチャーを引き受ける
n クロスファンクショナルでクロスコ
ンポーネント
n 理想的には同じ場所にいる
n 全てのコンポーネントや領域(分析、
プログラミング、テスト)を超え、
完全なる顧客中⼼のフィーチャーで
作業する
n 専⾨家で構成される
n スクラムでは、通常は7±2⼈
『大規模スクラム Large-Scale Scrum(LeSS)』 P.77 より

コンポーネントチーム vs フィーチャーチーム

LeSS の組織構造
n よく⾒られる組織構造
プロダクトグループ
の責任者
ほとんどの LeSS 組織ではマネージャーが存在する
現地現物によってチームを⽀援。障害を取り除く
Undone 部⾨理想的には存在しない部⾨
システム保証などの名前で存在することがある
https://less.works/jp/less/structure/organizational-structure.html
LeSS ではマネージャーは必須ではあり
ません。もしマネージャーがいる場合
でも多くの場合、その役割はおそらく
変わります。マネージャーがフォーカ
スすべきことは、⽇々の作業の管理か
らプロダクトを開発するシステム全体
の価値提供能⼒の向上に移ります。マ
ネージャーの役割はプロダクト開発の
仕組みの改善を促進することです。
「現地現物」の実践、「⽌めて直す」
の推奨、「適合するよりも実験をす
る」ことを通じて改善を促進します。
『 LeSSルール(2020 12月) LeSSの構造』より

LeSS ルール︓LeSS のプロダクト
n １⼈のプロダクトオーナーと１つのプロダクトバックログがあり、出荷可能なプロダクト全体を
運⽤します。
n プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。
複数のチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダク
トオーナーをサポートします。
n 全ての優先順位付けはプロダクトオーナーが⾏います。が、要求や仕様を明確にするのは出来る
限りチームと、顧客やユーザーそしてステークホルダーとの間で直接⾏います。
n プロダクトの定義は現実的な範囲で、エンドユーザーまたは顧客中⼼でなければなりません。プ
ロダクトの定義は広い⽅が好ましく、時間の経過とともに拡張する可能性があります。
n プロダクト全体で全チーム共通の１つの Done の定義を持ちます。
n 各チームは共通の Done の定義を拡張してより厳しい独⾃のものを定めても構いません。
n 究極のゴールは Done の定義を拡張し、毎スプリント（あるいはより⾼い頻度で）出荷可能なプ
ロダクトを作れるようになることです。

LeSS のプロダクトオーナー
n 基本的に１チームのスクラムと同じ
n プロダクトオーナーが内側（チーム）と外側（ステークホルダー、顧
客・ユーザー）と同じように時間を費やす
l 新しいビジネスの戦略的な機会の模索
l スケールという観点では、プロダクトへの投資収益率( ROI )を最⼤
化してリターンを確保するためにわずかに異なる点がある
n 明確化より優先順位付け
l 優先順位付けはプロダクトオーナー
l 明確化はチームで協業する
Ø ユーザー・顧客とチームの直接会話する事を奨励する
Ø コネクターとしてのプロダクトオーナー

ガイド︓はじめに
LeSS 導⼊の成功率を⾼めるには
1 全員を教育する LeSS を理解する
LeSS の導⼊の⽬的を理解する
2 「プロダクト」を定義するプロダクトを定義することによって、導⼊範囲、プロダクトバックログの
内容、適切なプロダクトオーナーが決まる
3 「Done」を定義する Doneの定義により、組織変更の規模が変わる
4 正しい構造を有したチーム
をつくる
専任、安定、⻑期間存続、クロスファンクショナル、同⼀ロケーション
機能部⾨から離れたフィーチャーチームを組織する
5 プロダクトオーナーのみが
チームに仕事を与える
最初のチームは将来のチームの⾜場となる基盤を築くため、通常よりもさ
らにチームは集中する必要がある
6 プロジェクトマネージャー
をチームに近づけない
LeSS では、プロジェクトマネージャーの役割がなくなる

ガイド︓あなたのプロダクトを定義する
n LeSS では広いプロダクトの定義が好ましいが現実的な範囲でなけれ
ばならない
画像: NEWS PICKS アマゾン、倉庫の完全⾃動化の可能性排除「あと10年かかる」 2019年
https://www.amazon.co.jp/

Done の定義
n Done の定義は全チーム共通
l 可能な限り強い Done の定義を設定する
l 弱い Done の定義
Ø リスクと透明性の⽋如
Ø 遅延と柔軟性の⽋如
n チーム単位で、強い Done の定義に拡張できる
l チームは⾃分たちで改善をコントロールできる
Ø 少しずつ、他のチームにも共有していく
n Done の定義を拡張に、組織変更が必要なものもある
l 例えば、Undone 部⾨を各チームに⼊れる

LeSS ルール︓LeSS のスプリント
n １つのプロダクトに関わる全てのチームは同じスプリントで作業します。スプリントの開始も終了も全チーム共通です。スプリントの終わ
りにはプロダクト全体が１つに統合されている状態にします。
n スプリントプランニングは２つのパートで構成されています。スプリントプランニング１は全てのチームが合同で実施します。それに対し
てスプリントプランニング２は通常、各チームごとに個別で⾏われます。ただし、関連性が強いアイテムがある場合は共有スペースで、マ
ルチチーム・スプリントプランニング２を⾏います。
n スプリントプランニング１にはプロダクトオーナーとチーム全員またはチームの代表者が参加します。参加者は⼀緒に、各チームがこのス
プリントで作業するアイテムを暫定的に選択します。チームは協働する部分を特定し、質問を明確にします。
n 各チームにはチームごとのスプリントバックログがあります。
n スプリントプランニング２は各チームがどのようにアイテムを実現させるかを考える場であり、設計やスプリントバックログの作成を⾏い
ます。
n デイリースクラムはチームごとに⾏います。
n チームどうしの調整はチームに委ねられています。中央集権的な調整ではなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。
重要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである「コードでのコミュニケーション」、チームをまたいだミーティン
グ、「コンポーネントメンター」、「トラベラー」、「偵察」、そして「オープンスペース」を活⽤することです。
n プロダクトバックログリファインメント（PBR）は、シェアード・ラーニング（訳注:学習したものをシェアする）を増やし、調整の機会と
して活⽤できるため、複数チームで⾏うのが望ましいです。
n スプリントレビューは全てのチームが共同で⾏います。検査と適応を⾏うのに適切な情報を得られるよう、必要なステークホルダーが参加
するようにします。
n スプリントレトロスペクティブは各チームで⾏います。
n オーバーオール・レトロスペクティブは各チームのレトロスペクティブの後に⾏われます。ここでは複数チームやシステム全体にまたがる
課題を扱い、改善に向けての実験を議論します。この場にはプロダクトオーナー、全スクラムマスター、チーム代表者と、（いるなら）マ
ネージャーが参加します。

LeSS のスプリント
１つのプロダクトに関わる全てのチームは同じスプリントで作業します。
スプリントの開始も終了も全チーム共通です。スプリントの終わりには
プロダクト全体が１つに統合されている状態にします。
『LeSSルール(2020 12月)』より

スプリントプランニング
スプリントプランニングは２つの
パートで構成されています。スプ
リントプランニング１は全ての
チームが合同で実施します。それ
に対してスプリントプランニング
２は通常、各チームごとに個別で
⾏われます。ただし、関連性が強
いアイテムがある場合は共有ス
ペースで、複数チームスプリント
プランニング２を⾏います。
!"#$%
&'()*'+),)-.
!"#$%&'(
)*+,-

スプリントプランニング１
n プロダクトオーナーはカードをテーブルに広げる
n チームがどのアイテムを持っていくか決める
l ディスカッションする
n チームが取ったアイテムの優先順位が全体最適になっているか確認す
る
n 共通でやらなければならない作業
の明確化
l 複数チーム
スプリントプランニング２

複数チームスプリントプランニング２
n １つの部屋で、複数チームで⾏う
n 設計した内容をシェアする
l ホワイトボードにモデルを書く
l ツールは使わない（視野が狭まる）
n 各チームが個別にタスクを作る
l コミュニケーションを取りながら

プロダクトバックログリファインメント( PBR )
プロダクトバックログリファイン
メント（ PBR ）は、シェアード・
ラーニング(訳注:学習したものを
共有する)を増やし、調整の機会と
して活⽤できるため、複数チーム
で⾏うのが望ましいです。
!"#$%
&'()*+,)'-./01232*
./01232*4567
89:;5<1=%

プロダクトバックログリファインメント( PBR )
n 実施する内容は、基本的にスクラムと同じ
n ３チーム未満の場合は、オーバーオールと複数チームPBRを組み合わせたものを
１回だけ⾏う、３チーム以上の場合は、オーバーオールPBRの後に、複数チーム、
単⼀チームPBRを組み合わせて⾏うことが多い
n 特定のチームにアイテムを事前に割り当てることは基本的には⾏わない
l ⾃分たちが⾏わないと知っていると関⼼を持たなくなる(プロダクト全体思考)
『大規模スクラム Large-Scale Scrum(LeSS)』より
最初のPBR 導⼊する際に１度だけ⾏われる
最初のスプリントを始めるのに⼗分なアイテムをリファインメントする
オーバーオール
PBR
複数チームや単⼀チームPBRに先だって⾏われるプロダクト全体に注⽬したPBR
どのチームがそのアイテムをリファインメントするのかを模索する
複数チームPBR ２つ以上のチームが⾃分たちが実装しそうなアイテムをリファインメントする
単⼀チームPBR １つのチームが⾃分たちが実装しそうなアイテムをリファインメントする
このチームが特定のアイテムを実装することが確実な場合のみ実施

スプリントレビュー・レトロスペクティブ
スプリントレビューは全てのチームが共同
で⾏います。検査と適応を⾏うのに適切な
情報を得られるよう、必要なステークホル
ダーが参加するようにします。
スプリントレトロスペクティブは各チーム
で⾏います。
オーバーオール・レトロスペクティブは各
チームのレトロスペクティブの後に⾏われ
ます。ここでは複数チームやシステム全体
にまたがる課題を扱い、改善に向けての実
験を議論します。この場にはプロダクト
オーナー、全スクラムマスター、チーム代
表者と、（いるなら）マネージャーが参加
します。『LeSSルール(2020 12月)』より

スプリントレビュー
n デモではなく、ディスカッションに重きを置く
n 報告ではなく学びの共有
n バザール形式（ガイド︓レビュー・バザール）
l 広い部屋に複数のブースを作成
Ø 各ブースには担当者がいて、質問などに答える
Ø プロダクトオーナー、ステークホルダー、他のチームメンバーなど
が、実際に動くソフトウェアを触る
Ø メモ(フィードバックや質問)を書くのが⼤事
l 全員が集まって、プロダクトオーナーを中⼼にメモについて議論す
る
Ø 市場や顧客、今後のビジネスやプロダクトに対する市場のフィード
バック、次のスプリントの⽅向性などを議論する

レトロスペクティブ
n チームレトロスペクティブ
l スクラムと同じ
n オーバーオールレトロスペクティヴ
l 次のプランニングの最初の⽅に⾏う(理想は前に⾏う)
l システム思考
Ø システム全体を改善することを考える場
l LeSS の原理・原則の1つは、完璧を⽬指しての継続的改善
l 2つの重要なステップ
Ø システム全体を分析する
Ø システム全体を改善するための実験案を設計する
•新しい実験を1つだけ集中して取り組む

調整と統合
チームどうしの調整はチームに委ねられています。中央集権的な調整で
はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重
要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである
「コードでのコミュニケーション」、チームをまたいだミーティング、
「コンポーネントメンター」、「トラベラー」、「偵察」、そして
「オープンスペース」を活⽤することです。
n ただ話す
n コードでのコミュニケーション
n ブランチは使わない
n コミュニティ
n オープンスペース
n トラベラー
n コンポーネントメンター
n 偵察

LeSS Huge フレームワーク
https://less.works/jp/less/less-huge/index.html
「9チーム以上」で作る場合に適⽤します。
これよりも⼩さな規模で LeSS Huge を適⽤することは推奨しません。不必要なオーバーヘッドや
部分最適の原因となります。
特に明記しない限り、すべての LeSS のルールは LeSS Huge にも適⽤されます。各要求エリアは、
基本的な LeSS のフレームワークのようにふるまいます。

LeSS ルール︓LeSS Huge の構造
n 顧客視点で関連の強い顧客の要求は、要求エリアにまとめられます。
n 各チームは１つの要求エリアを専⾨的に対応します。チームはエリアに⻑期間固
定するものです。ただし、他のエリアの価値がより⾼くなった場合、そちらに移
動することがあります。
n 各要求エリアにはエリアプロダクトオーナーが１⼈ずついます。
n 各エリアは「４〜８」チームで構成されます。このチーム数の範囲を守るように
します。
n LeSS Huge の導⼊は、構造上の変更も含め、進化させながらインクリメンタル
なアプローチで進めます。
n 毎⽇思い出して下さい。LeSS Huge の導⼊は数ヶ⽉〜数年を要します。無限の
忍耐とユーモアのセンスを持って進めてください。

LeSS ルール︓LeSS Huge のプロダクト
n 全体の（オーバーオール）プロダクトオーナーの役割はプロダクト全体の優先順
位決めと、どのチームがどのエリアを対応するかを決めることです。エリアプロ
ダクトオーナーとは密にコミュニケーションを取る必要があります。
n エリアプロダクトオーナーは当該エリアのチームに対してプロダクトオーナーと
してふるまいます。
n プロダクトバックログは１つです。そして全てのアイテムはどこか必ず１つの要
求エリアに属します。
n 要求エリアごとに１つのエリアプロダクトバックログが存在します。このバック
ログは概念的には、プロダクトバックログをより詳細な視点で記述しているもの
です。

LeSS ルール︓LeSS Huge のスプリント
n プロダクト単位でスプリント期間は共通です。各要求エリアで別々のスプリント
期間にすることはありません。スプリントの終わりには統合された１つのプロダ
クトになっている必要があります。
n プロダクトオーナーとエリアプロダクトオーナーは頻繁に会話し、スプリントプ
ランニング時にチームが最も価値の⾼いアイテムに着⼿できるように準備する必
要があります。また、スプリントレビュー後にはプロダクト規模の適応がより⼀
層可能となります。

ガイド︓⼤規模スクラム
ルールを効率的に適応するためのガイドであり、何年にも及ぶ
LeSS の経験の中で試す価値があるとされた実験の集まり。
ガイドはヒントであり、改善の余地がある部分でもある。
⼤規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを⼤規模に実装する⽅法丸善出版 2019年
著:Craig Larman, Bas Vodde 監修:榎本明仁翻訳:⽊村卓央, ⾼江洲睦, 荒瀬中⼈, ⽔野正隆, 守⽥憲司

ガイド
3. 導⼊ 51
3つの導⼊原則
はじめに 57
⽂化は構造に従う 62
役割は守らないが雇⽤は守る 64
完璧を⽬指しての組織ビジョン 64
継続的改善 67
導⼊の拡⼤ 69
進化させながらインクリメンタルな導⼊ 71
要求エリアを1つずつ 71
並列組織 72
4. 顧客価値による組織化 73
チームベースの組織を構築する 74
フィーチャーチームを理解する 76
フィーチャーチーム導⼊マップ 84
顧客ドメインでの専⾨化を優先 90
LeSSの組織構造 92
複数拠点でのLeSS
要求エリア 96
流動的な要求エリア 96
フィーチャーチームへの移⾏ 100
LeSS Hugeの組織 102
5. マネジメント 106
テイラーとファヨールを理解する 108
Y理論によるマネジメント 110
マネージャーは任意 112
LeSSの組織 113
現地現物 117
教師および学習者としてのマネージャー 119
ドメインと技術⼒の両⽅ 120
少ない⽬標とLeSSのメトリクス 121
マネジメントに関する推奨書籍リスト 122
6. スクラムマスター 124
スクラムマスターが重視すること 126
スクラムマスターの5つのツール 129
巨⼤なグループのファシリテーション 131
学習と複数のスキル習得を促進する 132
コミュニティ活動 132
スクラムマスターサバイバルガイド 134
スクラムマスターへの推奨書籍 137
特に注意を払う領域 138
要求エリアのサイロ化を避ける 139
7. プロダクト 143
あなたのプロダクトは何ですか? 145
あなたのプロダクトを定義する 150
プロダクトの定義を広げる 154
プロジェクトやプログラムよりもプロダクト 155
8. プロダクトオーナー 157
誰がプロダクトオーナーになるべきか? 158
⼀時的な仮のプロダクトオーナーと早めに、または適
当に始める 161
ユーザー/顧客は誰? 162
明確化より優先順位付け 163
やってはいけないこと 164
プロダクトオーナーのヘルパー 165
5つの関係 166
何よりも顧客との協調を 173
少なくともスプリントごとに出荷する 174
良い⼈になるな 175
放棄しよう 176
Undoneワークに負けるな 177
LeSSのミーティング 177
LeSS Hugeのプロダクトオーナー 179
エリアプロダクトオーナー 180
スクラムマスターの助けを借りるPOチーム 181
9. プロダクトバックログ 182
「依存関係の管理」ではなく，制約の最⼩化 183
少しかじる 187
親の対処 189
特別なアイテムの取扱い 192
⼤規模プロダクトバックログ⽤のツール 195
アウトカムを多く，アウトプットを少なく 197
エリアバックログ 200
最⼤3レベルまで 204
巨⼤な要求のための新しいエリア 205
巨⼤な要求を扱う 206
10. Doneの定義 210
Doneの定義を作成する 211
Doneの定義を育てる 220
11. プロダクトバックログリファインメント
225
プロダクトバックログリファインメントの種類 227
オーバーオールPBR 228
複数チームPBR 230
複数拠点でのPBR 231
最初のPBR 232
分割 238
⼤規模での⾒積り 246
12. スプリントプランニング 250
スプリントプランニング1 251
複数チームスプリントプランニング2 255
スプリントバックログにソフトウェアのツールは使わ
ない 256
プロダクトオーナーのチームミーティング 258
13. 調整と統合 259
ただ話す 260
調整しやすい環境 262
コードでのコミュニケーション 265
継続的にインテグレーションする 267
コミュニティ 269
クロスチームミーティング 272
複数チームの設計ワークショップ 274
現在のアーキテクチャーワークショップ 276
コンポーネントメンター 277
オープンスペース 279
トラベラー 280
偵察 282
スクラムオブスクラムズをしない⽅がいいかも 282
リーディングチーム 282
テクニックを混ぜ合わせる 284
14. レビューとレトロスペクティブ 286
早く頻繁にプロダクトを適応させる 287
レビュー・バザール 288
オーバーオールレトロスペクティブ 290
システムを改善する 292
複数エリアでのレビューとレトロスペクティブ 297

実験︓LeSSに関する本
Scaling Lean & Agile
Development
Practices for
Scaling Lean & Agile
Development
Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (English Edition) Addison-Wesley Professional 2010年
著: Craig Larman, Bas Vodde
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (English Edition) Addison-Wesley Professional 2008年著: Craig Larman, Bas Vodde

おまけ

ロール
n プロダクトオーナー︓1⼈
l 全てのアイテムの詳細を把握することは不可能
l 優先順位は、プロダクトの⽅向性により決定する
l 規模、難易度などは、POにとって必要な情報
n スクラムマスター︓専任、1~3チームを担当
l 組織に対する働きかけが多くなる
n チーム︓スクラムで⾔う開発チーム（同じ）
l 各チームは同じ場所で働く
l チームの⼤半は顧客中⼼のフィーチャーチーム
n LeSSでは、プロダクトグループ（明確には定義していない）
l スクラムチームでは無い

作成物
nプロダクトバックログ
lLeSSでは、あまり粒度を⼩さくしない
Ø各チームが、１スプリントで4アイテムくらい
nスプリントバックログ
lスクラムと同じ
n出荷可能なプロダクトのインクリメント
lPotentially Shippable Product Increment
lLeSSでは、あえて古い⽤語を使う

イベント
n スプリントプランニング１
l どのチームがどのアイテムをやるのかを決める
Ø 均等に優先順位を振り分ける
l 複数チームの代表者
n スプリントプランニング２
l 各チームがチームごとに⾏う
Ø 実施するアイテムに関連がある場合は、複数チームで⾏う
l アイテムの詳細な確認はリファインメントで⾏う
n スプリント
l 1~4週間
l 全てのチームは、同じスプリント

イベント
n スプリントレビュー
l 全てのチームで共有
l 今後のプロダクトの⽅向性をフィードバックしてもらう
l プロダクトの種類によっては、レビューが難しいものもある
n レトロスペクティブ
l 各チームで⾏う
Ø ごくたまに、複数チームで⾏う
n オーバーオールレトロスペクティブ
l 組織、システム全体、複数チームで起きた問題を取り上げる
l 組織の課題を洗い出す
Ø 次のスプリントで改善出来るようなものではない
l 次のスプリントの⽕曜⽇に⾏うことが多い

イベント
nプロダクトバックログリファインメント
lアイテムの明確化と⾒積もりを⾏う
lどのチームでやるのかを検討する
Ø最終決定はスプリントプランニング
lPOは任意

エンタープライズアジャイル勉強会 LeSS概要

More Related Content

What's hot

Similar to エンタープライズアジャイル勉強会 LeSS概要

More from Takao Kimura

エンタープライズアジャイル勉強会 LeSS概要