大規模スクラム（LeSS）：概要と比較

Scrumを採用してアジャイルなチームが3つあるとして、スケールしたいとします。Scrumだけではもう不十分です。どうすればいいでしょうか？そのために、いくつかのフレームワークがあります。 セーフ Nexusなど、他にもたくさんある。今日はLeSSを詳しく見てみよう。

LeSSはSCRUMである（定義）

(その) LeSSフレームワーク Scrumの原則と理想を、定義されたルールとガイドラインによって、大企業のコンテキストで可能な限り簡単に適用しようとするものです。そのシンプルさから、LeSSは「必要最低限」のフレームワークという定義、またはラベルを与えられていますが、それは決してネガティブな意味ではありません。

7 LeSSフレームワークの利点

LeSSの基本的な焦点は、別の新しいフレームワークを作ることではない。その代わりに、スクラムの原則を多くのチームに適用する。

以下のような利点がある。 LeSS を達成することができる：

1. 導入コストの低減 チームがすでにスクラムで使用しているプラクティスを導入することによって、次のことが可能になる。
2. プロダクト・オーナーフレームワークと原則を理解し、ビジネスチームと技術チームの橋渡しをする。
3. についてである。 製品の配達をする人が少なくなる 必要である。LeSSは、指数関数的に役割やオーバーヘッドを増やすことはない。
4. を提供している。 製品全景 フォーカスエリア内
5. (その) チームは直接連絡を取り合っている 顧客およびその他の利害関係者と 
6. 継続的な改善 これはAgilenマニフェストの基本的なプロセスである。
7. 多くの企業にとって、スクラムチームを拡大するためのLeSSのアプローチは次のようなものだろう。 アジャイル・スケーリングへの次の論理的ステップである。.

LeSSはどのように構成されているのか？定義

定義によれば、大規模スクラムは原則、フレームワーク、ガイドライン、実験の上に構築される。図解（出典 LeSSウェブサイト)がそれを示している。例を挙げて説明しよう： 

原則：チームXが携帯電話を開発しています。彼らは透明性を持って行動することを重要視しています。そのため、彼らは一方では透明性を持って仕事をし、定期的なデイリーを行います。さらに、携帯電話の生産に重要な材料がどこから来ているのかを正確に把握し、後でそれを顧客に透明性を持って伝えることも望んでいます。つまり、透明性を徹底しているのです。

フレームワークの条件同時に、SCRUMのフレームワークを理想的なものにするためのフレームワークの条件を作るための努力も続けている。 アジャイル・バリュー を定義する：開放性、勇気、尊敬、集中、そして献身である。

指導原則：開発の指導原則とは、製品のビジョン、製品の技術的要件、さらにはチーム内での協力の仕方である。

実験：不確定要素が生じた場合、私たちは実験の領域に入り、そこで物事をテストし、試してみることになる。例えば、新しい機能を開発したり、まったく新しいターゲットグループを開拓したりする場合だ。(出典 LeSSウェブサイト)

LeSSの10原則

LeSSの定義 10原則。例えば、お客様の価値観や考え方に最も合致する携帯電話を開発するのに役立ちます。以下に、10の原則のリストを一目でわかるように示します。

