LeSS は、複数のチームが一つのプロダクトを開発するために、1チームのスクラムを組織全体へ広げる枠組みである。 一人のプロダクトオーナー、一つのプロダクトバックログ、一つの Done の定義、一つの共通スプリントを置き、職能別や部品別ではなく、顧客価値を端から端まで届けられる長期的なチームを基本単位にする。 会議を増やしてチーム間を調整する手法ではなく、複数チームを一つのプロダクトへ向ける組織設計と考えるほうが近い。
LeSS のルールは必須事項として定義され、対象とするプロダクト群では導入時に完全な LeSS の構造を設けることを求めている。 したがって、全体ふりかえりや複数チームでのプロダクトバックログリファインメントだけを取り入れても、それを LeSS の導入とは呼べない。 各要素が相互に補強し合うため、都合のよい要素だけを選ぶと、一つのプロダクトへ向けた優先順位と統合された成果物という狙いを失ったまま、会議の負担だけが残ることもある。
ただし、LeSS から得た一つのやり方を、明示した問題に対する期限付きの実験として試すことまで否定する必要はない。 たとえば、チーム間の依存関係を発見できないという問題に対して全体ふりかえりを試し、観察する指標と見直す時期を決めることはできる。 この場合は「LeSS を部分導入した」のではなく、「LeSS を参考に改善実験をした」と捉える。
スクラムを最初に教科書どおり行うという勧めも、儀式への服従が目的ではない。 スクラムガイドは、要素を省くと問題が隠れて効果が制限される一方で、枠組みの内側で文脈に応じた手法を使えるとしている。 まず全体を一定期間使うのは、変更前に各要素の目的と相互作用を経験し、後の変更が適応なのか、見たくない問題の回避なのかを区別するためである。
LeSS の導入範囲は組織全体でなくてもよく、一つのプロダクト群へ狭く深く適用することが推奨されている。 範囲は狭められるが、その範囲の内部では仕組みを一式で試すという境界になる。
https://less.works/jp/less/framework
https://less.works/less/adoption/three-principles