Submit Search
Upload
アジャイルコーチから見たScaled Agile Method LeSS版
•
3 likes
•
2,256 views
Takao Kimura
Follow
Agile Talks で私が話したLeSSパート部分のスライドです。
Read less
Read more
Leadership & Management
Report
Share
Report
Share
1 of 44
Recommended
LeSSでつなぐビジネスとIT
LeSSでつなぐビジネスとIT
Takao Kimura
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Takao Kimura
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜
EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜
TIS Inc.
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Takafumi ONAKA
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
Graat(グラーツ)
Recommended
LeSSでつなぐビジネスとIT
LeSSでつなぐビジネスとIT
Takao Kimura
エンタープライズアジャイル勉強会 LeSS概要
エンタープライズアジャイル勉強会 LeSS概要
Takao Kimura
5分で分かるアジャイルムーブメントの歴史 拡大版
5分で分かるアジャイルムーブメントの歴史 拡大版
Fumihiko Kinoshita
アジャイル開発とメトリクス
アジャイル開発とメトリクス
Rakuten Group, Inc.
アジャイルメトリクス実践ガイド
アジャイルメトリクス実践ガイド
Hiroyuki Ito
EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜
EventStormingワークショップ 〜かつてない図書館をモデリングしてみよう〜
TIS Inc.
グルーミングしながら進めるプロダクト開発
グルーミングしながら進めるプロダクト開発
Takafumi ONAKA
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
アジャイルチームの成果指標設計、進め方と注意点 -開発チームの事業貢献を見える化するには
Graat(グラーツ)
エムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すもの
Yuki Shiromoto
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
div Inc
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
Satoshi Harada
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
Takeshi Kakeda
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
Itsuki Kuroda
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
Takeshi Kakeda
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
Takayuki Shimizukawa
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
越境する開発
越境する開発
toshihiro ichitani
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
Yuki Okada
ドメイン駆動設計再入門
ドメイン駆動設計再入門
Yukei Wachi
Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
Yasuharu Nishi
情報システム部門の組織開発
情報システム部門の組織開発
Kazutaka Sankai
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Takao Kimura
Agile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
More Related Content
What's hot
エムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すもの
Yuki Shiromoto
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
div Inc
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
Kenji Hiranabe
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
増田 亨
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
Yasuharu Nishi
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
Satoshi Harada
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
Takeshi Kakeda
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
増田 亨
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
Itsuki Kuroda
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
増田 亨
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
Takeshi Kakeda
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Akinori SAKATA
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
Takayuki Shimizukawa
リーン開発の本質 公開用
リーン開発の本質 公開用
ESM SEC
越境する開発
越境する開発
toshihiro ichitani
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
Yuki Okada
ドメイン駆動設計再入門
ドメイン駆動設計再入門
Yukei Wachi
Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
Yasuharu Nishi
情報システム部門の組織開発
情報システム部門の組織開発
Kazutaka Sankai
What's hot
(20)
エムスリーのQAチームが目指すもの
エムスリーのQAチームが目指すもの
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
非エンジニアのためのこれだけは押さえておきたいWEBサービスの基礎技術
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
アジャイル開発の現在・過去・未来~今を知り、源流を訪ね、先を見据える~
ソフトウェアの核心にある複雑さに立ち向かう
ソフトウェアの核心にある複雑さに立ち向かう
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
[アジャイル・スクラム勉強会]アジャイルとスクラムの歴史背景
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
日本アジャイル昔話 『忘れられたXPer』 XP祭り2021
ドメイン駆動設計の正しい歩き方
ドメイン駆動設計の正しい歩き方
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について(Rebuild) #devlove
世界でいちばんわかりやすいドメイン駆動設計
世界でいちばんわかりやすいドメイン駆動設計
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
アジャイル・スクラム時代のパタン・ランゲージとアレグザンダー理論
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
JaSST Tokyo 2022 アジャイルソフトウェア開発への統計的品質管理の応用
Webアプリを並行開発する際のマイグレーション戦略
Webアプリを並行開発する際のマイグレーション戦略
リーン開発の本質 公開用
リーン開発の本質 公開用
越境する開発
越境する開発
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
エンジニア組織づくり5年。見えてきた関西Web界隈のええとこ、あかんとこ - Developers Summit 2019 KANSAI
ドメイン駆動設計再入門
ドメイン駆動設計再入門
Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
情報システム部門の組織開発
情報システム部門の組織開発
Similar to アジャイルコーチから見たScaled Agile Method LeSS版
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Takao Kimura
Agile2010とは何だったのか
Agile2010とは何だったのか
Dai FUJIHARA
開発チームの世代交代への取り組み
開発チームの世代交代への取り組み
グロースエクスパートナーズ株式会社/Growth xPartners Incorporated.
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン
Ryota Inaba
HowToDevelopATeamGrowsByThemselves_SCF_OSaka2022.pdf
HowToDevelopATeamGrowsByThemselves_SCF_OSaka2022.pdf
Kei Nakahara
SPI Japan 2012 「Agileのベースライン」ポジショントーク用
SPI Japan 2012 「Agileのベースライン」ポジショントーク用
Naoya Maekawa
大規模スクラムの失敗から学んだこと #AgileJapan2015
大規模スクラムの失敗から学んだこと #AgileJapan2015
Itsuki Sakitsu
スクラムプロジェクト準備(公開用) No.31
スクラムプロジェクト準備(公開用) No.31
Sukusuku Scrum
Nexus and LeSS #rsgt2016
Nexus and LeSS #rsgt2016
Takao Kimura
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
Rakuten Group, Inc.
Scrum"再"入門
Scrum"再"入門
You&I
開発とテストが一体となったソフトウェア開発
開発とテストが一体となったソフトウェア開発
Yahoo!デベロッパーネットワーク
スクラム再入門
スクラム再入門
Minoru Yokomichi
Hello Scrum-はじめてのスクラム導入記
Hello Scrum-はじめてのスクラム導入記
Tetsuya Imamura
スクラム初心者セッション.pdf
スクラム初心者セッション.pdf
Hideo Kashioka
開発現場を盛り上げる技術とチームを支え続ける原動力 - Developers summit 2015 kansai
開発現場を盛り上げる技術とチームを支え続ける原動力 - Developers summit 2015 kansai
Masahiro Taguchi
SYN Presentation Slides
SYN Presentation Slides
Hiroki Ichinose
SPI Japan2016発表資料
SPI Japan2016発表資料
Reiko Rikuno
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
Yoshitaka Kawashima
リーダーシップ・マネジメント実践への提言
リーダーシップ・マネジメント実践への提言
リーダーシップ研究アカデミー・CLS Japan本部
Similar to アジャイルコーチから見たScaled Agile Method LeSS版
(20)
Agile Tech EXPO Community Introduction
Agile Tech EXPO Community Introduction
Agile2010とは何だったのか
Agile2010とは何だったのか
開発チームの世代交代への取り組み
開発チームの世代交代への取り組み
【Sgt2016】Agile人材の評価とキャリアプラン
【Sgt2016】Agile人材の評価とキャリアプラン
HowToDevelopATeamGrowsByThemselves_SCF_OSaka2022.pdf
HowToDevelopATeamGrowsByThemselves_SCF_OSaka2022.pdf
SPI Japan 2012 「Agileのベースライン」ポジショントーク用
SPI Japan 2012 「Agileのベースライン」ポジショントーク用
大規模スクラムの失敗から学んだこと #AgileJapan2015
大規模スクラムの失敗から学んだこと #AgileJapan2015
スクラムプロジェクト準備(公開用) No.31
スクラムプロジェクト準備(公開用) No.31
Nexus and LeSS #rsgt2016
Nexus and LeSS #rsgt2016
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
はじめてのスクラム体験ワークショップ 〜 アジャイル時代のテスターを目指して
Scrum"再"入門
Scrum"再"入門
開発とテストが一体となったソフトウェア開発
開発とテストが一体となったソフトウェア開発
スクラム再入門
スクラム再入門
Hello Scrum-はじめてのスクラム導入記
Hello Scrum-はじめてのスクラム導入記
スクラム初心者セッション.pdf
スクラム初心者セッション.pdf
開発現場を盛り上げる技術とチームを支え続ける原動力 - Developers summit 2015 kansai
開発現場を盛り上げる技術とチームを支え続ける原動力 - Developers summit 2015 kansai
SYN Presentation Slides
SYN Presentation Slides
SPI Japan2016発表資料
SPI Japan2016発表資料
ふつうの受託開発チームのつくりかた
ふつうの受託開発チームのつくりかた
リーダーシップ・マネジメント実践への提言
リーダーシップ・マネジメント実践への提言
More from Takao Kimura
Agile and Team Building
Agile and Team Building
Takao Kimura
Ost
Ost
Takao Kimura
強いチームを創るには-20160124 Gaiakitchen
強いチームを創るには-20160124 Gaiakitchen
Takao Kimura
Agile Discussion 1st
Agile Discussion 1st
Takao Kimura
POStudy Large Scale Scrum
POStudy Large Scale Scrum
Takao Kimura
LeSS Study LeSS Framework Overview
LeSS Study LeSS Framework Overview
Takao Kimura
自社ブログサービス「ヤプログ!」でスクラム開発
自社ブログサービス「ヤプログ!」でスクラム開発
Takao Kimura
20141222 アジャイルサムライ横浜道場 LT&忘年会
20141222 アジャイルサムライ横浜道場 LT&忘年会
Takao Kimura
DevLOVE現場甲子園2014 東日本大会 一回表
DevLOVE現場甲子園2014 東日本大会 一回表
Takao Kimura
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
Takao Kimura
20140214 TOCfEBC openjam
20140214 TOCfEBC openjam
Takao Kimura
20130425 branch1
20130425 branch1
Takao Kimura
20130320 agile pm
20130320 agile pm
Takao Kimura
横浜道場忘年会
横浜道場忘年会
Takao Kimura
はじめてのアジャイル
はじめてのアジャイル
Takao Kimura
横浜道場紹介 AJ12
横浜道場紹介 AJ12
Takao Kimura
横浜道場紹介 第2版
横浜道場紹介 第2版
Takao Kimura
Pomodoro tecnique
Pomodoro tecnique
Takao Kimura
More from Takao Kimura
(18)
Agile and Team Building
Agile and Team Building
Ost
Ost
強いチームを創るには-20160124 Gaiakitchen
強いチームを創るには-20160124 Gaiakitchen
Agile Discussion 1st
Agile Discussion 1st
POStudy Large Scale Scrum
POStudy Large Scale Scrum
LeSS Study LeSS Framework Overview
LeSS Study LeSS Framework Overview
自社ブログサービス「ヤプログ!」でスクラム開発
自社ブログサービス「ヤプログ!」でスクラム開発
20141222 アジャイルサムライ横浜道場 LT&忘年会
20141222 アジャイルサムライ横浜道場 LT&忘年会
DevLOVE現場甲子園2014 東日本大会 一回表
DevLOVE現場甲子園2014 東日本大会 一回表
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
アジャイルサムライ横浜道場「ざっくりわかるアジャイル開発」
20140214 TOCfEBC openjam
20140214 TOCfEBC openjam
20130425 branch1
20130425 branch1
20130320 agile pm
20130320 agile pm
横浜道場忘年会
横浜道場忘年会
はじめてのアジャイル
はじめてのアジャイル
横浜道場紹介 AJ12
横浜道場紹介 AJ12
横浜道場紹介 第2版
横浜道場紹介 第2版
Pomodoro tecnique
Pomodoro tecnique
アジャイルコーチから見たScaled Agile Method LeSS版
1.
アジャイルコーチから⾒た Scaled Agile Method.. 〜SAFe
and LeSSから学ぶ勘所〜 原田 巌/木村 卓央/水野 正隆 Agile Talks vol.1, 2019.12.09
2.
⽔野正隆 オージス総研 アジャイルコーチ 原⽥巌 オージス総研アジャイルコーチ (期限切れ) ⽊村卓央 合同会社カナタク 代表社員 アジャイルコーチ LeSS派SAFe派 司会進行
3.
Copyright© Kanataku,LLC Takao
Kimura. LeSS Part
4.
Copyright© Kanataku,LLC Takao
Kimura. ⾃⼰紹介 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) アジャイルとスクラムを大規模に実装する方法 共訳 木村 卓央 KIMURA Takao アジャイル コーチ https://www.facebook.com/kanataku.LLC/ https://about.me/tw_takubon kimura.takao@kanataku.com
5.
Copyright© Kanataku,LLC Takao
Kimura. ⼤規模スクラム Large-Scale Scrum (LeSS) https://less.works/
6.
Copyright© Kanataku,LLC Takao
Kimura. LeSS complete picture LeSSは原理・原則をコアにして、複 数チームのコンテキストにスクラム を適⽤するためのルールとガイドの セットからなる n 原理・原則 l LeSSのコア n フレームワーク l ルールで定義している n ガイド l ルールを効率的に適応するためのもの l 試す価値がある実験の集まり(経験知) n 実験 l 限定的な環境で機能する
7.
Copyright© Kanataku,LLC Takao
Kimura. ⼤規模スクラムは スクラムである 透明性 少なくすることで もっと多く プロダクト全体 思考 顧客中⼼ 完璧を⽬指しての 継続的改善 リーン思考 システム思考 経験的プロセス 制御 待ち⾏列理論 原理・原則 - LeSSのコア 出典: https://less.works/less/principles/index.html
8.
Copyright© Kanataku,LLC Takao
Kimura. 原理・原則 ⼤規模スクラムはスクラム LeSSはスクラムの原理・原則、ルール、要素、⽬的を⼤規模開発のコンテキストに可能 な限りシンプルに適応したもの 透明性 スクラムと同じ。完成したアイテム、短いサイクル、協働、共通の定義、現場から恐れを 取り除くことがベースになる 少なくすることでもっと多く 多くしてしまうと思考停⽌、改善の余地が減る 少なくすることでチームが多くの責任を持つ。 チームがプロセスと意義のある仕事のオーナーシップを持つ プロダクト全体思考 顧客が望んでいるひとまとまりのプロダクトとしての価値ある機能を提供する 顧客中⼼ 顧客にフォーカスし続ける ⾃分の仕事がお⾦を払うお客様に対してどのような価値提供につながっているのかを理解 する 完璧を⽬指しての継続的改善 パーフェクトビジョン=達成出来ないほどの⽬標に継続的に改善して近づける 例︓コストをかけずに障害のないプロダクトを常に提供し続け、⽣活を豊かにする リーン思考 ⼈間性尊重と継続的改善の2つの柱を組織に根付かせ、完璧な⽬標を⽬指す システム思考 システム全体(アイデアから売上を得るまでに関わる⼈・物などすべて)を最適化する システムモデルを使いシステムの関係性を理解する 経験的プロセス制御 スクラムと同じ 継続的にプロダクト、プロセス、ふるまいの検証と適応を⾏う 待ち⾏列理論 どこにキューがあるのか。リードタイムを短くするにはどうするのか 『大規模スクラム Large-Scale Scrum(LeSS)』 P.8 より
9.
Copyright© Kanataku,LLC Takao
Kimura. ⼤規模スクラムはスクラムである Large-Scale Scrum is Scrum
10.
Copyright© Kanataku,LLC Takao
Kimura. スクラムの成功は抽象的な原理・原則と 具体的な⼿法の絶妙なバランスにある n抽象的な原理・原則 l透明性・検査・適応 l5つの価値基準 l経験的プロセス制御 n具体的な⼿法 l3つのロール l3つの作成物 l4つのイベント Bas Vodde 出典 : https://less.works/resources/about.html Craig Larman
11.
Copyright© Kanataku,LLC Takao
Kimura. ⼤規模スクラムはスクラムである nLeSS はスクラムと同様にバランスを取っている l抽象的な原理・原則 l具体的なプラクティス n⾃分たちの仕事の仕⽅を継続的に改善できるように l徹底的な透明性の維持 l検査と適応のサイクルを重視 lスクラムに具体的な構造を追加
12.
Copyright© Kanataku,LLC Takao
Kimura. フレームワーク - ルール LeSS Rules (April 2018) n LeSSフレームワーク 2~”8”チームで開発するプロダクトに 適⽤ n LeSS Hugeフレームワーク “9”チーム以上で開発するプロダクトに 適⽤
13.
Copyright© Kanataku,LLC Takao
Kimura. 基本は1チームのスクラムと同じ スクラムのプラクティスとアイデアを保持 n1つのプロダクトバックログ n1⼈の(全体の)プロダクトオーナー n1つの完成の定義 n各スプリントの終わりに出荷可能なインクリメント nクロスファンクショナルなチーム nスプリント lLeSSでは、全てのチームが共通のスプリントで 共通の出荷可能なインクリメントをデリバリーする
14.
Copyright© Kanataku,LLC Takao
Kimura. LeSSの⽅向性 n シンプルであるべき(More with LeSS) l 余計な役割/成果物/プロセスを追加してしまう罠にはまらないよう にする n スケールしたスクラム(Large-Scale Scrum is Scrum) l スクラムの各要素を理解した上で、同様の効果を⼤規模開発におい て実現する⽅法を模索する n 削ぎ落しではなくスケールアップ(LeSS→LeSS Huge) l 汎⽤的なフレームワークからスタートして削ぎ落としていく⽅法で は、メタボなプロセスになる。 常に「最⼩限」から始めて必要最低限のものをビルドアップ 14
15.
Copyright© Kanataku,LLC Takao
Kimura. コミュニティ スクラムマスター チーム 顧客価値による組織化 フィーチャーチーム 組織構造 LeSSの構造 https://less.works/less/structure/index.html
16.
Copyright© Kanataku,LLC Takao
Kimura. LeSSルール︓ LeSSの構造 n 実際のチームを組織の基本構成要素として組織を構成します。 n それぞれのチームは、(1)⾃⼰管理、(2)クロスファンクショナル、(3)同⼀ロケーション、(4)⻑期間存続で す。 n チームの⼤半は顧客中⼼のフィーチャーチームです。 n スクラムマスターはLeSSの導⼊が問題なく⾏われることに責任を持ちます。注⼒する対象は、チーム、プロ ダクトオーナー、組織、技術的⼿法であり、1チームだけの改善に留まることなく、組織全体の改善を⾏う 必要があります。 n スクラムマスターは専任でフルタイムのロールです。 n 1⼈のスクラムマスターが1〜3チームを担当することができます。 n LeSSではマネージャーは必須ではありません。もしマネージャーがいる場合でも多くの場合役割が変わりま す。マネージャーがフォーカスすべきことは、⽇々の作業の管理からプロダクトを開発するシステム全体の 価値提供能⼒の向上に移ります。 n マネージャーの役割はプロダクト開発の仕組みの改善を促進することです。「現地現物」の実践、「⽌めて 直す」の推奨、「適合するよりも実験をする」ことを通じて改善を促進します。 n プロダクトグループは、「最初から」完全なLeSSの構造を適⽤します。これはLeSSを導⼊する際の肝とな ることです。 n プロダクトグループを越える、より⼤きな組織には、「現地現物」の考え⽅を使い、実験や改善があたりま えとなる環境を作っていくことで段階的にLeSS導⼊を進めます。 『LeSSルール(2018 4月)』より
17.
Copyright© Kanataku,LLC Takao
Kimura. ロール n プロダクトオーナー︓1⼈ l 前提︓全てのアイテムの詳細を把握することは不可能 l 明確化よりも優先順位付けに重きをおく l チームとユーザー(ステークホルダー)をつなぐコネクター n スクラムマスター︓専任、1~3チームを担当 l LeSSの導⼊が問題なく⾏われることに責任を持つ l 1チームだけではなく、組織全体の改善を⾏う n チーム︓スクラムで⾔う開発チーム l フィーチャーチーム n LeSSでは、プロダクトグループ(明確には定義していない) l スクラムチームでは無い
18.
Copyright© Kanataku,LLC Takao
Kimura. フィーチャーチーム 『大規模スクラム Large-Scale Scrum(LeSS)』 P.77 より 実際のチームを組織の基本構成要素とし て組織を構成します。 それぞれのチームは、(1)⾃⼰管理、(2) クロスファンクショナル、(3)同⼀ロ ケーション、(4)⻑期間存続です。 チームの⼤半は顧客中⼼のフィーチャー チームです。 『LeSSルール(2018 4月)LeSSの構造』より
19.
Copyright© Kanataku,LLC Takao
Kimura. コンポーネントチーム vs フィーチャーチーム 同期依存関係 コンポーネントをいじるときに依存関係が発⽣する 個⼈が協⼒しあう環境 ⾮同期依存関係
20.
Copyright© Kanataku,LLC Takao
Kimura. LeSSの組織構造 n よく⾒られる組織構造 プロダクトグループ の責任者 ほとんどのLeSS組織ではマネージャーが存在する 現地現物によってチームを⽀援。障害を取り除く Undone部⾨ 理想的には存在しない部⾨ システム保証などの名前で存在することがある https://less.works/jp/less/structure/organizational-structure.html LeSSではマネージャーは必須ではありま せん。もしマネージャーがいる場合でも多 くの場合役割が変わります。マネージャー がフォーカスすべきことは、⽇々の作業の 管理からプロダクトを開発するシステム全 体の価値提供能⼒の向上に移ります。 マネージャーの役割はプロダクト開発の仕 組みの改善を促進することです。「現地現 物」の実践、「⽌めて直す」の推奨、「適 合するよりも実験をする」ことを通じて改 善を促進します。 『LeSSルール(2018 4月)LeSSの構造』より
21.
Copyright© Kanataku,LLC Takao
Kimura. LeSSのプロダクト
22.
Copyright© Kanataku,LLC Takao
Kimura. LeSSルール︓ LeSSのプロダクト n 1⼈のプロダクトオーナーと1つのプロダクトバックログがあり、出荷可能なプロダクト全体を運 ⽤します。 n プロダクトオーナーだけでプロダクトバックログリファインメントをするべきではありません。 複数のチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダク トオーナーをサポートします。 n 全ての優先順位付けはプロダクトオーナーが⾏います。が、要求や仕様を明確にするのは出来る 限りチームと、顧客やユーザーそしてステークホルダーとの間で直接⾏います。 n プロダクトの定義は現実的な範囲で、エンドユーザーまたは顧客中⼼でなければなりません。プ ロダクトの定義は広い⽅が好ましく、時間の経過とともに拡張する可能性があります。 n プロダクト全体で全チーム共通の1つのDoneの定義を持ちます。 n 各チームは共通のDoneの定義を拡張してより厳しい独⾃のものを定めても構いません。 n 究極のゴールはDoneの定義を拡張し、毎スプリント(あるいはより⾼い頻度で)出荷可能なプロ ダクトを作れるようになることです。 『LeSSルール(2018 4月)』より
23.
Copyright© Kanataku,LLC Takao
Kimura. LeSSのプロダクト 1⼈のプロダクトオーナーと1つのプロダクトバックログがあり、 出荷可能なプロダクト全体を運⽤します。 『LeSSルール(2018 4月)』より 1つのプロダクトに関わる全てのチームは同じスプリントで作業します。 スプリントの開始も終了も全チーム共通です。スプリントの終わりには プロダクト全体が1つに統合されている状態にします。
24.
Copyright© Kanataku,LLC Takao
Kimura. LeSSルール︓ LeSSのスプリント n 1つのプロダクトに関わる全てのチームは同じスプリントで作業します。スプリントの開始も終了も全チーム共通です。スプリントの終わ りにはプロダクト全体が1つに統合されている状態にします。 n スプリントプランニングは2つのパートで構成されています。スプリントプランニング1は全てのチームが合同で実施します。それに対し てスプリントプランニング2は通常、各チームごとに個別で⾏われます。ただし、関連性が強いアイテムがある場合は共有スペースで、複 数チームのスプリントプランニング2を⾏います。 n スプリントプランニング1にはプロダクトオーナーとチーム全員またはチームの代表者が参加します。参加者は⼀緒に、各チームがこのス プリントで作業するアイテムを暫定的に選択します。チームは協働する部分を特定し、質問を明確にします。 n 各チームにはチームごとのスプリントバックログがあります。 n スプリントプランニング2は各チームがどのようにアイテムを実現させるかを考える場であり、設計やスプリントバックログの作成を⾏い ます。 n デイリースクラムはチームごとに⾏います。 n チームどうしの調整はチームに委ねられています。中央集権的な調整ではなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。 重要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである「コードでのコミュニケーション」、チームをまたいだミーティン グ、「コンポーネントメンター」、「トラベラー」、「偵察」、そして「オープンスペース」を活⽤することです。 n プロダクトバックログリファインメント(PBR)は、シェアード・ラーニング(訳注:学習したものをシェアする)を増やし、調整の機会とし て活⽤できるため、複数チームで⾏うのが望ましいです。 n スプリントレビューは全てのチームが共同で⾏います。検査と適応を⾏うのに適切な情報を得られるよう、必要なステークホルダーが参加 するようにします。 n スプリントレトロスペクティブは各チームで⾏います。 n オーバーオール・レトロスペクティブは各チームのレトロスペクティブの後に⾏われます。ここでは複数チームやシステム全体にまたがる 課題を扱い、改善に向けての実験を議論します。この場にはプロダクトオーナー、全スクラムマスター、チーム代表者と、(いるなら)マ ネージャーが参加します。 『LeSSルール(2018 4月)』より
25.
Copyright© Kanataku,LLC Takao
Kimura. スプリントプランニング 『大規模スクラム Large-Scale Scrum(LeSS)』 P.254 より スプリントプランニングは2つの パートで構成されています。スプ リントプランニング1は全ての チームが合同で実施します。それ に対してスプリントプランニング 2は通常、各チームごとに個別で ⾏われます。ただし、関連性が強 いアイテムがある場合は共有ス ペースで、複数チームのスプリン トプランニング2を⾏います。 『LeSSルール(2018 4月)』より
26.
Copyright© Kanataku,LLC Takao
Kimura. スプリントプランニング1 n プロダクトオーナーはカードをテーブルに広げる n チームがどのアイテムを持っていくか決める l ディスカッションする n チームが取ったアイテムの優先順位が全体最適になっているか確認す る n 共通でやらなければならない作業 の明確化 l 複数チームの スプリントプランニング2 n プロダクトオーナーが チームの判断を超えて、やってはいけない
27.
Copyright© Kanataku,LLC Takao
Kimura. プロダクトバックログリファインメント(PBR) 『大規模スクラム Large-Scale Scrum(LeSS)』 P.229 より プロダクトバックログリファイン メント(PBR)は、シェアード・ ラーニング(訳注:学習したものを シェアする)を増やし、調整の機会 として活⽤できるため、複数チー ムで⾏うのが望ましいです。 『LeSSルール(2018 4月)』より
28.
Copyright© Kanataku,LLC Takao
Kimura. スプリントレビュー・レトロスペクティブ 『大規模スクラム Large-Scale Scrum(LeSS)』 P.288 より スプリントレビューは全てのチームが共同 で⾏います。検査と適応を⾏うのに適切な 情報を得られるよう、必要なステークホル ダーが参加するようにします。 スプリントレトロスペクティブは各チーム で⾏います。 オーバーオール・レトロスペクティブは各 チームのレトロスペクティブの後に⾏われ ます。ここでは複数チームやシステム全体 にまたがる課題を扱い、改善に向けての実 験を議論します。この場にはプロダクト オーナー、全スクラムマスター、チーム代 表者と、(いるなら)マネージャーが参加 します。 『LeSSルール(2018 4月)』より
29.
Copyright© Kanataku,LLC Takao
Kimura. 調整と統合 チームどうしの調整はチームに委ねられています。中央集権的な調整で はなく、個別の判断で⾃由かつ⾮公式に調整する⽅が好ましいです。重 要なのは、「ただ話す」ことや、⾮公式のコミュニケーションである 「コードでのコミュニケーション」、チームをまたいだミーティング、 「コンポーネントメンター」、「トラベラー」、「偵察」、そして 「オープンスペース」を活⽤することです。 n ただ話す n コードでのコミュニケーション n ブランチは使わない n コミュニティ n オープンスペース n トラベラー n コンポーネントメンター n 偵察 『大規模スクラム Large-Scale Scrum(LeSS)』 P.284 より 『LeSSルール(2018 4月)』より
30.
Copyright© Kanataku,LLC Takao
Kimura. https://less.works/less/adoption/index.html はじめに フィーチャーチーム 導⼊マップ 継続的改善 コーチング 3つの原則 LeSSの導⼊
31.
Copyright© Kanataku,LLC Takao
Kimura. ガイド︓3つの導⼊原則 n 広く浅くよりも、狭く深く l 1つのプロダクトを上⼿く回してから n トップダウンとボトムアップ l トップダウトとボトムアップの両⽅が必要 l 特にマネジメント(通常はプロダクトグループの責任者)の⽀援が重要 Ø コントロールでなく⽀援をする Ø 以下をはっきりと伝えて⾏動に移す •LeSSを導⼊する意図、必要な構造的変化を起こす約束、教育と コーチングの提供 n ボランティアを活⽤する l ⾊々なところで、希望する l 参加しないことも選択肢として与える 『大規模スクラム Large-Scale Scrum(LeSS)』 P.53 より
32.
Copyright© Kanataku,LLC Takao
Kimura. ガイド︓はじめに(6つのレシピ) n 全員を教育する l LeSSの知識だけではなく、⽬的を理解することが重要︕ n 「プロダクト」を定義する l 導⼊の範囲、プロダクトバックログ、適切なプロダクトオーナー n 「Done」を定義する l より強いDoneの定義は、弱いDoneの定義よりも組織的な変化(グループ、役割、 ポジションの排除)をもたらします n 正しい構造を有したチームをつくる l 機能部⾨を離れ、新しいチームに参加する(機能部⾨を排除する) n プロダクトオーナーのみがチームに仕事を与える n プロジェクトマネージャーをチームに近づけない l プロジェクトマネジメントの責任はプロダクトオーナーとチームにある 『大規模スクラム Large-Scale Scrum(LeSS)』 P.57 より
33.
Copyright© Kanataku,LLC Takao
Kimura. ラーマンの組織⾏動の法則 1. 組織は、中間及び現場のマネージャーや、単 ⼀専⾨職といったポジションの権⼒構造を維 持するために、暗黙に最適化されます。 2. 1.の結果として、組織を変えようという試みは、 今まで使っていた⽤語をただ、別の名前に変 えるか、⽤語を⼤量につくって何か分からな くする事で現状を維持します。 3. 1.の結果として、組織を変えようという試みは、 弱みを指摘される事を嫌がったり、マネー ジャー/スペシャリストの現状を維持しようと する⼈々により、「純粋主義者」、「理論主 義者」、「⾰命主義者」、「現実に合わせる ためにカスタマイズが必要だ」と⾮難されま す。 4. ⽂化は構造に従います。 出典 : https://2016-conference.less.works/speakers/craig-larman.html 『大規模スクラム Large-Scale Scrum(LeSS)』 P.63 より
34.
Copyright© Kanataku,LLC Takao
Kimura. ガイド︓⽂化は構造に従う “組織”の構成要素(グループ、役割、 階層、ポリシーまたはより広範には “組織システム/設計“)が変更されない 限り、⾏動や考え⽅は変わることはな いのです。 出典 : https://2016-conference.less.works/speakers/craig-larman.html 『大規模スクラム Large-Scale Scrum(LeSS)』 P.63 より
35.
Copyright© Kanataku,LLC Takao
Kimura. LeSSのコンセプト 組織をシンプルにし、“アジャイル”になるためには どうすれば良いのか︖ 少なくすることでもっと多く-More with LeSS
36.
Copyright© Kanataku,LLC Takao
Kimura. その他導⼊のガイド n 役割は守らないが雇⽤は守る l 改善の結果、⾃分が解雇されると思うと改善をしようとしない n 完璧を⽬指しての組織ビジョン l LeSSの完璧なビジョン l この改善により、私たちは組織が理想とするビジョンに近づきますか︖ l この改善により、現場が改善されますか︖ n 継続的改善 l チームレトロスペクティヴ、オーバーオール・レトロスペクティブ n 導⼊の拡⼤ l 他のプロダクトへ、Doneの定義の拡張、プロダクトの拡張など 『大規模スクラム Large-Scale Scrum(LeSS)』 P.64-69 より 「価値提供または、方向転換をいつでも 追加コストなしにできる組織をつくり出す」
37.
Copyright© Kanataku,LLC Takao
Kimura. マネジメント ⾃⼰管理 問題の解決⽅法 を教える 現地現物 マネージャーの役割 スクラムマスター としてのマネージャー 改善サービスの提供 https://less.works/less/management/index.html
38.
Copyright© Kanataku,LLC Takao
Kimura. ⾃⼰管理 n Y理論によるマネジメント n 改善も含め⾃⼰管理するチームに責任を委譲する 43 全体の⽅向性の決定 チームと組織的 サポートの設計 作業プロセスと 進捗の監視と管理 チームタスクの実⾏ マネジャー 主導チーム ⾃⼰管理 チーム ⾃⼰設計 チーム ⾃⼰統治 チーム マネジメントの責任 チームの⾃⼰責任 Leading Teams: Setting the Stage for Great Performances Harvard Business Review Press 2002年 著:J. Richard Hackman
39.
Copyright© Kanataku,LLC Takao
Kimura. 組織の強さを作る存在としてのマネージャー ● 多くの権限をチームに移譲する ● チームとスクラムマスターが取り組んでいる障害の排除と改善を⼿助けする 『大規模スクラム Large-Scale Scrum(LeSS)』 P.114 より 114 5 マ ネ ジ メ ン ト 図 5.1 LeSS の組織の概要 • プロダクトづくりと提供 • プロダクトのビジョンと方向性 • 組織の能力向上
40.
Copyright© Kanataku,LLC Takao
Kimura. LeSSでのマネージャーの役割5.1 LeSS でのマネジメント 115 図 5.2 3 つの重点領域への役割と責任 ります.たとえばですが,チームはデプロイの自動化を改善し,マネージャーはデ『大規模スクラム Large-Scale Scrum(LeSS)』 P.115 より
41.
Copyright© Kanataku,LLC Takao
Kimura. まとめ
42.
Copyright© Kanataku,LLC Takao
Kimura. LeSSでのポイント n LeSSは基本的な考え⽅、プロセスはスクラムと同じ l いきなりLeSSではなく、まずは1チームのスクラムを実践して n LeSSの原理・原則は押さえておくことが重要 n LeSSを導⼊する際には、上級マネジメントの協⼒が必要になる l 正しい構造を有したチームをつくる(組織構造を変える) l ただしトップダウンだけではダメ。ボランティアを活⽤する l 上級マネジメントを巻き込み、プロダクトチーム全体の 課題を取り除く(このあたりは@ScaleのEMTが参考になる) 「われわれに選択権はない.マネージャーがLeSS をやれといっている!」 と主張しはじめます.そして,おそらく無意識に,快適な,少なくとも慣れている被 害者という立場に身を置いたままやり過ごそうとします. 『大規模スクラム Large-Scale Scrum(LeSS)』 P.54 より
43.
Copyright© Kanataku,LLC Takao
Kimura. ⼤規模スクラム Large-Scale Scrum (LeSS) 『⼤規模スクラム Large-Scale Scrum(LeSS)』が丸善出版より出版 Less.works(https://less.works/) 最新の情報を掲載(⼀部⽇本語あり)
44.
Copyright© Kanataku,LLC Takao
Kimura. LeSS Study n LeSS Large-Scale Scrum の勉強会 n LeSSのサイトである less.works を翻訳しながら 学び合う場として2015年から開催していた n 2019年『⼤規模スクラム Large-Scale Scrum(LeSS)』 が丸善出版より出版されたことを期に読書会 として活動を開始 https://less-study.doorkeeper.jp/ https://www.facebook.com/groups/less.study/