アジャイルコーチから見たScaled Agile Method LeSS版

アジャイルコーチから⾒た Scaled Agile Method.. 〜SAFe and LeSSから学ぶ勘所〜 原田 巌/木村 卓央/水野 正隆 Agile Talks vol.1, 2019.12.09

LeSS派 SAFe派 司会進行 原⽥巌 オージス総研アジャイルコーチ （期限切れ） ⽊村卓央 合同会社カナタク 代表社員 アジャイルコーチ ⽔野正隆 オージス総研 アジャイルコーチ

LeSS Part Copyright© Kanataku,LLC Takao Kimura.

⾃⼰紹介 アジャイル コーチ KIMURA 木村 Takao 卓央 Certified Scrum Professional – ScrumMaster™ and Product Owner ™ / Certified Scrum Developer® Project Management Professional (PMP)® PMI Agile Certified Practitioner (PMI-ACP)® EXIN Agile Scrum Foundation PMI⽇本⽀部 アジャイルプロジェクトマネジメント研究会 会員 LeSS Study主催 Agile Discussion!主催 Fearless Changeアジャイルに効くアイデアを広めるための48のパターン共訳 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 共訳 [email protected] https://www.facebook.com/kanataku.LLC/ https://about.me/tw_takubon Copyright© Kanataku,LLC Takao Kimura.

• https://www.facebook.com/kanataku.LLC/
• http://about.me/tw_takubon
• http://kanataku.com

⼤規模スクラム Large-Scale Scrum (LeSS) Copyright© Kanataku,LLC Takao Kimura. https://less.works/

• https://less.works/

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

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

原理・原則 ⼤規模スクラムはスクラム LeSSはスクラムの原理・原則、ルール、要素、⽬的を⼤規模開発のコンテキストに可能 な限りシンプルに適応したもの 透明性 スクラムと同じ。完成したアイテム、短いサイクル、協働、共通の定義、現場から恐れを 取り除くことがベースになる 少なくすることでもっと多く 多くしてしまうと思考停⽌、改善の余地が減る 少なくすることでチームが多くの責任を持つ。 チームがプロセスと意義のある仕事のオーナーシップを持つ プロダクト全体思考 顧客が望んでいるひとまとまりのプロダクトとしての価値ある機能を提供する 顧客中⼼ 顧客にフォーカスし続ける ⾃分の仕事がお⾦を払うお客様に対してどのような価値提供につながっているのかを理解 する 完璧を⽬指しての継続的改善 パーフェクトビジョン＝達成出来ないほどの⽬標に継続的に改善して近づける 例︓コストをかけずに障害のないプロダクトを常に提供し続け、⽣活を豊かにする リーン思考 ⼈間性尊重と継続的改善の2つの柱を組織に根付かせ、完璧な⽬標を⽬指す システム思考 システム全体(アイデアから売上を得るまでに関わる⼈・物などすべて)を最適化する システムモデルを使いシステムの関係性を理解する 経験的プロセス制御 スクラムと同じ 継続的にプロダクト、プロセス、ふるまいの検証と適応を⾏う 待ち⾏列理論 どこにキューがあるのか。リードタイムを短くするにはどうするのか Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.8 より

• https://amzn.to/2DYXTI5

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

スクラムの成功は抽象的な原理・原則と 具体的な⼿法の絶妙なバランスにある n 抽象的な原理・原則 l 透明性・検査・適応 n 具体的な⼿法 l 3つのロール l 5つの価値基準 l 3つの作成物 l 経験的プロセス制御 l 4つのイベント Bas Vodde Copyright© Kanataku,LLC Takao Kimura. Craig Larman 出典 : https://less.works/resources/about.html

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

フレームワーク n - ルール LeSS Rules (April 2018) LeSSフレームワーク 2~”8”チームで開発するプロダクトに 適⽤ n LeSS Hugeフレームワーク “9”チーム以上で開発するプロダクトに 適⽤ Copyright© Kanataku,LLC Takao Kimura.

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

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

LeSSの構造 顧客価値による組織化 チーム フィーチャーチーム 組織構造 スクラムマスター コミュニティ Copyright© Kanataku,LLC Takao Kimura. https://less.works/less/structure/index.html

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

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

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

ロール n プロダクトオーナー︓1⼈ 前提︓全てのアイテムの詳細を把握することは不可能 l 明確化よりも優先順位付けに重きをおく l チームとユーザー(ステークホルダー)をつなぐコネクター n スクラムマスター︓専任、1~3チームを担当 l LeSSの導⼊が問題なく⾏われることに責任を持つ l 1チームだけではなく、組織全体の改善を⾏う n チーム︓スクラムで⾔う開発チーム l フィーチャーチーム n LeSSでは、プロダクトグループ（明確には定義していない） l スクラムチームでは無い l Copyright© Kanataku,LLC Takao Kimura.