1. 大規模スクラムはスクラムである： 携帯電話は1つのチームだけでなく、複数のチームによって開発することができるため、顧客は満足し、開発期間は合理的である。
2. 経験的プロセス制御： 短期的な経験に基づき、携帯電話の個々の機能は継続的に適応され、絶えず改訂されている。
3. 透明性： 私たちのチームXは、今後、毎週のチーム目標を社内のプラットフォームでオープンに共有することにした。これは、全員が実際に何に取り組んでいるかを理解するのに非常に役立つ。
4. より少ないものでより多くを得る： 基本的に、不活性なルールを確立して “バラスト “を追加する前に、新しいアイデアを試し、そこから学ぶべきである。
5. 全製品に焦点を当てている： チームには、個人以上に目標を最適化できない傾向がある。したがって、チームにとっての最大の課題は、自分たちの仕事を製品に統合することである。したがって、製品全体の「目的」はできるだけ明確でなければならない。そのため、チームや個人には、必要に応じて適切な小目標を自ら定義する権限が与えられる。
6. 顧客中心主義である： 顧客と直接仕事をするチームだけが、製品の真の価値を最大化することができる。残念なことに、組織はチームが成長し始めるとすぐに顧客から切り離す傾向がある。これに対抗するため、例えば、顧客は定期的にチームのミーティングに招かれ、フィードバックを受ける。
7. 完璧を目指して改善を続ける： LeSSは多くの組織にとって大きな変化です。ただし、それが自動的に改善を意味するわけではないことに注意してください。LeSSは、組織がより良くなるためのスタートを支援し、その後は継続的に最適化していくべきです。LeSSはプロセスです！
8. リーン・シンキングだ： LeSSは、何よりもその場（ゲンバ）を見ることを重視し、3段階の学習コンセプトを掲げている。 シュハールi（Shu＝真似る、Ha＝変化させる、Ri＝自分のルールを決める）、そして人を尊重する。
9. システム思考だ： すべての行動、変化、改善は、目標を達成するために、常に体系的に、またはシステムに準拠して考えられるべきです。例：チームに理論的に финансовые ボーナスを提示する場合、それは他のチーム（つまり、組織システムの残りの部分）にとって何を意味するのでしょうか？
10. 待ち行列理論： 基本的な考え方は、ソフトウェアの世界では、私たちは目に見えないキュー（例えば、要求文書やテストされていないソフトウェア）をたくさん作り上げ、これらのキューの最適な処理についてはほとんど気にしないということである。例えば、リソースの利用率が50%から90%に増加した場合、新しいタスクの待ち時間はおよそ2倍になるのではなく、倍増することをご存知だろうか？そのため、WIP（仕掛品）制限を定義し、マルチタスクや大規模な作業パッケージを避ける。 

LeSSのフレームワーク

