《敏捷宣言》发布后，“敏捷”被越来越多的小型开发团队认可。与此同时，另一个问题也逐渐暴露了出来：以 Scrum 为首的敏捷方法论对那些大规模的开发团队并不友好。
基于此，业界开始探寻能够达到多个团队协作开发最佳效率的办法。直至2005年，当时在诺基亚公司工作的 Bas Vodde（一位精益敏捷教练）和 Craig Larman（一名组织设计顾问）对此产生了莫大的兴趣，两人一拍即合。凭借 Bas 对 Scrum 等敏捷方法的应用，以及 Craig 对产品开发流程的熟悉程度，他们打造了一款适合于多团队的规模化敏捷框架——Large Scale Scrum（LeSS）。
对于如何大规模实践 Scrum 这一问题，Bas 和 Craig 找到了完美的答案。
实际上，LeSS 框架就是将 Scrum 框架放大，并应用于多团队管理层级中，因此，LeSS 保留了很多 Scrum 中的基本要素，例如：每日站会、产品待办列表、Sprint 计划会议、Sprint 评审会议、回顾会议等。但在 Scrum 框架的基础上，LeSS 框架又延伸出比之更大的范围。
对于多团队来说，规则越少，实践的门槛就会越低。因此，LeSS 框架是一个极简框架，以真正的团队作为基本构建块来进行整个组织的架构。另外，在创建 LeSS 的过程中，Bas Vodde 和 Craig Larman 尽可能地减少定义的输入，更多的是推动团队凭自身经验创建适合自己的流程。
LeSS 具体细化为两种框架：一种是适用于8个小团队进行开发，每组最多8人的“LeSS”；另一种是协调、管理多达上千人的团队的“LeSS Huge”。不论是哪一种具体的框架，对团队自身的要求都不会改变。
1. LeSS 团队要求是自管理的
一个自管理的团队，能够帮助各团队成员之间增强协同能力，提高团队工作效率。这里的一个大前提就是，各团队有一个共同的愿景和为之奋斗的目标，让每一位成员都有“主人翁”意识。
2. LeSS 团队要求是跨职能的
Craig Larman 解释，“与其引入一种方法，在这基础上打各种补丁的话，倒不如尝试改变组织架构，创建一个跨职能的团队。”跨职能的团队具有很大的灵活性，能够更快地响应不断变化的需求，并能更好地处理团队之间的协作问题。
3. LeSS 团队要求是协同办公的
多个团队协作办公，以更快地为客户交付新的产品。无论如何，需要打破部门和团队间的壁垒，通过不断地学习、试错来帮助各团队、各成员之间快速适应。与此同时，与其他流程部门之间的沟通、交流也能够为团队增加新的可能。
4. LeSS 团队要求是长期存在的
由于 LeSS 面向的是多个团队，这就要求各团队的组合不能随意变动。因为团队的目标是长期的，所以通过将大目标分解为小目标，协调各个团队步调一致，才能实现项目的成功。如若各个团队随意组合，那么最初拟定的计划则会被全盘打散。
总的来说，LeSS 团队与小型敏捷团队的要求没有太大的差别。但 LeSS 框架是如何做到，既能在团队间保留足够的灵活能力和扩展能力，又能有充足的时间来启动整个流程的呢？LeSS 框架具体又应如何实践呢？且听下回分解。
