上篇文章《 LeSS 团队实践指南》中讲到 LeSS 框架中的团队数量不要超过8个，但8个以上的团队要如何实践敏捷呢？
为了应对8个以上团队实践敏捷的情况，Bas 以及 Carig 还提出了 LeSS Huge：一个通过在多个小型 LeSS 框架堆叠的基础上扩展的规模化敏捷框架。
一、需求领域
LeSS Huge 按照产品中的客户需求，划分出不同的需求领域，每一需求领域由几个相应的功能团队组成。也就是说，需求领域是按比例放大的功能团队。
举一个例子来进一步说明需求领域：在一个小型的保险团队中，会有合同承保、合同修改以及索赔三个功能角色，LeSS Huge 中可以将一个大型保险团队分为合同承保、合同修改以及索赔三个需求领域，每一领域有几个相对应的功能团队。这里要注意的是，需求领域具有临时性，会根据产品的需求在整个生命周期内进行调整（不会在每一迭代中改变）。
二、产品负责人团队
首先需要解决一个产品负责人无法协调众多团队的问题。LeSS Huge 增加了产品负责人团队的概念：划分不同的需求领域，每一需求领域增加一名区域产品负责人，该区域产品负责人会对该需求区域的产品需求做出优先级决定。
由于需求区域大小不同，每个区域会包含不同数量的团队，团队太小会导致积压事项，团队太大则会导致区域产品负责人无法协调，因此一个合理的需求区域所包含的团队数量在4-10之间。
产品负责人团队由产品负责人主导，即产品负责人始终拥有最终决定权，且产品范围及产品发布时间仍由产品负责人决定。
三、区域产品待办列表
针对某一需求领域归纳整理出该领域的产品待办列表，这一事项由该区域产品负责人负责。相比产品待办列表而言，区域产品待办列表内包含的是更易于管理、颗粒度更细的项目。但如果区域产品待办列表与产品待办列表出现很大的差异的时候，就需要考虑重新整理产品待办列表了。
四、一个产品级 Sprint
同 LeSS 框架一样，LeSS Huge 框架中所有团队都处于一个 Sprint 之下，又以交付一个集成的整体产品增量结束。
其次，无论是 Sprint 计划会议2、Sprint 评审会议还是 Sprint 回顾会议，都可以以一个需求领域为单位来组织会议活动。为了对齐计划与进度，区域产品负责人要经常与产品负责人同步，从而及时发现团队方向是否出现了偏差，团队是否处理的是最有价值的项目等。
五、由点到面的 LeSS Huge 实践
由于团队规模庞大，实现一次性采用 LeSS Huge 框架会有很大的风险，因此，LeSS Huge 的实践应循序渐进地进行。
首先，应先完善一个需求领域，其次逐步扩大团队的工作范围以及完成的定义，与此同时，让其他团队做好转型的准备，逐步适应 LeSS Huge 框架，实现由点到面的规模化敏捷转型。规模化敏捷实践的转型往往需要很长时间，急功近利并不可取。
LeSS Huge 在 Scrum 以及 LeSS 的基础上，重新扩展了敏捷框架，降低了大型团队管理的复杂。其中，最重要的还是团队之间的协作性与互通性，而 LeSS 强调的更加灵活的团队便是要着重实现这一点。