1. LeSSの概要 (Large-Scale Scrum) 2016/11/25 Ryuzee.com 吉羽龍太郎 (@ryuzee)
2. LeSS概要 ✤ 大規模用のスクラムフレームワーク。まぁまぁ十分という程度を目指している ✤ 8チームまで用とそれ以上のチーム用(LeSS Huge)の2バージョンがある ✤ LeSSはスクラムなので以下はそのまま適用される ✤ 製品は1つでプロダクトバックログも1つ ✤ 完了(完成)の定義も1つ ✤ スプリントの最後には出荷判断可能な製品の増分を作る ✤ 1人のプロダクトオーナー (スクラムマスターは複数でOK) ✤ クロスファンクショナルチーム ✤ スプリント期間は固定期間 (各チーム共通で同じ日に開始・終了)
3. 歴史 ✤ ✤ CraigとBasによって2005年から開発。多くの事例 ✤ 通信機器 - Ericsson & Nokia Network ✤ 投資銀行およびリテールバンク - UBS ✤ トレーディングシステム - ION Trading ✤ マーケティングプラットフォームとブランド分析 - Vendasta ✤ ビデオ会議 - Cisco ✤ オンラインゲーム - bwin.party ✤ オフショアアウトソーシング - Valtech India 1000人を超える規模での採用事例もある
4. 歴史 Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum Large-Scale Scrum: More with LeSS
5. LeSSに含まれるもの ✤ ルール ✤ ✤ ガイド (オプション) ✤ ✤ ルールを効果的に適用するためのガイドセットと実験のサブセット。 通常役にたつ が、継続的改善のための領域 実験 (オプション) ✤ ✤ 基礎となる最小限のルール。経験的なプロセス制御と製品全体の焦点をサポートする ために必要なもの。例：全体的なふりかえりを各スプリントで実施 状況次第のもので、場合によっては試す価値がないかもしれない多くの実験。 原則 ✤ ルール、ガイド、実験のもととなる原則。たとえば製品への注目
6. LeSSの原則 (10個) キュー理論 経験的 プロセス制御 システム シンキング リーンシンキング 大規模スクラムは スクラム 透明性 少ないことから 大きな成果 製品全体に フォーカス 顧客中心 完璧に向けた 継続的改善
7. LeSSの原則 (1) ✤ 大規模スクラムはスクラム => 新しいスクラムではなく、スクラムの原則 やルールや要素を大規模でできるだけ簡単に適用できるようにする ✤ 透明性 => 明確に「完了」した項目、短いサイクル、協働、共通の定義、 職場からの恐怖の追放を基にする ✤ 少ないことから大きな成果 => 新しいロールを増やしたりプロセスを増や したり成果物を増やさないで、顧客にフォーカスして製品を作る ✤ 製品全体にフォーカス => プロダクトバックログは1つ、プロダクトオー ナーも1人、1つの出荷可能な製品、1つのスプリント期間
8. LeSSの原則 (2) ✤ 顧客中心 => 顧客の本当の問題を学習し解決する。お金を払う顧客の目で 価値や無駄を見分ける。待ち時間を減らし本当の顧客とのフィードバック ループを強化する。全ての作業は顧客に関係がある ✤ 完璧に向けた継続的改善 => 安い金額で欠陥のない顧客の喜ぶ製品を早く 作るという目標に向かって無限に改良を繰り返す ✤ リーンシンキング => ストップ＆フィックスを促す ✤ システムシンキング => システム全体を理解・最適化する。個人やチーム の生産性や効率に重点を置いて部分最適するのではなく、全体を最適化す る
9. LeSSの原則 (3) ✤ 経験的プロセス制御 => 製品やプロセスや行動などを状況に応じた方法で 継続的に検査し適応する。盲目的にベストプラクティスに従わない ✤ キュー理論 => キューのサイズ、仕掛り数の制限、マルチタスク、バラつ きの管理などにキュー理論を適用する
10. 2つのフレームワーク ✤ LeSS => 2∼8チーム用 ✤ LeSS Huge => それ以上の数のチーム向け ✤ ただし、製品全体にフォーカスする原則 (1人のプロダクトオーナー、1つ のプロダクトバックログ、全チーム共通のスプリント、1つの出荷可能商 品増分)については変わりない
12. LeSSにおけるスプリントの流れ 1人のプロダクト オーナー 1つの プロダクト バックログ 開発チーム1 + SM 開発チーム2 + SM 開発チーム3 + SM 開発チームN + SM スプリ ント計 画会議 第一部 チーム毎の スプリント バックログ 製品も1つ 計画 第二部 デイリー スクラム … デイリー スクラム 計画 第二部 デイリー スクラム … デイリー スクラム 計画 第二部 デイリー スクラム … デイリー スクラム 計画 第二部 デイリー スクラム … デイリー スクラム ふりかえり スプリ ントレ ビュー ふりかえり ふりかえり ふりかえり 全体 ふりか えり
13. LeSSのルール (1) ✤ 1つの製品に1人のプロダクトオーナーと1つのプロダクトバックログ。開発チー ムはフィーチャーチームでクロスファンクショナル ✤ 製品レベルのスプリントは1つであり、各チームごとに異なるスプリントではな い ✤ スプリント計画第一部は全チーム参加、スプリント計画第二部はチーム毎に実施 ✤ スプリント計画第一部にはプロダクトオーナーと各チームまたはその代表者が参 加して、各チームが作業するプロダクトバックログ項目を暫定的に選択する ✤ スプリント計画第一部ではチームはチーム間で一緒に働ける機会を探す。また内 容についてマイナーな点を含めて質問を行う
14. LeSSのルール (2) ✤ スプリント計画第二部では密接に関連するチーム同士は共有スペースなど近い場 所で計画を作る ✤ スプリントバックログは各チームごとに別に持つ ✤ 中央集権化よりも非集中化と非公式の調整が望ましい ✤ 各スプリントごとに出荷可能な製品になるように、完了の定義を改善し続ける ✤ チーム単位のふりかえりを行う ✤ チーム単位のふりかえりのあとに全体でのふりかえりを行い、チーム間およびシ ステム全体の問題を議論し、改善実験を行う
15. LeSSのルール (3) ✤ チームをまたがる調整はチーム同士で行う ✤ 複数チームまたは全体でのバックロググルーミングを実施して共通理解を深める とともに密接に関連した項目や学習が必要な項目がある場合の調整機会とする ✤ プロダクトバックログの優先順位はプロダクトオーナーを経るが、明確化は可能 な限り直接顧客やステークホルダーと行う ✤ プロダクトオーナーはプロダクトバックログの改良に単独で取り組むべきではな く、顧客/ユーザーおよび他のステークホルダーと直接関係している複数のチーム によってサポートされなければならない ✤ スプリントレビューは製品につき1回で全チーム共通
16. LeSS Huge ✤ 8チームを超えるサイズの場合はLeSS Hugeを適用する ✤ 単一プロダクトバックログは維持し、スプリント単位で製品を結合するが、プロ ダクトバックログに「要求エリア」を定義する ✤ エリアごとにエリアプロダクトオーナーを用意する(一人で全体を見きれないた め)。 ✤ エリアが1つのLeSSになると考えるとよい(エリア内で計画、レビュー等がある) ✤ 開発チームはエリアフィーチャーチームとして作業する。単一エリア内は通常4∼ 8チーム(ただし新規エリア立ち上げ時は少ないこともある)。※個別にエリアを 切りすぎてしまうとほかのエリアに関心を持たなくなったりムダが生まれるため
18. 詳細情報 ✤ https://less.works/less/framework/introduction.html
