在敏捷宣言面世十年后，在软件开发领域出现了规模化敏捷的框架，比如SAFe、Less等。大规模敏捷落地的确是一大难题，那么是不是我们遵守了规模化敏捷的框架标准，就实现了规模化敏捷呢？本质上，规模化敏捷是一个伪命题。大型软件开发中需要解决的问题，是复杂性问题和依赖性问题。复杂性问题和依赖性问题怎么去解决？不是依赖我们的框架，而是依赖于对问题的分析和拆解。

在规模化敏捷产品开发时， 有内部依赖和外部依赖。外部依赖则在产品以外，比如硬件组件或依赖其它产品。内部依赖，在产品内的非特性团队， 比如组件团队或集成团队。 对于产品内部的依赖，PO需要考虑如何拆分产品功能复杂性降低。特性团队的设计会消除依赖，对于共享代码的团队，其实不需要管理内部依赖。作为产品负责人始终关注依赖关系，尽早识别依赖关系，与所有人合作寻求帮助移除依赖。

“管理依赖”的文化将会阻碍基本解决方案的实施。最小化依赖关系的最佳方法是切除依赖关系，即没有依赖关系。通过以下方法我们彻底消除依赖：培训和拓展技能；复杂的架构简单化；减少组件的数目；组织设计并组建特性团队，充分发挥特性团队的能力。

组织不是通过简单扩大规模来处理大的复杂的问题，而是将复杂的问题分解成一个个小的部分，由小的团队来处理。特别对于大规模复杂的产品，自组织团队和团队单元的建立和辅导很重要。

任何一个团队必须历经塔克曼团队发展阶段模型的四个阶段：形成期、震荡期、规范期、成熟期。团队进入高绩效的状态，需要花费6-12月的时间和相当大的努力。我们传统的做法是：项目结束，把老团队拆散，新项目开始我们再重新组建新的团队。我们把人当作资源，可以替换也可以随时增加。 却忽略了人是有学习能力的，每个个体是一个复杂的自适应系统，有自己的价值观和理想。个体之间需要化时间与集成和融合， 成为真正的团队。

因此，我们需要把钱花在组建一支稳定的团队上，他们是专注于某个产品的一个稳定单元，而不是项目完成之后解散团队。我们要创建跨职能团队，团队成员来自不同的职能部门：包括业务分析师、设计师、开发人员、测试人员。核心团队成员都是全职的投入到产品中。工作应该尽可能由小型的、自主的、跨职能的团队在短周期内完成相对较小的最高价值工作，并从最终用户那里获得即使持续的反馈。

帮助成就自组织敏捷团队的这个管理框架就是Scrum，也是企业导入敏捷思想，团队落地敏捷的简单游戏规则. Scrum框架“进化价值交付”的两个关键特征：

(1) 增量产品交付：以一种被叫做迭代 (Sprint)的小块的形式将产品交付到市场；

(2) 过程迭代：很短时间盒内以小颗粒度的工作级别执行整个软件生命周期中的计划，设计，开发，测试，发布这些流程，重复。

一旦一个组织内团队在一段时间内不懈地追求和实践Scrum，拥抱敏捷思维，就会对组织产生潜移默化的影响：组织做计划的方式，人们工作的方式（比如做决定和解决冲突），领导力的方式，都会改变，一个高效自治组织单元会渐进形成。从组织的角度来看，工作单元变成了团队，而不再是个人。通过在短周期内工作，团队很容易调整方向。

稳定的小团队构成了规模化敏捷组织交付价值给客户的基本单元。这样的团队具备精益创业型的特质。以Scrum 价值观作为工作文化，Scrum团队是一个充满激情，学习型的，有机的，自适应生命体。没有建立和打造这样的团队作为基石，规模化敏捷都是空中楼阁。

我们在引入和定制规模化敏捷的方法时，要时刻记住我们的目的什么？如何减少复杂性，如何避免依赖关系，应满足和遵从如下原则：

1、简洁，不能增加复杂性，对待复杂问题不能依靠复杂的套路来解决，增加角色，流程，结构，层级，物件都会使问题更加复杂化，我们要遵从Scrum的框架；

2、需要我们组织的身体力行，进化出最适合的多团队以上的组织设计架构；最大化聚集多个团队一起工作的价值流；

3、多个敏捷团队的能量，热情，士气依然像单个Scrum 团队一样得到最大释放，而不是被压制；

4、管理层和领导力的重新定义和定位，敏捷文化驱动组织最大化价值的产生。

解决问题的最终是一个个的小团队，怎么把问题拆解到一个个小团队，才是解决规模化问题的复杂性和依赖性之道。