フィーチャーチーム 実際のチームを組織の基本構成要素とし て組織を構成します。 それぞれのチームは、(1)⾃⼰管理、(2) クロスファンクショナル、(3)同⼀ロ ケーション、(4)⻑期間存続です。 チームの⼤半は顧客中⼼のフィーチャー チームです。 『LeSSルール(2018 4月)LeSSの構造』より 『大規模スクラム Large-Scale Scrum(LeSS)』 P.77 より Copyright© Kanataku,LLC Takao Kimura.

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

コンポーネントチーム vs フィーチャーチーム ⾮同期依存関係 Copyright© Kanataku,LLC Takao Kimura. 同期依存関係 コンポーネントをいじるときに依存関係が発⽣する 個⼈が協⼒しあう環境

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

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

LeSSのプロダクト Copyright© Kanataku,LLC Takao Kimura.

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

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

LeSSのプロダクト 1⼈のプロダクトオーナーと1つのプロダクトバックログがあり、 出荷可能なプロダクト全体を運⽤します。 １つのプロダクトに関わる全てのチームは同じスプリントで作業します。 スプリントの開始も終了も全チーム共通です。スプリントの終わりには プロダクト全体が１つに統合されている状態にします。 Copyright© Kanataku,LLC Takao Kimura. 『LeSSルール(2018 4月)』より

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

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

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

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

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

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

プロダクトバックログリファインメント(PBR) プロダクトバックログリファイン メント（PBR）は、シェアード・ ラーニング(訳注:学習したものを シェアする)を増やし、調整の機会 として活⽤できるため、複数チー ムで⾏うのが望ましいです。 『LeSSルール(2018 4月)』より Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.229 より

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

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

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

調整と統合 チームどうしの調整はチームに委ねられています。中央集権的な調整で はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重 要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである 「コードでのコミュニケーション」、チームをまたいだミーティング、 「コンポーネントメンター」、「トラベラー」、「偵察」、そして 『LeSSルール(2018 4月)』より 「オープンスペース」を活⽤することです。 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の導⼊ 3つの原則 はじめに コーチング 継続的改善 Copyright© Kanataku,LLC Takao Kimura. フィーチャーチーム 導⼊マップ https://less.works/less/adoption/index.html

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

ガイド︓3つの導⼊原則 n 広く浅くよりも、狭く深く １つのプロダクトを上⼿く回してから n トップダウンとボトムアップ l トップダウトとボトムアップの両⽅が必要 l 特にマネジメント(通常はプロダクトグループの責任者)の⽀援が重要 Ø コントロールでなく⽀援をする Ø 以下をはっきりと伝えて⾏動に移す LeSSを導⼊する意図、必要な構造的変化を起こす約束、教育と コーチングの提供 n ボランティアを活⽤する l ⾊々なところで、希望する l 参加しないことも選択肢として与える l • Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.53 より

• https://amzn.to/2DYXTI5

ガイド︓はじめに（６つのレシピ） 全員を教育する l LeSSの知識だけではなく、⽬的を理解することが重要︕ n 「プロダクト」を定義する l 導⼊の範囲、プロダクトバックログ、適切なプロダクトオーナー n 「Done」を定義する l より強いDoneの定義は、弱いDoneの定義よりも組織的な変化(グループ、役割、 ポジションの排除)をもたらします n 正しい構造を有したチームをつくる l 機能部⾨を離れ、新しいチームに参加する(機能部⾨を排除する) n プロダクトオーナーのみがチームに仕事を与える n プロジェクトマネージャーをチームに近づけない l プロジェクトマネジメントの責任はプロダクトオーナーとチームにある n Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.57 より

• https://amzn.to/2DYXTI5

ラーマンの組織⾏動の法則 1. 2. 3. 4. 組織は、中間及び現場のマネージャーや、単 ⼀専⾨職といったポジションの権⼒構造を維 持するために、暗黙に最適化されます。 1.の結果として、組織を変えようという試みは、 今まで使っていた⽤語をただ、別の名前に変 えるか、⽤語を⼤量につくって何か分からな くする事で現状を維持します。 1.の結果として、組織を変えようという試みは、 弱みを指摘される事を嫌がったり、マネー ジャー/スペシャリストの現状を維持しようと する⼈々により、「純粋主義者」、「理論主 義者」、「⾰命主義者」、「現実に合わせる ためにカスタマイズが必要だ」と⾮難されま す。 ⽂化は構造に従います。 出典 : https://2016-conference.less.works/speakers/craig-larman.html Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.63 より

• https://amzn.to/2DYXTI5

ガイド︓⽂化は構造に従う “組織”の構成要素（グループ、役割、 階層、ポリシーまたはより広範には “組織システム/設計“）が変更されない 限り、⾏動や考え⽅は変わることはな いのです。 出典 : https://2016-conference.less.works/speakers/craig-larman.html Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.63 より

