LeSSのルール (December 2020)

(前のバージョンからの変更点)
LeSSのルールはLeSSフレームワークを定義するものである。これらは最も重要な点である。なぜLeSSなのかについてはこちら Why LeSS? を参照ください。

LeSSフレームワークのルール

LeSSフレームワークは2〜8チームでの開発向けである。

LeSSの構造

チームを組織の基本単位とし、個人ではなくチーム単位で組織を構成すること。
それぞれのチームは①自律的②クロスファンクショナル③同一拠点④長期間存続していること。
ほとんどのチームは顧客中心のフィーチャーチームであること。
スクラムマスターはLeSS導入が問題無く行われる事に責任を持つ。そして、チーム、プロダクトオーナー、組織、技術的手法の改善に注力し、１チームだけの改善にとどまる事なく、組織全体の改善を行う必要がある。
スクラムマスターは専任でフルタイムであるべき。
１人のスクラムマスターが１〜３チームを支援できます。
LeSSではマネージャーの存在は任意だが、存在する場合は役割が変わる可能性が高い。マネージャーは日々のプロダクト開発を管理するのではなく、より高い価値提供ができるようにプロダクト開発全体を改善していく事になる。
マネージャーの役割は現地現物Go Seeによりプロダクト開発の改善を推進する事である。また、プロダクトグループ全体に対し、問題を発見したらすぐに開発を止めて問題を解決する事を推奨する。
LeSS導入の初期からプロダクトグループにLeSSの構造を完全な形で導入する事は非常に重要なポイントとなる。
LeSSの導入を単一のプロダクト開発グループだけでなく、組織全体に広げていく事で、現地現物の考え方が広がり、実験や改善があたりまえとなる環境を作っていく事ができる。

LeSSのプロダクト

１つの出荷可能なプロダクトに対して１人のプロダクトオーナーと１つのプロダクトバックログで運用を行う。
プロダクトオーナーは1人でプロダクトバックログリファインメントを行うべきでは無く、幾つかのチームが顧客やユーザー、ステークホルダーと直接コミュニケーションをとり、プロダクトオーナーをサポートしている状態であるべきである。
全ての優先順位付けはプロダクトオーナーに集約するべきだが、要求や仕様の詳細確認は極力チーム間や顧客、ユーザー又はステークホルダーと直接やるべきである。
プロダクトの定義は可能な限り広く、エンドユーザー又は顧客の視点で定義するのが良く、時間の経過とともにプロダクトの定義は拡張されていき、より広い定義とするのが望ましい。
プロダクト全体で１つの完成の定義を有し、全てのチームで共通の完成の定義となっている。
各チームは全体の完成の定義を強化した個別の拡張した完成の定義を持つ事ができる。
完璧なゴールは完成の定義を拡張し、毎スプリント出荷可能な製品を作れるようになる事である。（さらに頻度を上げる事に挑戦するのも良い）

LeSSのスプリント

必ず１つのプロダクトに関わるチームは同じスプリント周期を守る事。全てのチームのスプリントの開始と終わりは同じタイミングであること。スプリントの終わりにはプロダクト全体が１つに結合されている状態にすること。
スプリント計画は２つのパートに分かれる：スプリント計画１は全てのチームが一緒に行う。但し、スプリント計画２は各チームに分かれて別々で行う。ただし、関連性が強いアイテムを開発するチームは複数チームでの計画を同じ場所で協働して行う。
スプリント計画１はプロダクトオーナーと全チーム又はチームの代表にて行われる。各チームが次のスプリントで何をするかを選び、他チームと協働する機会がないかを検討したり、不明確な点があれば質問をして明確化をおこなう。
各チームはチームごとのスプリントバックログを有する。
スプリント計画２は各チームがどのようにアイテムを実現させるかを考える場なので、設計をしてスプリントバックログを作る事になる。
デイリースクラムはチーム単位で行う。
チーム横断での調整はチームに委ねられている。集約的で形式的な調整ではなく、分散的で型にはまらない自由な調整の方が好ましい。重要なのはお互いに、ただ話す事（単純だができて無い事が多い）、そして、コード上でのコミュニケーション、チーム横断での会議、コンポーネントメンター、トラベラー、スカウト、オープンスペースなどの形式ばらないコミュニケーション手法を使う。
プロダクトバックログリファインメント（PBR）は複数チームで行うのが好ましい。複数チームで実施することにより、お互いに学び、協働する機会を増やすことにつながる。
スプリントレビューはプロダクト単位で実施するので、全チームが集まり、効果的な検証と適応が行われるように適切なステークホルダーも必ず招待し、フィードバックが得れるような環境にする。
スプリントレトロスペクティブは各チームで行う。
オーバーオールレトロスペクティブは各チームのレトロスペクティブの後に行われる。ここでは複数チームの共通課題や広い領域の課題を扱い、改善に向けてのどのような実験をするか決める。この場にはプロダクトオーナー、スクラムマスター、チーム代表とマネージャー（いる場合）が参加する。

LeSS Hugeフレームワークのルール

LeSS Hugeはプロダクトを８チーム以上で作る場合に適応されます。これよりも小さな規模でLeSSHugeを適応する事は不必要なオーバーヘッドや部分最適の原因となり、推奨しない。
個別に明記されてない限り、すべてのLeSSのルールがLeSS Hugeにも適用される。そして、すべての要求エリアは基本のLeSSフレームワークと同じ動きとなる。

LeSS Hugeの構造

顧客の要望は顧客視点での分類がされ、要求エリアと紐付く。
各チームは１つの要求エリアを専門的に対応する。チームは担当するエリアを頻繁に変えることはせず、長期間固定する。ただし、他のエリアの要求が増えて来た場合はエリアを移動することもある。
各要求エリアには１人のエリアプロダクトオーナーを設ける。
それぞれのエリアは４−８チームとし、このチーム数の範囲を守るようにする。
LeSS Hugeの導入には組織の構造を変える事が伴います。この変更は１度に行わず少しずつ変えていくようにする。
覚えておいて下さい。LeSS Hugeの導入は数ヶ月〜数年を要します。忍耐と多少のユーモアを持って進めてください。

LeSS Hugeのプロダクト

（全体の）プロダクトオーナーは1人でプロダクト全体の優先順位決めと、どのチームがどのエリアを対応するかを決める。そして、エリアプロダクトオーナーと密にコミュニケーションを取る必要がある。
エリアプロダクトオーナーは該当エリアのチームに対してプロダクトオナーとして振舞う。
プロダクトバックログは１つである。そして全てのアイテムは必ずどこか１つの要求エリアに属する。
各要求エリアには必ず１つのエリアプロダクトバックログが存在し、このバックログはプロダクトバックログよりも粒度が細かいものとなる。

LeSS Hugeのスプリント

プロダクト単位で共通のスプリント期間とする。各要求エリアで別々のスプリント期間とする事は無い。スプリントの終わりには統合された１つのプロダクトになっている必要がある。
プロダクトオーナーとエリアプロダクトオーナーは頻繁に同期し、スプリント計画時にチームが最も価値の高いアイテムに着手できるように準備する必要がある。スプリントレビュー後にはプロダクト横断で何を適応すべきか認識を合わせる。