每次听到大家探讨规模化敏捷，都是关于用SAFe还是Less呢？DAD还是Spotify？这些只是具体的框架，规模化敏捷不只是这些东西。
为什么要考虑规模化?
很多团队运用Scrum、看板等敏捷方法，结合持续集成、测试自动化、持续交付流水线等工程实践，已经具备较高的成熟度。但是在大型组织里，企业面临的挑战远超过单个团队所能控制的范围。在这些组织里，一个产品的交付，需要几十人、几百人、甚至上千人共同完成。他们面临着如下挑战：
如何凝聚目标，对齐节奏，解决团队与团队之间的依赖，共同交付产品？
在更大的范围里，如何拉通整个产品价值流的各个环节所涉及的部门，把所有的相关角色、和相关的敏捷实践高效、有机地串联起来系统化运作，达到缩短Time To Market的目标？
整个企业如何应对市场和技术的不确定性，让人事、行政、财务、市场等非产品研发部门高效地支撑业务，不成为组织转型的重力作用，从而在整个企业范围内实现业务敏捷性？
这些问题正是敏捷规模化要解决的问题。
规模化敏捷的几种模式
Bob Hartman提出规模化敏捷有这样几种模式：
1.从产品交付维度，有两种规模化：
产品级规模化：多个敏捷团队共同交付一个产品。
平台级规模化：一个平台，或一个解决方案交付多个产品，而每个产品又由多个团队共同协作交付。
2. 从组织维度，又有两个方向的规模化：
水平方向规模化
一个司空见惯的现象是，非产品研发相关的部门，比如人事、财务、行政、销售、采购等部门制定的流程和制度与敏捷思想相违背，阻碍了业务的敏捷性。不是说这些部门自己要应用敏捷的具体方法，导入Scrum框架等，而是说，敏捷和精益的思想是通用的，他们需要调整既有的流程和制度，以服务于业务为核心，而不是以部门的KPI为核心, 才能让企业更迅速的响应业务和市场的需求。
案例：
某世界500强企业的一个产品线需要采购工具软件Licence。但是，公司的采购部门规定：采购一套工具软件，需要经过CTO审批，而从一个项目经理从提交采购申请到经过CTO审批，一共经过7层部门领导，外加3层采购部领导，一共10个领导审批。此外，在项目经理的直接领导审批后，还需要在评审委员会上评审，而评审委员会每个月召开一次，如果没有通过审批，需要补充事实材料，再等待一个月再次上评审委员会。
所以，一般采购周期走完大概需要4-6个月的时间。这极大影响了产品线的交付效率。
如果在过去，产品线年初制定产品规划和预算，第二年交付产品，那么这样的采购周期还勉强可以忍受。但是现在世界已经不一样，由于市场的瞬息万变，很多类型产品的规划和交付周期都必须缩短，那么这样冗长的采购周期极大地拖累了产品的交付。
垂直方向规模化
随着敏捷的深入，企业组织结构的上层管理层如果仍旧用原有的体制、文化来管理整个企业，我们做的产品级、平台级、以及组织水平方向的规模化都会遇到极大的桎梏，每向前一步都异常艰难。因此，必须自下向上，每层组织结构都要转型，一直到企业的CEO。
Out-of-Box Thinking
组织级的规模化敏捷有多重要? Mike Cohn为组织重力与敏捷的关系做了这样的比喻，这个比喻适合任何组织变革：敏捷转型就像发射一枚火箭，让火箭飞上天的力量源自引擎，而地球的重力使火箭拉回地球。如果火箭能够飞得够远，可以进入轨道，脱离地球的重力作用。如果没有飞得够远，火箭不可避免会发射失败，摔到地球上。组织从垂直方向上以及水平方向都构成了敏捷的重力。 如果不从组织上规模化转型，不要说等到敏捷转型这个枚火箭进入轨道，哪怕在起飞的路上都会随时被组织重力牵引回来。
遗憾的是，业界应用范围比较广泛的规模化敏捷框架SAFe、Less、DAD、Spotify，总体而言，这些框架主要以面向产品交付的规模化，而组织维度的规模化尚不成熟。
如果你正在领导或推动组织转型，请不要陷在具体的框架里思考和工作。