• https://amzn.to/2DYXTI5

LeSSのコンセプト 組織をシンプルにし、“アジャイル”になるためには どうすれば良いのか︖ 少なくすることでもっと多く-More with LeSS Copyright© Kanataku,LLC Takao Kimura.

その他導⼊のガイド n 役割は守らないが雇⽤は守る l 改善の結果、⾃分が解雇されると思うと改善をしようとしない n 完璧を⽬指しての組織ビジョン l LeSSの完璧なビジョン 「価値提供または、方向転換をいつでも 追加コストなしにできる組織をつくり出す」 l l この改善により、私たちは組織が理想とするビジョンに近づきますか︖ この改善により、現場が改善されますか︖ n 継続的改善 l チームレトロスペクティヴ、オーバーオール・レトロスペクティブ n 導⼊の拡⼤ l 他のプロダクトへ、Doneの定義の拡張、プロダクトの拡張など Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.64-69 より

• https://amzn.to/2DYXTI5

マネジメント 現地現物 マネージャーの役割 問題の解決⽅法 を教える スクラムマスター としてのマネージャー ⾃⼰管理 改善サービスの提供 Copyright© Kanataku,LLC Takao Kimura. https://less.works/less/management/index.html

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

⾃⼰管理 n Y理論によるマネジメント n 改善も含め⾃⼰管理するチームに責任を委譲する 全体の⽅向性の決定 マネジメントの責任 チームと組織的 サポートの設計 作業プロセスと 進捗の監視と管理 チームの⾃⼰責任 チームタスクの実⾏ マネジャー ⾃⼰管理 主導チーム チーム ⾃⼰設計 チーム ⾃⼰統治 チーム Leading Teams: Setting the Stage for Great Performances Harvard Business Review Press 2002年 著:J. Richard Hackman Copyright© Kanataku,LLC Takao Kimura. 43

• https://amzn.to/2Fufnw8

組織の強さを作る存在としてのマネージャー 114 5 マネジメント 図 5.1 ● ● LeSS の組織の概要 多くの権限をチームに移譲する • プロダクトづくりと提供 チームとスクラムマスターが取り組んでいる障害の排除と改善を⼿助けする • プロダクトのビジョンと方向性 • 組織の能力向上 Copyright© Kanataku,LLC Takao Kimura. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.114 より

• https://amzn.to/2DYXTI5

LeSSでのマネージャーの役割 5.1 図 5.2 LeSS でのマネジメント 115 3 つの重点領域への役割と責任 『大規模スクラム Large-Scale Scrum(LeSS)』 Copyright© Kanataku,LLC Takao Kimura. ります．たとえばですが，チームはデプロイの自動化を改善し，マネージャーはデ P.115 より

• https://amzn.to/2DYXTI5

まとめ Copyright© Kanataku,LLC Takao Kimura.

LeSSでのポイント n LeSSは基本的な考え⽅、プロセスはスクラムと同じ いきなりLeSSではなく、まずは1チームのスクラムを実践して n LeSSの原理・原則は押さえておくことが重要 n LeSSを導⼊する際には、上級マネジメントの協⼒が必要になる l 正しい構造を有したチームをつくる(組織構造を変える) l ただしトップダウンだけではダメ。ボランティアを活⽤する l 「われわれに選択権はない．マネージャーがLeSS をやれといっている!」 と主張しはじめます．そして，おそらく無意識に，快適な，少なくとも慣れている被 害者という立場に身を置いたままやり過ごそうとします． 『大規模スクラム Large-Scale Scrum(LeSS)』 P.54 l 上級マネジメントを巻き込み、プロダクトチーム全体の 課題を取り除く(このあたりは@ScaleのEMTが参考になる) Copyright© Kanataku,LLC Takao Kimura. より

• https://amzn.to/2DYXTI5

⼤規模スクラム Large-Scale Scrum (LeSS) Less.works(https://less.works/) 『⼤規模スクラム Large-Scale Scrum(LeSS)』が丸善出版より出版 最新の情報を掲載(⼀部⽇本語あり) Copyright© Kanataku,LLC Takao Kimura.

• https://amzn.to/2DYXTI5
• https://less.works/

LeSS Study Large-Scale Scrum の勉強会 n LeSSのサイトである less.works を翻訳しながら 学び合う場として2015年から開催していた n 2019年『⼤規模スクラム Large-Scale Scrum(LeSS)』 が丸善出版より出版されたことを期に読書会 として活動を開始 n LeSS https://less-study.doorkeeper.jp/ https://www.facebook.com/groups/less.study/ Copyright© Kanataku,LLC Takao Kimura.

• https://less.works/
• https://amzn.to/2DYXTI5
• https://less-study.doorkeeper.jp/
• https://www.facebook.com/groups/less.study/