详解规模化敏捷框架 Scrum@Scale 、LeSS 、SAFe

1、规模化敏捷框架

1.1Scrum@Scale

 

(图1：Scrum@Scale框架的组件透视图)

 Scrum@Scale由Jeff Sutherland设计，也是Scrum框架的发明者。从框架的组件透视图看到，Scrum@Scale框架由一个Scrum Master Cycle和一个Product Owner Cycle的工作闭环流程组成，中间有Executive Action Team(EAT)和Executive Meta Scrum(EMS)两个组织，这两个组织是整个框架的核心。 框架看上去都很容易理解，那么它有什么独特之处呢？究竟它与其它框架有什么不一样？它背后的设计逻辑是怎样的？它的沟通机制是怎样的？

1.2 LeSS (Large Scale Scrum)

 

(图2：LeSS框架的组件透视图)

LeSS由Craig Larman和Bas Vodde共同设计，框架基于Scrum进行扩展，通过大大量的实践经验，糅合精益思想沉淀而成，支持企业以敏捷的方式进行大型产品研发，是一个轻量级的规模化敏捷框架。

1.3SAFe (Scaled Agile Framework)

 

(图3：SAFe框架的组件透视图)

SAFe的设计和主要方法论由Dean Leffingwell主导，是另一个流行的规模化敏捷框架，特点是将敏捷实践在企业中分层而治，从团队级(Team level)到项目群级(Program level)乃至投资组合级(Portfolio leve)，糅合精益-敏捷知识体系。

2、规模化敏捷框架的11个维度分析