LeSSには2つのコンフィギュレーションがある： 基本的なLeSS のためのものである。 2～8チーム (10名から50名）と LeSS 巨大な のためのものである。 8チーム以上 (50人から6,000人以上）。

ソースはこちらだ： Less.works

LeSS Hugeに直接移行する前に、実験し、経験を積み、フィードバックを得るためにBasic LeSSから始めることを推奨する。LeSS Hugeの導入には2つのアプローチが提案されている：

• 大きな製品の中で、一度に1つの要求領域から始め、最初はそれだけに集中する。
• あるいは、チームの作業範囲、完了定義、製品定義を徐々に拡大していく。

このようにして、企業はLeSSでのチーム経験を積み、製品分野を拡大し、最初の成功を収めることができます。そして、LeSSが企業全体に拡大される前に、経営陣のサポートを得ることができます。

ちなみに、アジャイル変革の文脈で簡単な注意点です。現在のアジャイル変革において、適切な優先順位を設定していることを確認したいですか？ 

Dann mach unseren Reifegrad-Check für eure agile Transformation - dauert nur 3 Minuten. Du bekommst sogar einen Benchmark auf Basis der über dreihundert anderen Teilnehmer*innen. Siehe Button 🙂

LeSSにおける役割と計画

基本的なLeSSは、チームと最も重要なスクラムの役割に焦点を当てている：

1. スクラムプロダクトオーナーは、製品のビジョンと方向性に責任を持つ。
2. スクラム開発チームが製品の創造と提供を担当する
3. スクラムマスターは、チームの継続的な改善をサポートする。
4. マネジャーの役割と、マネジャーが継続的改善と自律性を妨げる障害や「阻害要因」を取り除くためにチームをどのようにサポートするか（SCRUMの拡張）。

巨大なLeSSは、基本的なLeSSを以下の役割で補完する：

1. LeSS Hugeの地域プロダクトオーナーはプロダクトオーナーをサポートし、ビジネス要件（財務など）と開発チームをつなぐ重要な役割を担う。
2. エリアプロダクトオーナーは、顧客志向のタスクを専門とし、製品志向のフィーチャーチームのプロダクトオーナーとして活動する。

PBRミーティングは、一連の並行したLeSSスプリントの実行を通じて、フォーカスエリア全体のスプリント計画を拡張する。各スプリントにおいて、要素を理解し、議論し、洗練させ、将来のスプリントに備えるために、これらのミーティングを継続的に行うことが必要である。PBRミーティングの主な活動は以下の通りである： 

1. Erstellung von Epics - also Clusterung großer zusammenpassender Themenbereiche; in unserem Beispiel wäre das die Zusammenlegung der Sprints vom Design & Usability Team
2. オープンな質問の明確化と回答：顧客や同僚のアイデアや製品について、全員が同じ理解を持つべきである。
3. ユーザーストーリーのサイズ、リスク、依存関係の見積もり：個々のトピックの準導出と詳細計画

(その) スプリント・レビュー

スクラムに相当するもの：スプリントレビューとは、スプリントの終わりに行われるミーティングで、スプリントのゴールに関連して行われた作業を評価するものである。これは製品そのものに関するものである。進捗が可視化され、新たな行動領域が特定される。これにより、製品とゴールに関する進捗が透明化される。

(その) レトロスペクティブ 

スクラムと似ている：レトロスペクティブは、チームの協力関係を扱うミーティングである。チーム内のコラボレーションを改善することであり、プロセスと内容を改善することである。また、個々の開発者間の相互作用、スクラムマスターの作業、プロダクトオーナーとのコミュニケーションにも関係する。これにより、レトロスペクティブは継続的改善プロセス（CIP）の重要な一部となる。

Bei Large Scale Scrum wird teilweise empfohlen, eine “Retro of Retros” durchzuführen - also übergeordnet über viele Teams hinweg.

Large Scale Scrum - Scrum Master Ratio

スクラムマスターは何チーム担当すべきでしょうか？ チームごとに1人のスクラムマスターが最適であると主張できますが、これも デメリット は持っている。 原則として Large Scale Scrum Master Ratioは1:1から1:3です。スクラムマスターは1つから最大3つのチームを担当します。

大規模スクラムLeSSがAgileの手法として正しいのはどのような場合か？

ラージスケールスクラムは、すでにSCRUMを使用していて、スクラムの規模を拡大したい場合に使用できる。また、自己組織化とルールの間のバランスを見つけることもできる。 

バス・ヴォッデ と語ったことがある。 クレイグ・ラーマン LeSSは、必要な指導と可能な限り少ない指導の間のスイートスポットを突いているため、非常に優れたアプローチだと信じている。 

スクラムそのものと同様に、スクラムはプロセスフレームワークに過ぎず、それを使用するチームによって非常に個別かつ多様に設計することができる。この主張はもっともらしく、実際にラージスケールスクラム（LeSS）は他のスケーリングフレームワークとは一線を画している。

イラストレーションだ： スイートスポット 

比較：大規模スクラムとスクラムの比較

LeSSはスクラムの上に構築され、より広い文脈での使用をサポートし、より大きな組織や1つのチームを超えて拡大する。だから、どちらか一方という問題はない。LeSSはSCRUMの拡張である。だからLeSSを導入するには、必ずスクラムが必要だ。まずSCRUMを導入し、それからLeSSに切り替えるのは理にかなっている。

比較：大規模スクラムと大規模AgileフレームワークSAFe®の比較。

LeSSは大規模なソフトウェア開発チームを抱える企業でますます人気が高まっているが、スクラム・オブ・スクラムやスクラム@スケールといった他のスケーラブルなアジャイルフレームワークも重要性を増している。代表的なフレームワークの1つは スケールドAgileフレームワーク®（SAFe）.

大規模スクラムとスケールドAgileフレームワークSAFe®の間には多くの類似点がある。例えば、どちらもスクラムチームをスケールさせ、リーン思考、継続的改善、顧客重視などの原則を取り入れることから始める。 

3 ラージスケールスクラムとスケールドAgileフレームワークSAFe®の主な違い

1. 組織である： LeSSは、柔軟性と適応性を維持することで、組織構造を簡素化することに重点を置いている。
2. 役割だ： SAFeには、リリーストレインエンジニア（RTE）、ソリューショントレインエンジニア（STE）、エピックオーナーなどの役割が追加されている（このため、「オーバーヘッド」が増えたとも言われている）。
3. 実施する： Scaled AgileフレームワークSAFe®には、組織によっては採用できないプロセス、成果物、組織変更が含まれている。そのため、どのフレームワークが自分と組織に合っているかを常に検討する必要がある。

大規模スクラムの導入を成功させるために

大規模スクラムを成功させるには、長年の前提を打ち破り、企業構造を変える必要があります。これは、対応する変化がもたらす「トップレベル」での爆発的な可能性と「メンツの喪失」を伴います。 

したがって、基本は、全員がこの変化に同意することです。これについては、以下も参照してください。 コッターによるチェンジ・マネジメント・モデル に関する我々の記事も参照のこと。 Agile変革ロードマップ .

魅力的なビジョンを描いて、それに向かって努力する。そして、実験的な意味で、多くの変革プロジェクトを一度に開始する。 

当初の目標が達成されると、変更は完了し、組織は次の変更が差し迫るまで新しい現状に適応する。 

この古典的なアプローチは、逐次的なアプローチと似ている。 「ビッグバッチ・アプローチ 参照 図)のソフトウェア開発では、変更は例外であり、管理機関によって厳密に管理される。

LeSSの導入には変革イニシアチブ、つまりチェンジマネージャーは存在しません。LeSSでは、変化は実験と改善を通じて継続的に行われます。変化が現状なのです。

成功するためのステップとは何か？

1. チーム文化を転換、適応、変化させる。

チームと組織が新しいアジャイル文化について十分な経験を積み、責任ある意思決定者が次のステップを開始するまで、まずはスクラムチームから始めることを推奨する。これはまた、誤った開発のリスクを減らすことにもなる。

2. チーム内の協力関係を改善する

1つの製品に複数のチームがスケーラブルに取り組むには、アジャイル・プラクティスを導入する必要がある。チーム間の調整を容易にするプラクティスは、特に重要である。最初のチームは、組織の他のチームのパイオニアとして、まだ多くの実験をしなければならない。 

チームが組織の他の部分から本当に切り離されていれば、それに応じて組織の進歩も速くなる。これは、管理可能な枠組みの中で、より速く、より少ないリスクで行うことができる。

3. 企業構造の変化

アジャイル組織のさらなる成長は、あらゆるレベルでの再構築を意味します。遅くともこの時点で、変革の発起人は経営陣を巻き込む必要があります。チームと企業のトップとの間のすべてのレベルが問われ、組織構造は非常にスリムになります。これはおそらくプロセスの中で最も「苦痛」な部分であり、特に経営陣にとってはそうです。

4. 企業文化の変化

スクラムとLeSSのフレームワークと適切なアジャイルプラクティスを企業の全領域に適用することで、アジャイル文化を組織全体で学ぶことができる。最適なアジャイル組織は存在しないため、プロセスが停止することはない。

スクラム、LeSS、LeSS HugeによるAgileへの移行には、先見性のある戦略が必要である。そのため、適切なアドバイスとトレーニングが必要である。

もし、あなたがまだ適切なレトロボードを探しているのであれば、我々の記事が役に立つだろう： それに比べて最高のレトロボードだ。