• Csp-train
  • A-csm-2019
  • Scrum@scale201904
  • Shine-scrum-02
  • Arne-201903
  • Jim-banner
  • Cal
  • Inner-training
  • Growth-process
  • Jens-heart-of-scrum
【新年特刊】洞悉规模化敏捷框架 Scrum@Scale 、LeSS 、SAFe (上篇)
原创: 孔兆祥  Jim Wang审校


引言


        本文以多个维度不同视角向你呈现Scrum@Scale 、LeSS 和SAFe三个规模化敏捷框架的共性和各自的特点。包括Scrum团队容器、沟通机制、沟通饱和度、适应性、系统思考、实施路线图、原则、角色、DevOps、Product Owner、实践者,11个维度可以分为三类受众。 Scrum团队容器、沟通机制、沟通饱和度是设计规模化敏捷框架的重要元素,这三个维度能为敏捷推动者设计框架提供参考。适应性、系统思考、实施路线图、原则四个维度企业决策者会比较关心。角色、DevOps、Product Owner、实践者属于框架的角色和认证的共性,对实施层面的朋友可能会有所帮助。

        本文作者孔兆祥,由Jim Wang审校,文章分为上中下三篇,本篇是《洞悉规模化敏捷框架》上篇。作者从自己的视角尽可能做到文章观点的中立和完整的剖析。

1、规模化敏捷框架
 1.1 Scrum@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.3  SAFe (Scaled Agile Framework) 


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

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

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

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

