引言
本文作者孔兆祥，由Jim Wang审校，文章分为上中下三篇，本篇是《洞悉规模化敏捷框架》上篇。作者从自己的视角尽可能做到文章观点的中立和完整的剖析。
Scrum@Scale由Jeff Sutherland设计，也是Scrum框架的发明者。从框架的组件透视图看到，Scrum@Scale框架由一个Scrum Master Cycle和一个Product Owner Cycle的工作闭环流程组成，中间有Executive Action Team(EAT)和Executive Meta Scrum(EMS)两个组织，这两个组织是整个框架的核心。 框架看上去都很容易理解，那么它有什么独特之处呢？究竟它与其它框架有什么不一样？它背后的设计逻辑是怎样的？它的沟通机制是怎样的？
1.3 SAFe (Scaled Agile Framework)
2.1 Scrum团队容器(Scrum Team Container)
在计算机领域对容器的解释是，容器是用来存储和组织其他对象的对象。 那么在规模化敏捷框架上下文中，Scrum团队容器(以下简称团队容器)是指在框架中用来容纳敏捷团队的一个对象，在规模化敏捷框架并没有清晰地定义出这个概念，但笔者认为它是存在的，它很显式地体现在框架的组织设计当中，在框架设计时是抽象的，在实践以组织架构形式实例化。所以可以这么认为，团队容器就是一个企业的组织架构。规模化敏捷的组织架构设计与传统组织有很大的区别，企业要扩大敏捷的范围，自然会涉及更大范围的的组织变革，所以每一个规模化框都会有组织变革措施，但企业组织变革往往是规模化敏捷最大的障碍，因为企业的组织架构就是它的中枢神经。组织变革的过程就像科幻片里的情节，人类研发并植入外星的基因，想创造出新的物种，目的都只有一个，就是为了更好地活下去。同样，在企业规模化敏捷上下文中，我们可以把企业组织看作一个系统，敏捷就是一种新型基因，当我们尝试植入这种基因时，组织自有的免疫系统开始可能会产生抵触，极端情况甚至是会产生抗体消灭新来基因，如果适应下来后，双方会很好地融合形成新的物种。
清楚团队容器的设计逻辑能更好地帮助你在实践时设计出适合组织的价值生产单元，采用不同的设计逻辑会直接影响组织的沟通机制和沟通饱和度，这两个是组织设计的重要指标。组织设计是一门科学和艺术，如果可以掌握就可以设计自己的组织结构，提高组织适应性。倘若我们并不想去设计组织或者还不具备这种能力，那么了解现有框架设计者的逻辑也会有所帮助。所以笔者认为团队容器是一个十分重要的概念，无论你是规模化敏捷实践者或管理者都需要去了解。
注：
*本文默认读者已经对Scrum有一定的知识基础，所以不会对Scrum做额外的知识普及。
2.1.1 Scrum@Scale Team Container
Scrum@Scale的团队容器设计十分特别，也是它的核心，所以这节会以较大篇幅去分析。从下图可以看到，Scrum@Scale组织结构里Team的最小单元是一个Scrum团队，一个Scrum of Scrum(下称SoS)的最结构是小于等于5个Scrum团队，再上一层的SoSoS也是同样的规则，可以有多层的SoSoSoS…..,所以Scrum@Scale的这种网状组织结构是可以支持无限大团队。至于为什么它设计的单元是5呢？背后的设计逻辑稍后会再作分析。
Scrum@Scale这种组织结构让人感觉和LeSS与SAFe都很不一样，后两者对于团队容器都有一个很清晰的容量限制，SAFe有ART的限制，LeSS也有Team的人数限制，后两者要突破限制就要添加新的Role和规则来平衡沟通的效率，本文的沟通饱和度一节会对这种设计进行详细分析。
Scrum@Scale框架是Scale-Free network的仿生设计，这种设计能更适应更快速的组织发展和功能开发响应，理论是基于无尺度网络模型，这种网络在实现中普遍的存在，如神经网络、社交网络、航空网络等。
The Executive Action Team(EAT)组织内只有一个，有些组织可能叫精益/战略转型等类似的名称
• 对组织中Scrum的质量负责；
• 拥有组织转型战略；
• 拥有转型代办清单和清除阻碍转型的所有障碍；
• 消除由于范围，预算或公司政治权力而未在团队级别处理的障碍；
• 执行转型战略或将其委托给专业部门(通常称为敏捷实践)；
• 测量并提高组织中Scrum的质量，以构建业务敏捷性的能力；
• 敏捷践行小组(Agile Practice)，十分重要，它是企业内推行敏捷的组织，Scrum Master会向这个小组汇报。Agile Practice成员也是EAT成员，负责推动敏捷实践，这样自上而下的推动，才能保证敏捷不只是以形式留存于基层。
MetaScrum
这个组织要说明一下，是所有PO和利益相关者的容器，从SoS的Team层开始他就有，直到企业执行官层(EMS)都存在，这个组织在不同层次有不同的企业成员，重要的一点他们也是一个Scrum团队，职责如下：
Executive MetaScrum(EMS)
管理层成员(CPO、 CEO、CFO、CCPO)拥有组织愿景、识别价值流、设定组织优先级CCPO MetaScrum
设置多个团队组(可以理解为所有的产品线)的优先级，产品澄清、识别价值流、跨团队协调。CPO MetaScrum
设置多个团队的优先级、故事拆分、跨团队代办清单协调、对齐
2.1.2 LeSS Team Container
LeSS的团队容器十分特别，是由1个Product Owner、多个Scrum Master和Scrum Team组成，设计是通过系统思考的方式推理和优化出来的。LeSS只扩展Dev Team，整个组织的上限是50人(再大就会是LeSS Huge，本文不会展开)。LeSS建议Scrum Master全职同时支持两个团队，这样可以得到不同团队的视角，更好地提高团队的适应性。当然，如果Scrum Master的能力足够，可以支持更多的Scrum Team。
另外，LeSS很强调产品的定义，组织的设计是为了更好的支持产品的迭代和适应性。而产品的定义又涉及投资组合、DoD(完成的定义)等因素，所以清晰的产品定义是团队容器的基础。
Team Design vs. Coaching，可以看到花成本去设计好组织结构比教练团队，得到的回报会更高。
2.1.3 SAFe Team Container
SAFe的团队容器在框架的TEAM层，容器里有多个Scrum团队和看板团队。SAFe的TEAM层会有多个Product Owner和Scrum Master，并没有强调和限制使用特定哪一种形式的团队，水平扩展多个多功能团队，直到到达上限150人(包括所有人)。SAFe以层级的设计思路，层间的沟通问题通过引入新的角色去解决。团队容器抽象为一列敏捷发布火车(Agile Release Train)ART，在框架的PROGRAM层，用火车来比喻十分形象，一列火车承载着所有团队成员和要交付的产品价值，这也是SAFe中最大的特色。SAFe在各层之间还有一个系统团队(System Team)，它是一个共享的资源团队，如类似架构团队和设计团队等，在同层是用火车来承载，跨层是用System Team来承载。
2.1.4 小结：
通过对比我们可以看到三个框架的组织结构设计都有它的思路，Scrum@Scale以仿生Scale-Free架构设计理论依据，支持可无限扩展的组织。LeSS在小范围内达到极致，到达一定极限后扩展成Huge。SAFe在到达一定上限时扩展多个ART和RTE。三者都以Scrum作为团队基础单元，LeSS的结构更像是Scrum@Scale的其中一种实现。
每个组织都有它自运转的生态和惯性，这个生态我们称它为系统，它的惯性我们称它为心智模式。系统的组织结构是它运作的核心，是管理者十分关注的一个维度。系统有它的心智模式，当我们要对系统进行变革的时候，它自然会产生抗体，所以变革的阻力就在于系统的惯性，然而我们实践者往往要做的是这个核心的变革工作。
组织结构的设计逻辑直接影响实践者实施的难度，那么我们该如何选择框架为企业赋予敏捷的属性？作为一名敏捷教练如果理解了框架背后的逻辑和设计原理，那么我们就能更加容易做出正确的决策，在实施组织变革时的成功机会也会增加。
Scrum@Scale认为如果一个系统没有自生态的机制，那么当它发展到一定体积后就会慢下来，对于组织管理和设计者来说，也是有必要考虑的因素。LeSS发展到一定体积后要切换到Huge模式，SAFe的ART到达150人后也需要更多的RTE建立沟通机制，这种进化也必然要引入新的资源配套，倘若系统天然就支持和具备快速进化发展的机制和基因，就能减少系统在决策和申请资源时的消耗，Scrum@Scale以Scale-Free的架构设计就具有这种天然的基困。
版权所有，欢迎转发分享。转载请联系ShineScrum捷行。
