Upcoming course:Provisional Certified LeSS Practitioner: Principles to Practices@(Online) Rockville Centre@April 3, 2023

LeSSのルール (February 2016 (5))

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

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

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

LeSSの構造

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

LeSSのプロダクト

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

LeSSのスプリント

必ず１つのプロダクトに関わるチームは同じスプリント周期を守る事。全てのチームのスプリントの開始と終わりは同じタイミングであること。スプリントの終わりにはプロダクト全体が１つに結合されている状態にすること。
スプリント計画は２つのパートに分かれる：スプリント計画１部は全てのチームが一緒に行う。但し、スプリント計画２部は各チームに分かれて別々で行います。ただし、関連性が強いアイテムを持っているチームは同じ場所で行う。
スプリント計画１部はプロダクトオーナーと全チーム又はチームの代表にて行われる。仮で各チームが次のスプリントで何をするかを選び、他チームと協働する部分がないかや不明確な点はないかを議論して、最終的に各チームがやることを決定する。一旦、各チームが次のスプリントに何を行うかを選択し、内容の不明点を聞き、他のチームと協働する部分は無いかの確認を行う。
各チームはチームごとのスプリントバックログを有する。
スプリント計画２部は各チームがどうアイテムを実現させるかを考える場であり、設計とスプリントバックログを作る事になる。
デイリースクラムはチーム単位で行う。
チーム横断での調整はチームに委ねられている。中央集権的で形式的な調整ではなく、個別の判断で自由に調整する方が好ましい。重要なのはお互いに会話をする事（単純だができて無い事が多い）、コード上でのコミュニケーション、チーム横断での会議、コンポーネントメンター、旅行者、偵察、そしてオープンスペース。
プロダクトバックログリファインメント（PBR）は各チームでそのチームが対応する可能性が高いアイテムをリファインする。チーム間での共通認識作りや調整機会を増やす為に領域が近いアイテムや広い領域の理解が必要な場合には複数チーム又はオーバーオールPBRを行う。
スプリントレビューは全てのチームで行う。検証と適応を行うのに十分な情報を得られるように必要なステークホルダーが参加しているようにすること。
スプリントレトロスペクティブは各チームで行う。
オーバーオールレトロスペクティブは各チームのレトロスペクティブの後に行われる。ここでは複数チームの共通課題や広い領域の課題を扱い、改善に向けての試みを決める。この場にはプロダクトオーナー、全スクラムマスター、チーム代表とマネージャー（いる場合）が参加する。

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

LeSS Hugeはプロダクトを８チーム以上で作る場合に適応されます。これよりも小さな規模でLeSS Hugeを適応する事は不必要なオーバーヘッドや部分最適の原因となり、推奨しない。

特に明記しませんがすべてのLeSSのルールがLeSS Hugeに適用される。

LeSS Hugeの構造

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

LeSS Hugeのプロダクト

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

LeSS Hugeのスプリント

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