(图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.2  角色Roles

        Scrum@Scale和LeSS并没有新增角色,他们都是Scrum的角色,LeSS对Product Owner的能力要求提到了一个新的高度。SAFe在Scrum的角色基础上添加了一些新的角色,由于章节篇幅问题,不再一一展开。RTE(Release Train Engineer)是SAFe中一个重要的角色,主导SAFe的一个核心活动PI Planning。Scrum@Scale虽然没有加新的角色,但对原有Scrum Master角色职责有所扩展。

Scrum@Scale

LeSS

SAFe

扩展Scrum Master Scrum of Scrums MasterSoSM

扩展Product OwnerChief Product OwnerCPO

扩展Dev TeamAPOArea PO

TEAM层:Scrum  Kanban 团队

PROGRAM层:RTESystem ArchProduct Mgmt

SOLUTION层:SVSESolution ArchSolution Mgmt

PORTFOLIO层:Epic OwerEnterprise ArchPPM

2.2.1 Scrum@Scale Roles

        Scrum@Scale并且没有引入新角色,但对Scrum Master和Product Owner有了新的职能扩展,扩展后的每日站会叫Scale Daily Scrum (SDS)。SDS里关注和讨论的问题也有变化,不再是原来Scrum里的三个问题,SDS要处理更多的是团队之间的依赖问题,只有把团队尽可能的解藕才能提升整个组织的适应性,这种变化在几个框架中只有 Scrum@Scale把这项工作明确地固化在一个角色的每日工作当中。

( 图10: Scrum@Scale中SDS团队层面的每日站会结构)


扩展Scrum Master,Scrum of Scrums Master(SoSM):

•共享和清除障碍

•知识分享和标准化

•讨论和解决依赖

•SoS作为发布团队发挥作用

Scale Daily Sccrum(SDS)

同样是站会,但三个问题可能不一样

l   我的团队有什么阻碍令到我们无法完成Sprint目标的?

l   我的团队是否有影响到别的团队完成Sprint目标?

l   我们是否有发现新的依赖或者找到一种减少依赖的方法?


扩展Product Owner, Chief Product Owner, Chief Chief Product Owner

在MetaScrum里CPO是一个主导者,MetaScrum是一个负责产品级别的团队,Scrum对Product Owner的要求不低, Scrum@Scale的要求更高,CPO要负责引导MetaScrum产品级别的会议。

( 图11: Scrum@Scale中MetaScrum中的团队成员)


    至此,Scrum@Scale的组织结构与其相关的Role都已经清晰,也很好理解。组织结构的设计一个重要的元素就是Role, 框架都通过Role来稳定它的设计架构。就像盖房子和大楼需要有主力梁柱,Role就是这些关键的主力支点。我们用系统思考来分析一下,每个框架自身都有他要解决问题的目标,就像一个系统,Role就是它的杠杆点。如果一个系统的杠杆点越多,我们认为可以影响它的目标因素就越多,可以推理,这个系统的抗干扰能力越弱。这里也会让人引发一些思考,为什么SAFe会不断地加入新的东西?设计者的假设是什么? Scrum@Scale和LeSS 与SAFe是两种截然不同的设计风格和思维,LeSS角色设计原则是刚好满足框架的需要就够,不多也不少。


2.2.2 小结

        角色这个话题会有一个很大的反差,Scrum@Scale和LeSS与SAFe的理念完全的相反,SAFe中把有的都列出来了,基本上企业是能够对上号的,如架构师,发布经理等等,很容易让人联想到为什么SAFe是这么受市场欢迎。框架的设计也是考虑了市场化的因素在内,要知道导入SAFe的决策者也是利益分配者,失败对于导入者是不能接受的风险。角色引入容易,但要撤销就十分的困难,LeSS设计得这么轻和尽可能少的角色,目的就是让用户能快速导入,对于一些从Scrum团队发展起来的企业会比较适合进行扩展。那么是否意味着将要转型的企业选择LeSS和Scrum@Scale不适合呢?上述的上下文是企业收支平衡的状况下,倘若企业都要快倒闭了,那么决策的重点就不是在这里了,决策者更关注的还是在是否对现有的团队有重大的改变或者未知的风险。那么LeSS和Scrum@Scale的确相对于SAFe会有更大范围组织变革,它们更倡导的是用最短的时间过把组织结构调整过来,而不是一个渐变的过程,因为在渐变的过程中也要不断思考和调整,这样的过程也是一种浪费。以上两个问题都与精益思想吻合,延迟决策和消除浪费。

从推广的难度来分析,SAFe里有多种协调的角色,给客户的感觉比较重,垂直是协调层间价值流从企业顶层战略一直向下分解到达TEAM层交付,水平是协调层里各团队、交付速度和吞吐率。SAFe定义的角色让企业可以灵活地做裁剪,只要遵从框架的原则,达到同样的效果也SAFe了。SAFe框架是层级设计,为了解决层级间和层内的沟通框架必须要引入更多的角色,从框架设计角度上是一个加法,设计者允许用户对框架进行裁剪,即用户要为框架做减法(之前已经分析过了,人们在做减法的时候往往会更加困难),推广上相对是容易导入。

Scrum@Scale设计者在Scrum的基础上再一次突破,定义了EAT和EMS两个核心组织,以及Agile Practice和MetaScrum与两个核心组织的关系和协作方式,明确了管理层在整个敏捷组织架构中的位置和职责,是首个做到的规模化框架。LeSS角色比较简单,从框架的设计角度上是一个减法,如果企业原来组织结构扁平,那么导入Scrum@Scale或者LeSS都是比较容易的。当发展到一定规模的企业,涉及管理层的结构设计问题,Scrum@Scale就给予了这方面的支持。


2.3  系统思考(System Thinking

       系统思考是高管或者变革推动者必备的技能,能让他们从系统的高度来做决策和思考,也是一位优秀的规模化敏捷实践者必须学习的知识体系,至于系统思考为什么这么重要这里不展开,但三个框架都无一例外提及它。 Scrum@Scale和LeSS都推荐《第五项修炼》一书,SAFe把系统思考作为了它的第二条原则,但在SA(SAFe Agilist)的认证课上官方并没展开系统思考。SAFe的SA设计是给管理层的上的,相信多数管理层都不具有系统思考的能力或学习过系统思考,既然这么重要的一个原则,更应该展开说明。系统思考是LeSS的第四条原则,LeSS的CLP课程你会深深感受到框架设计的逻辑,因为它就是通过系统思考推导和设计出来的,CLP课程会让学员感受框架是怎么通过系统思考设计出来的,并且明白为什么系统思考在规模化敏捷组织中这么重要。LeSS 把系统思考作为它的核心,并应用于全局的设计中,有详细的建模指引。系统思考是解决延迟反馈问题的一种处理方式,LeSS官方网站对系统思考的说明是三个框架中最详细的。


小结:

     “只有管理者才能去改变系统”——Deming, W. Edwards。系统思考是SAFe的三个重要组成基础之一,要求管理者要具备教授和展示系统思考的能力。SAFe的SA认证课,官方教程中对系统思考的教授是比较少的。LeSS会把系统思考列入在教程中,系统思考是CLP应该要掌握的。完成两门课程的学习后,对两个框架理解的深度会有明显的差距。CLP会让你明白到框架设计背后的原理,而SA可能你只能记住PI Planning和RTE。掌握系统思考后,你可能会想知道为什么PI Planning一次要排4个迭代?背后有些什么因素驱使他这样设计?

        对比到这里我们应该要停一停,慢下来回答之前Team容器抛出来的问题,SAFe与LeSS的团队容器设计的选择不一样,导致了整个框架的设计都不一样,而团队的容器设计也正是为了尽量减少Backlog的份数。为什么框架的设计与Backlog的份数有关系?而产品边界的定义又与团队的划分有关系,团队划分就会产生Backlog,那么这又是如何去解决呢?这个正是LeSS的核心价值,也是这些CLP得到最大的收获,个中的杠杆原理请看吕毅老师最新的文章《待办列表的份数-终极杠杆》*,这里不展开。只可以说一句“系统之美”!

        SAFe的设计是多个Scrum团队之间的协作,引入RTE角色去引导协调沟通会议、对齐信息,这是一个合理的设计逻辑,为了解决多个团队间的沟通的问题,所以就设计了一个沟通会叫PI Planning。这样设计的好处在于之前Scrum团队的所有流程产品定义等都是以Scrum为单元,不用改变,当然默认也是团队以Scrum为单元,Scrum团队所应有的能力都要具备,只要在上层添加一个沟通的机制即可解决,但副作用就是降低了团队的适应性为代价。

        而LeSS是以适应性为最大化为目标的设计,它要打破小团队的Scrum(5-7人),变为大团队Scrum(50人),CLP要理解它这样的设计背后的原理,就要对组织的设计、产品的定义、组件团队与特性团队的协调机制等都要明白, 所以课程中你会强烈感受到两种截然不同的课堂体感。


2.4  沟通机制(Communication Mechanism

Scrum@Scale

LeSS

SAFe

No specific mechanism/Scrum Events/SDS

Product Backlog Refinement

PI Planning

        Scrum@Scale基本都是Scrum活动和SDS,没有具体的特色事件,要实践者去实践出企业最适合的方式和事件。这里听起来让人有点不适应,正常规模化框架都应该有一个沟通机制或者一个类似PI Planning这样的特色事件和工具去落地,这是我们正常的思维和心智模式,这里会带出一个问题,我们一直认为规模化敏捷就必然有一个沟通机制,那么这个论断的假设是什么?在Scrum@Scale的教程有一页让我当头棒喝。

“Add cross-team coordinating mechanisms ONLY in response to identified impediments to avoid wasteful bureaucracy”

增加跨团队协调机制只是为了应对已发现的障碍,以避免官僚主义造成浪费


    为什么要有沟通协作机制?团队不协作?或者不高效?或者这些就是我们所在的环境对你心智造成的影响,我们所处的环境可能或多或少存在官僚,所以我们的得出来的论断的假设是我们都存在于这样的环境中,然而我们自己并没有察觉,笔者在学习之前也是这样的心智模式,并没有跳出系统的视角。每个系统都有他的障碍,而沟通机制的存在是为了克服和清除这些障碍,这个机制会随着障碍的减少会不断地进化,所以只有组织自己才知道怎样的机制对它最适合,这个也是Scrum@Scale设计者对自组织的最大化设计。


        SAFe设计了PI Planning,最多150人,由RTE来引导,1次计划一个Scrum团队4个Sprint的Backlog,有多少个Scrum团队就有多少个Backlog和Product Owner。

        LeSS设计了Product Backlog Refinement ,最多50人,由Product Owner来引导,1次计划一个团队的Backlog,尽量少的Backlog为目标。 LeSS有一个特色实践,就是为了让团队提高适应性,在集体澄清需求时,可打散团队,提升广度学习能力。


小结

        这一部分是笔者最想去深入理解的,规模化框架的设计一定有它特定的机制去解决沟通的问题,清楚它们设计背后的设计逻辑和度量的指标才是价值所在。SAFe和LeSS两者的沟通会议是十分相似的,都是集体Review Backlog,而Scrum@Scale的这种沟通就分散在Meta Scrum的日常当中和SDS。两者的区别是一个集中,一个分散,分散的形式与Scale-Free的设计十分契合。

      因为SAFe中只是直接沿用Scrum或看板方法框架,所以实践都在其中了。而LeSS是通过实践总结出来的框架,SAFe的实践在Scrum团队的上层,而LeSS的实践是在Scrum的Develop Team中。所以他们两者表面上的不同之处就在于会议的频率、规模、形式等,但执行方式方法都是取决于他们的核心Backlog份数和Product Owner的数量。

    通过系统建模推导,SAFe为什么要设计4个Spring的Backlog和一个IP,与团队的人数数量、澄清需求的成本、PO的能力、PO的数量、特性团队的专业化程度等因素相关。分析结果回答了上面的问题,SAFe使用正向思维推理的设计方式,框架开始设计时就受局限,为了平衡一些副作用,必然要牺牲适应性来换取设计的不足。Scrum@Scale采用的是分散和涌现的沟通方式,这种机制和集中式的相比似乎更加灵活。


2.5  适应性(Adaptability)

     规模化敏捷框架在适应性方面,LeSS的设计已经是达到极致。通过一个案例,来说明一下敏捷框架适应性的设计,在某种场景下也有不适应的状况。中台系统*,在某种条件下,引入中台系统设计会给企业带来适应性的下降。

中台系统是互连网公司文化的产物,并不适合与它背后所承载的文化有冲突的企业导入。在激烈的市场竞争中,互联网公司为了生存,系统架构必须能够支持更短的产品研发周期、更快的产品迭代。企业的系统架构制约了自身的发展和创新的速度,为了更快的响应市场变化,产品要进行快速开发和试错。系统架构要适应企业的战略,一些共性的服务抽象出来由一个系统来提供服务,支持多个产品复用服务,从而减少重复开发带来的浪费。在这种上下文,中台系统是企业战略分解和经验积累下来的一个产物。但如果企业在一个产品都还没有做稳定的情况下,盲目追逐新概念,反而会降低企业的适应性,适得其反。

根据上面的分析,中台系统的出现必然会增加多一份属于中台的Backlog,并且企业组织还不具备高效的沟通机制,这时引入中台,就相当于增加了一个沟通壁垒。特性团队的任务要依赖中台系统,沟通成本增加,效率随之下降,适应性必然也会下降。

    另一种情况是,当适应性文化已经植入到企业每一位员工的骨髓后,就能打破架框的局限,做到极致的适应性。从系统思考的角度,我们都不能看清整个事物的全貌,而企业文化的基因也是我们在设计框架时所忽略的一个系统变量。国内大型互联网公司,能够做到一个产品2个月内不赚钱,团队可以全部解散,团队成员要适应新的岗位和技能。团队成员都知道只有产品成功才能生存下去,企业能做到如此高的适应性,瓶颈就在如何发现有价值的产品上。当企业已具有高适应性的文化,能驾驭任何框架。即使大型互联网公司没有使用任何规模化敏捷框架,企业同样可以能具备高适应性的特质,正是这个原因。

规模化敏捷框架能帮助企业提升外部和内部的适应性,外部对应市场,内部对应组织。中台系统是高适应性企业的系统架构产物,经过产品的包装,呈现在给人们的信息是,企业引入它就能够提升适应性。通过上述的案例分析,如果企业想通过建设中台系统提升自身的外部适应性,但又忽视了自身内部的适应性时,整体的适应性反而会下降。 

 规模化模敏捷框架设计,都是以提升企业和组织的适应性为设计原则。但我们这里想讨论一下框架本身的适应性能力。一个框架是否能成功帮助企业转型,它自身的健壮性和适应性也是有关系的。企业跟随市场的变化而变,通常企业的变化比较缓慢,假如我们选择的框架适应性越强,就越能适应企业的变化,企业在调整的过程产生的成本就越低。相反,是就成企业转型的障碍。


2.6  实施路线图(Roadmap

Scrum@Scale

LeSS

SAFe

No specific12 Dimensions

No specific6 Dimensions

Specific


Scrum@Scale虽然没有明确的Raodmap也是给出了一些建议,系统的反作用力是在所难免在,所以我们要先做容易提升的事,采用最快的方法把效率提高,争取更多的资源做更长远的改进工作,从而提高成功率。

•      Co-location


•      Small & Stable teams • Finish Early


•      T-shaped people


•      Swarming


•      Scrumming the Scrum • Interrupt buffer


•      Daily Clean



Scrum@Scale没有给出具体方案,同样需要Practitioner运用你的智慧找到组织最适合的方案。没有明确的Roadmap,因为每一个组织都不一样,可以通过以下的维度对自己的组织进行诊断,方式有两种,可以像下图用POST-IT和用维度表。


•     Executive Meta Scrum


•     Executive Action Team


•     Team-Level Process


•     Cross-Team Coordination


•     Continuous Improvement & Impediment removal


•     Strategic Vision


•     Backlog Prioritization


•     Backlog Decomposition & Refinement


•     Release Planning


•     Deployment


•     Product & Release Feedback


•     Metrics & Transparency


( 图14:POST-IT不同维度展示企业现状 )


( 图15:维度表展示企业现状 )

SAFe

SAFe有很清晰的Roadmap,由SPC来主导,照着走就可以。


( 图16:SAFe的实施路线图 )


LeSS

LeSS和Scrum@Scale是同样的思路,只是形式不一样,在导入前大概需要1个月的前期准备,没有Raodmap,看CLP的经验和实际情况来做方案,确保首次启航成功。坚持了他一向简约的风格,也是抽象了6点。

1.          educate everyone


2.          define ‘product’


3.          define ‘done’


4.          have appropriately-structured teams


5.          only the Product Owner gives work to the teams


6.          keep project managers away from the teams



小结

        我们默认企业导入规模化敏捷框的目的都是为了提升企业的适应性!这点十分重要,如果这个不成立,那么导引就没必要性了。即企业的Tipping point十分重要,要是你都没有痛点,那么导入行为可能是一种政绩或其它原因。规模化敏捷框架在导入前都要作充分准备,如工程实践,CI/CD的基础能力,各种角色的设计培训,最大的还是组织变革。

        为什么SAFe总是感觉比较重呢?我思考了一下,很可能是因为他设计了太多的角色的原因,整个组织(即系统)要有序的行动起来,它要需要克服和解决的问题是人的问题,引入的人和角色越多,系统就越复杂,需要调整的范围更广,解决和分析的能力要求也就更高。SPC的引入是必须的,企业的转型怎么也要2年左右才会有成效,因为开始实践时只是在TEAM层,财务预算层还是以年来计算的,所以起码要到第2个财年才会有成效可见。

        LeSS的组织变革更倾向一次进行大刀阔斧,目的也是很明确,宁愿开始时把最花精力的事完成,之后成功的几率会大很多,使用越少的改变得到最大的杠杆效果。

       Scrum@Scale给出的建议是先从两个Scrum团队开始做生态,之后就是自系统自行繁衍,EAT和EMS保证系统的环境,就像一个Scrum。

        这会让人想起一个情景,你只要给管理者计划和Paper,他们就会对项目有信心,相信项目就会按既定目标完成,一天拿不到计划似乎若有所失。从Roadmap的设计上看,SAFe对市场极具亲和力。


未完待续,下篇更精彩



版权所有,欢迎转发分享。转载请联系ShineScrum捷行。

点击微信版阅读