LeSS概要

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

アジャイル コーチ KIMURA Takao 木村 卓央 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) アジャイルとスクラムを⼤規模に実装する⽅法 共訳 https://www.kanataku.com/ Copyright© Kanataku,LLC Takao Kimura. [email protected]

• https://amzn.to/2FPoHy5
• https://amzn.to/3kj7SuA
• https://www.kanataku.com/

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

• https://less.works/
• https://amzn.to/2DYXTI5
• https://less-study.doorkeeper.jp/

⼤規模スクラムはスクラムである Large-Scale Scrum is Scrum Copyright© Kanataku,LLC Takao Kimura.

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

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

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

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

• https://less.works/less/framework/differences-with-scrum

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

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

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

2つのフレームワーク LeSSフレームワーク ２~８チームで開発するプロダクトに適⽤ LeSS Hugeフレームワーク ９チーム以上で開発するプロダクトに適⽤ Copyright© Kanataku,LLC Takao Kimura.

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

• https://less.works/less/rules

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

• https://less.works/jp/less/framework/index.html

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

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

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

• https://amzn.to/2DYXTI5

コンポーネントチーム vs フィーチャーチーム Copyright© Kanataku,LLC Takao Kimura.

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

• https://less.works/jp/less/structure/organizational-structure.html
• https://less.works/less/rules/index.html

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

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

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

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

• https://newspicks.com/news/3864754/body/
• https://www.amazon.co.jp/

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

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

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

• https://less.works/less/rules/index.html

スプリントプランニング !"#$%&'( )*+,!"#$% &'()*'+),)-. Copyright© Kanataku,LLC Takao Kimura. スプリントプランニングは２つの パートで構成されています。スプ リントプランニング１は全ての チームが合同で実施します。それ に対してスプリントプランニング ２は通常、各チームごとに個別で ⾏われます。ただし、関連性が強 いアイテムがある場合は共有ス ペースで、複数チームスプリント プランニング２を⾏います。 『LeSSルール(2020 12月)』より 『大規模スクラム Large-Scale Scrum(LeSS)』 P.254 より

• https://amzn.to/2DYXTI5
• https://less.works/less/rules/index.html

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

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

プロダクトバックログリファインメント( PBR )

./01232*4567
89:;5<1=%
!"#$%
&'()*+,)'-./01232*

Copyright© Kanataku,LLC Takao Kimura.

プロダクトバックログリファイン
メント（ PBR ）は、シェアード・
ラーニング(訳注:学習したものを
共有する)を増やし、調整の機会と
して活⽤できるため、複数チーム
で⾏うのが望ましいです。
『LeSSルール(2020 12月)』より

『大規模スクラム Large-Scale Scrum(LeSS)』 P.229 より

• https://amzn.to/2DYXTI5
• https://less.works/less/rules/index.html

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

• https://amzn.to/2DYXTI5

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

• https://amzn.to/2DYXTI5
• https://less.works/less/rules/index.html

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

• https://amzn.to/2DYXTI5

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

• https://amzn.to/2DYXTI5

調整と統合 チームどうしの調整はチームに委ねられています。中央集権的な調整で はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重 要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである 「コードでのコミュニケーション」、チームをまたいだミーティング、 「コンポーネントメンター」、「トラベラー」、「偵察」、そして 「オープンスペース」を活⽤することです。 『LeSSルール(2020 12月)』より n n n n n n n n ただ話す コードでのコミュニケーション ブランチは使わない コミュニティ オープンスペース トラベラー コンポーネントメンター 偵察 Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.284 より

• https://amzn.to/2DYXTI5
• https://less.works/less/rules/index.html

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

• https://less.works/jp/less/less-huge/index.html

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

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

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

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

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

• https://amzn.to/2NpjHzK

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

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

実験︓LeSSに関する本 Practices for Scaling Lean & Agile Development 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 Copyright© Kanataku,LLC Takao Kimura.

• https://amzn.to/2DJAsRz
• https://amzn.to/2SUFLr2

おまけ Copyright© Kanataku,LLC Takao Kimura.

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

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

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

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

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