2.1Scrum团队容器(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和规则来平衡沟通的效率，本文的沟通饱和度一节会对这种设计进行详细分析。

 

(图4：Scrum@Scale的组织设计进化透视图)

 

(图5：Scrum@Scale会有不同的组织结构实现形式)

Scrum@Scale框架是Scale-Free network的仿生设计，这种设计能更适应更快速的组织发展和功能开发响应，理论是基于无尺度网络模型，这种网络在实现中普遍的存在，如神经网络、社交网络、航空网络等。

 

(图6：Scrum@Scale以Scale-Free network设计的实现)

The Executive Action Team(EAT)组织内只有一个，有些组织可能叫精益/战略转型等类似的名称

•     对组织中Scrum的质量负责；

•     拥有组织转型战略；

•     拥有转型代办清单和清除阻碍转型的所有障碍；

•     消除由于范围，预算或公司政治权力而未在团队级别处理的障碍；

•     执行转型战略或将其委托给专业部门(通常称为敏捷实践)；

•     测量并提高组织中Scrum的质量，以构建业务敏捷性的能力；

•     敏捷践行小组(Agile Practice)，十分重要，它是企业内推行敏捷的组织，Scrum Master会向这个小组汇报。Agile Practice成员也是EAT成员，负责推动敏捷实践，这样自上而下的推动，才能保证敏捷不只是以形式留存于基层。

 

(图7：Scrum@Scale的Meta Scrum几种组织形式)

MetaScrum

这个组织要说明一下，是所有PO和利益相关者的容器，从SoS的Team层开始他就有，直到企业执行官层(EMS)都存在，这个组织在不同层次有不同的企业成员，重要的一点他们也是一个Scrum团队，职责如下：

Executive MetaScrum(EMS)

管理层成员(CPO、 CEO、CFO、CCPO)拥有组织愿景、识别价值流、设定组织优先级

CCPO MetaScrum

设置多个团队组(可以理解为所有的产品线)的优先级，产品澄清、识别价值流、跨团队协调。

CPO MetaScrum

设置多个团队的优先级、故事拆分、跨团队代办清单协调、对齐

2.1.2 LeSS Team Container

 

(图8：LeSS的团队容器)

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，可以看到花成本去设计好组织结构比教练团队，得到的回报会更高。

 

( 图9：Team Design比Coaching Team更重要)

2.1.3 SAFe Team Container

 

( 图10：SAFe在TEAM层的团队结构)

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的架构设计就具有这种天然的基困。

2.7实践者（Practitioner）

 

认证并不是笔者的目的，但这里也简单介绍一下。Scrum@Scale的Practitioner认证(SaSP)只要参加认证课程，通过考试就可以获取认证。Scrum@Scale Trainer（SaST）要先取得SaSP，然后要有培训经验和一个Scrum@Scale 案例，再参加5天的课程，并Show Case，通过评审之后就可以成为SaST。对于实践者来说Scrum@Scale是一个完美的框架，如果有很好的Scrum实践，Scrum@Scale会有很多可能性。作为一个SaSP，不单要掌握Scrum，更多的还要去动推动EAT和EMS。

LeSS的实践者是CLP，CLP并不需要正式的考试，只要上完课就能取得认证。课程中你能清楚理解到LeSS框架设计的原则，所以个人觉得考试与否并不重要。再高一层次是CLB和CLT，CLT的认证条件是十分严格，讲师要有真实的LeSS案例。LeSS的CLP更多的要去引导Product Refinement，使用系统思考去提高组织的适应性。

SAFe的实践者是SA，SAFe里的几个关键角色RTE、SPC等都要通过认证考试，考试过程会让你更加理解SAFe框架。SA再高一层是SPC，SPC要关注整个框架的运作，关注价值流和ART。

三个框架认证之后，笔者有如下感受。Scrum@Scale认证后，感觉LeSS就是它的一种实现形式，框架的设计接近完美。LeSS认证后，你会明白他设计的原理和了解到系统思考。SAFe认证之后，个人需要更完整的知识体系才能理解框架。对于实践者来说Scrum@Scale和LeSS是相对容易接受，而SAFe是管理者相对容易接受，观点与角度不一样。

2.8DevOps

 

DevOps在企业级敏捷中已经是一个不可或缺的基础能力，企业能够做到功能按需发布、快速获取用户反馈、持续改进。DevOps从SAFe 4.5版本正式加入，并且有它自己的一个DevOps认证SDP。而LeSS和Scrum@Scale并没在框架中提及，DevOps应该是由Team去肩负起来，这种原则和思维方式已经融入到框架之中，所以在框架中并没有明确声明。

2.9Product Owner

 

Product Owner在每一个框架中都是关键人物。SAFe中有它领域内的认证POPM。LeSS与Scrum@Scale并有没额外的PO认证，但后者对PO的能力要求并不低于前者。LeSS一个PO要支持50人的团队，大概7个Scrum团队，对PO的能力要求极高。在CLP的课程中会有一个篇幅去讲产品的定义，笔者清楚记得当时问了讲师一个问题。为什么要讲产品的定义？这个系统变量也是通过系统思考推导出来的，因为PO对产品定义不清晰，会影响整个团队的目标实现。

Scrum@Scale的Meta Scrum里PO更是需要有导引能力，并且与SM互补和有交集，扩展了PO的职责，识别价值流，引导会议等。通常我们衡量一位PO的指标都是直接与他负责的产品挂勾，相信每一个人都有追求卓越的心，但我们往往忽视了PO们所处系统的环境，环境影响了心智模式。我们是否为PO提供了可持续发展的空间和环境。

2.10沟通饱和度(Communication Saturation)

 

上表列出三个框架各自有特色的设计和活动，它们之间似乎都没有很大的关系。但笔者发现它们背后要平衡的是一个指标，就是沟通饱和度。如果我们从沟通饱和度的维度来看这些设计，就会发现这些设计和活动之前的关系。沟通是团队协作过程中最大的成本之一。Scrum设计之初，Jeff在他的书中（《敏捷革命》/《The Art of Doing Twice the Work in Half the Time》）第三章团队规模一节，就提及设计Scrum团队人数时考虑的就是这个指标。另外，在学习Scrum@Scale的Slide Deck时候也发现这个线索暗中贯穿整个框架。

 

 

( 图11：沟通饱和角色数量关系图)

 

( 图12：Jeff Sutherland的一条推文）

 

( 图13：Software Engineering Institute的论文)

三个框架都以不同的形式去找到团队沟通饱和度的平衡点，如果我们明白框架背后的逻辑那么我们就可以去设计我们自己的机制，团队沟通饱和度越高那么团队共享的知识就越多，需求就越明确。但要达到这种状态是需要成本的，工作时间不可能全部用于沟通，即我们的沟通饱和度不可能达到100%。假若我们想要沟通饱和度达到50%，那么这个机制的形式可能会有几种方式，要么一次达到50%，如开一个集体澄清会议（PI Planning）；或者我们加大沟通的频率，但每次沟通的时间变短；或者我们使用不同的频率和节奏；都能达到同样的沟通饱和度。

SAFe的PI Planning属于大型的沟通，所以频率不能高。LeSS的Backlog Refinement相对人员较少并且只设置1个PO，可以以迭代频率进行。S@S以5个为一组的SoS，多层SoS的Scale Daily Scrum，可以每天都进行同步。下图的例子是2000人的组织能在1.25小时内完成同步沟通。以上事件都是为了提升沟通饱和度的，但框架的组织结构设计不同就有不同效率的区别，和不同的沟通表现形式。

 

 

( 图14：SAAB的案例)

2.11原则（Principles）

Scrum@Scale就是Scrum，它的原则就是Scrum的原则。

 

 

( 图15：三个框架的原则示意图)

 

 

框架的原则让人思考到敏捷原则，通常都有一种共识，做事不拘于形式，只要我们按原则做事件，就能标签敏捷和框架。框架的原则也是笔者想去推敲的事情，由于篇幅问题，我们只可以在这里简单思考一下。如果把框架看作一个有机的生态系统，那么这些原则也是就是它的变量。规模化敏捷框架重要的一个目标是提升组织的适应性，这个观点我相信是正确和成立的。那么这些变量是如何杠杆框架的目标的呢？给大家一个思考的空间。

3. 结束语

所有的框架课程都是设计给Management去参加的，规模化敏捷是否成功取决于决策者的决心和智慧，框架对管理者的能力要求非常高，甚至连管理者都没有意识到，自身将要面对的改变幅度之大、范围之广，所面临的障碍是如此巨大。管理者要有所觉察，改变的不单是企业，更多的是自身。需要管理者有紧迫感、使命感、领导力、勇气和决心。至于每一个企业的决策因素都是复杂的，对于决策者们无论选择哪一个框架都是基于成功率最大的基础之上，因为失败的风险对管理者来说是不能接受的事实。

框架设计者的背景，他们所追随和认同的科学理论，直接影响着框架的设计风格特点。本文通过从不同维度来呈现规模化敏捷框架的设计逻辑，从中试着抽象和提炼出共性，希望能为企业在框架选型时提供多一份的参考。敏捷有不同的派系和理论的信奉，业界存在多样性是创新的源动力。本文可能未能做到观点的中立和完整的剖析，也必须承认笔者的视角并不完整。因此，希望能在尊重和理解的前提下，通过交流和探索互相刷新心智模式，并希望本文对正在学习或将要学习规模化敏捷框架的你有所帮助。（文章来源：ShineScrum捷行）