a. 例
LeSS Huge を導入した巨大なテレコムプロダクトのためのフィーチャーチーム導入マップ
https://scrapbox.io/files/649a8e60ddc9a4001cd6dead.png
導入開始時点では、一般的なコンポーネントチームだった
チームの対応範囲を拡張するという戦略を選択し、まずは 拡張したコンポーネントチーム を作った
次の数年間は フィーチャーチームに移行すること を目標とした
ただし、ある単一プロダクトグループによって作成された共有コンポーネントがあり、そのコンポーネントを対象範囲に入れるには組織の大幅な変更が必要となるため、このコンポーネントについては目標から除外していた
小さな LeSS Huge を導入した金融取引システムのためのフィーチャーチーム導入マップ
https://scrapbox.io/files/649a8ff6d23a6a001b6ad088.jpg
導入開始時点では、一般的なコンポーネントチームだった
一斉に フィーチャーチーム を導入する戦略を採ることにした
本番環境へのデプロイはまだフィーチャーチームのスコープ外だが、これは Done の定義がまだ不完全な状態であることが理由
プロダクトグループは 1 つの例外を除いてプロダクト全体にフィーチャーチームを導入したが、例外となった部分が非常に重要なコンポーネントで、別のプロダクトグループが担当していた
これにより導入に大幅な遅れが生じた
一斉に LeSS Huge を導入すると組織の変化の許容範囲を変えることが多く、これはその一例
筆者も一斉に LeSS Huge を導入することは非推奨
大規模な組織変更は政治の温床となる