LeSS と SVPG は、フィーチャーチームという同じ語を別の評価軸に使っている。 LeSS はチームが変更できる技術的な範囲を問題にし、SVPG はチームに与えられる意思決定の範囲を問題にする。
LeSS のフィーチャーチームは、特定の部品だけを担当するコンポーネントチームとの対比で定義される。 長く存続し、職能と部品をまたぎ、顧客にとって意味のある機能を端から端まで完成できるチームを指す。 ここでの「フィーチャー」は、経営層から指定された機能を作るだけという意味を含まない。
SVPG が批判するフィーチャーチームは、解くべき問題や事業成果ではなく、優先順位と期日の付いた機能を渡されるチームである。 対照となるプロダクトチームは、プロダクト、デザイン、開発の職能を持ち、顧客と事業の問題に対する解決策を発見し、その成果に責任を持つ。 SVPG 自身も、このフィーチャーチームという用法が標準的な定義ではないと断っている。
したがって、一つのチームは LeSS の意味ではフィーチャーチームであり、SVPG の意味ではプロダクトチームであり得る。 部品をまたいで実装できる能力を持ち、同時に、機能ではなく問題を渡され、顧客とともに解決策を発見するチームである。
LeSS も、プロダクトバックログの項目の多くを目標、仮説、成果、顧客項目とし、チームが顧客と直接対話して解決策を共創することを勧めている。 この点では SVPG のプロダクトチームと両立する。 ただし LeSS は複数チームに一人のプロダクトオーナーを置き、その人がプロダクト全体の優先順位と最終判断を担うため、各チームにプロダクトマネージャーを置いて価値と事業成立性の責任を持たせる SVPG の役割設計とは一致しない。
LeSS を検討するときは、フィーチャーチームという名称で判断せず、チームが「何を作るか」まで決められるかを別に確認する必要がある。 LeSS の組織設計を採用しても、解決策を上から渡せば SVPG のいうフィーチャーチームになる。
https://less.works/less/structure/feature-teams
https://less.works/less/framework/product-owner
https://less.works/less/framework/product-backlog