最近社区讨论规模化敏捷的话题不少，甚至会在几个大规模敏捷框架Scaled Agile Framework®（SAFe®），大规模Scrum（LeSS）和规范化敏捷交付（DAD），Scrum@Scale，Nexus 的选择中纠结和争论。
这里我们一起探索规模化敏捷的核心是什么，如何在实践中指导我们探索出最适合自己组织的规模化敏捷的框架。
首先我们定义什么是规模化敏捷？本文我们讨论的是两个以上的Scrum团队在遵循敏捷价值观和原则下围绕一个整体产品( a whole product)或服务如何快速交付价值给最终客户。规模化敏捷是敏捷方法超越团队级别，基于一个产品或者产品投资组合级别上的扩展。这里的前提是一个Scrum团队是组织敏捷和进化的有机生命单元。我们以产品的视角来讨论，避免用项目一词，项目是交付产品的一种组织资源的临时形式，产品的生命周期要远远大于项目。
敏捷（agile）的广义定义：组织响应市场和客户变化的敏捷度和灵活性。我更喜欢用adaptive来诠释敏捷。Scrum是一个最精益（lean and barely sufficient) 的团队工作的框架。大写的Agile代表敏捷宣言。
我们一起看看多团队会给我们带来什么问题？首先，想到加人会带来的复杂性，人是复杂的有思想和价值观的个体。加人带来的复杂性包括：角色，流程，结构，信息的流动即沟通成本, 比如沟通的管道和使用物件（Artifact）的增加等等。
所以，规模化敏捷的首要原则：First rule of scaling agile - DON'T do it
规模化敏捷的本质是减少复杂性or 瘦身（De-scaling）, 增加角色和岗位，组织架构的层级，重的流程， 都会阻碍我们价值交付的速率。通过局部优化解决局部(local)问题的方案，通常会成为组织（global）问题的根本原因。规模化敏捷不是增加复杂性。
“Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” – Dee Hock, CEO Emeritus VISA International
对于复杂的大型产品（比如电信，保险，银行等行业），如果我们确实需要通过增加人，但要考虑团队有机的增长。而不是一味简单的做加法。
规模化敏捷带来的第二个挑战是，依赖问题。依赖有多种： 多个产品之间的依赖，产品外部和内部的依赖，团队的依赖，包括能力的依赖。文章稍后我们讨论如何减少依赖。
因此， 我们在引入和定制规模化敏捷的方法时，要时刻记住我们的目的什么？如何减少复杂性，如何避免依赖关系，而不是简单的照抄和copy model, one size can NOT fit all. 同时要不断通过检视(inspect)和调整(adapt), 采取回顾持改进的方法， 探索出最适合自己组织的规模化敏捷的框架，也不要简单的copy其它同事和部门的最佳实践。最佳实践是非常危险的。
规模化敏捷的目标是清晰的： 用尽可能最好的方式巩固多个Scrum团队的成果(outcome)来扩大过程迭代（Iteration）和产品增量(Increment) 交付的规模。
这意味着我们至少需要建立一个基本的跨越多个团队的流程框架，并且持续不断的迭代改进。这个规模化的框架应满足和遵从：
i. 简洁(Simplicity)的原则，不能增加复杂性，对待复杂问题不能依靠复杂的套路来解决，增加角色，流程，结构，层级，物件都会使问题更加复杂化，要遵从Scrum的框架。（Scrum is a basis）
ii. 需要我们组织的身体力行，进化出最适合的多团队以上的组织设计架构；最大化聚集多个团队一起工作的价值流；没有现成的菜单可以照抄。(Learn by doing)
iii. 多个敏捷团队的能量，热情，士气, 幸福感(happiness) 依然像单个Scrum 团队一样得到最大释放，而不是被压制；（Morale is a multiplier for velocity, by Joe Justice）
iv. 管理层和领导力的重新定义和定位，敏捷文化驱动组织最大化价值的产生。（agile leadership and culture）
规模化敏捷宣言(Agile Scaling Manifesto)：
1. 切断依赖优先于管理依赖 （cut dependency over dependency management）
2. 减少复杂性优先于规模化敏捷的框架 (reduce complexity over scaling framework)
3. 拓展能力优先于团队协作 (build competence over coordination )
4. 做好Scrum 优先于规模化 (do better Scrum over Scaling)
规模化敏捷产品开发， 有内部依赖和外部依赖。外部依赖则在产品以外，比如硬件组件或依赖其它产品。内部依赖，在产品内的非特性团队， 比如组件团队（undone work）或集成团队。 对于产品内部的依赖，PO需要考虑如何拆分产品功能复杂性降低。特性团队的设计会消除依赖，对于共享代码的团队，其实不需要管理内部依赖（LeSS 有详细的阐述）。循环型依赖（Circular Dependency） 50%的时间会耗费在沟通上。作为产品负责人始终关注依赖关系，尽早识别依赖关系，与所有人合作寻求帮助移除依赖。
一个坏消息是，“管理依赖”的文化将会阻碍基本解决方案的实施。 最小化依赖关系的最佳方法是切除(cut)依赖关系，即没有依赖关系。通过以下方法我们彻底消除依赖： 培训和拓展技能； 复杂的架构简单化；减少组件的数目；组织设计并组建跨组件和跨职能的Scrum团队（Less 定义特性团队）。
作者建议，组织在规模化敏捷的实践中要遵循的三个基本原则：
第一条原则：
自治团队单元是组织进化的硬核 -- 培育小而稳定的践行Scrum的团队
“small, autonomous, cross-functional teams work best vs component team”
组织不是通过简单扩大规模来处理大的复杂的问题，而是将复杂的问题分解成一个个小的部分，由小的团队来处理。特别对于大规模复杂关键的产品，自组织团队和团队单元（Team based organization）的建立和辅导很重要。
任何一个团队必须历经塔克曼（Tuckman model）团队发展阶段模型的四个阶段：形成期、震荡期、规范期、成熟期。团队进入高绩效的状态，需要花费6-12月的时间和相当大的努力。我们传统的做法是：项目结束，把老团队拆散，新项目开始我们再重新组建新的团队。我们把人当作资源，可以替换也可以随时plug-in。 却忽略了人是有学习能力的，每个个体是一个复杂的自适应系统，有自己的价值观和理想。个体之间需要化时间与集成和融合， 成为真正的团队。
因此，我们需要把钱花在组建一支稳定的团队上，他们是专注于某个产品的一个稳定单元，而不是项目完成之后解散团队。我们要创建跨职能团队，团队成员来自不同的职能部门：包括业务分析师、设计师、开发人员、测试人员。核心团队成员都是全职的（至少80%或者更多时间）投入到产品中。工作应该尽可能由小型的、自主的、跨职能的团队在短周期内完成相对较小的最高价值工作，并从最终用户那里获得即使持续的反馈。LeSS 中明确定义了特性(feature)团队，特性团队扩展地图。
帮助成就自组织敏捷团队的这个管理框架就是Scrum，也是企业导入敏捷思想，团队落地敏捷的简单游戏规则. Scrum框架“进化价值交付”的两个关键特征：
(1) 增量产品交付(Incremental Product Delivery)：以一种被叫做迭代 (Sprint)的小块的形式将产品交付到市场；
(2) 过程迭代(Process Iteration)：很短时间盒内以小颗粒度的工作级别执行整个软件生命周期中的计划，设计，开发，测试，发布这些流程，重复。
担当这个框架的管理者和引导者的关键角色就是ScrumMaster。Scrum 定义了一套简单的游戏规则 （有点像 chess game），一旦一个组织内团队在一段时间内不懈地追求和实践Scrum，拥抱敏捷思维，就会对组织产生潜移默化的影响：组织做计划的方式，人们工作的方式（比如做决定和解决冲突），领导力的方式，从本质上改变了原来的游戏规则。一个高效自治 （self-governing） 组织单元在渐进形成。从组织的角度来看，工作单元变成了团队，而不再是个人。通过在短周期内工作，团队很容易调整方向。
我们认为：稳定的小团队构成了规模化敏捷组织交付价值给客户的基本单元（basic building block）。这样的团队具备精益创业型（Lean+ Entrepreneurship）的特质。以Scrum values 作为core的工作文化，，一个充满激情，学习型的，有机的，自适应生命体。ScrumMaster 正是打造这个产品（视团队为产品）的敏捷教练。敏捷管理者充分激发知识型员工的才干和能力，把自己看作赋能者（enabler）而非控制者，并身体力行。
Scrum刚开始就非常关注团队的设计和结构变化，Scrum的结构往往会迅速影响组织的文化。没有建立和打造这样的团队作为基石，规模化敏捷都是空中楼阁。
第二条原则：
以精益思想(Lean Thinking)为基石的实践
“Keep your organization as small as possible and focus on eating the elephant piece by piece. And only eat the really delicious parts of it.”
当下面临的这个时代，我们再也不能以组织内部的规定和流程限制为借口，去搪塞和操纵客户。客户是我们的boss, 企业的每个个体都应该审视他们所做的每一份工作是否真正给客户带来价值，时刻铭记减少不增值(non-value added)的活动。
我更喜欢尝试用精益思想五个核心原则，来一起探索规模化敏捷:
1.以产品来定义价值（identify value）。 客户价值是至高无上的。以聚焦于给客户和用户带来附加增值和创新为组织的目标，而非以短期盈利为目标。LeSS 中对产品定义有专门的解释。
2.为每个产品识别价值流 （map value stream）。寻求从最初构想到产品交付的端到端的完整步骤，以交付客户价值，同时要识别不同价值流之间的依赖。
3.确保价值的流动不被打断(create flow)。 通过识别问题来改进我们的流程；减少或消除阻碍价值流动的瓶颈，去除浪费。
4．客户从交付团队拉取价值(establish pull system).。靠保持最小数量的库存来进一步减小浪费和提高生产力，优化团队的工作方式。
5. 追求完美 (seek perfection)。团队和管理者坚持不懈的寻求改进.
我们如果从精益思想的原则出发，尝试探索一个组织内部的规模化敏捷的基本框架，比如价值流的管理，如何让价值能快速流动起来，并生成关键实践。几个实例：
用户故事流的方式。一个核心理念就是连续流（flow）。在精益组织里，通过单件流或连续流的方式，将全面（holistic） 正确的产品，端到端的无中断地，快速交付客户。这样启发我们：敏捷团队在定义，开发，整合和部署产品时，通过将产品分解为功能特性或用户故事流的方式。一个功能特性 (feature)或者更细粒度的“用户故事”代表着“单件”的商业价值，需要从客户端以最快的速度无中断的通过开发，测试和部署流程回流到客户端。(end to end).
以产品的探索（product visioning or discovery）为例, 要经过产品愿景，用户画像，产品路线图，史诗级的用户故事Epic到 迭代级的story （sprint-able），商业画布验证商业模式，设计实验或MVP 验证具体的想法，精益创业(lean start-up)的理念，用户故事地图，影响地图等工具会帮助我们做产品的探索，然后采用Scrum 的框架帮助我们做产品交付(delivery), 这些技能我们都会在CSPO课上讨论和操作，这里不在累述。
那么，组织如何去管理多个产品呢？ 我们定义了投资组合（Portfolio） backlog, 这个backlog的条目可能是不同的产品，或者是产品增量（比如一个发布），或者项目（有些组织习惯用项目来规划工作）。注意到，在敏捷的语境下，我们用产品来替代项目，敏捷中我们很少提及项目集（program）的概念。 但有产品Portfolio的概念。参看下图：
任何一个组织的资源和容量(capacity)都是一对矛盾体，组织需要建立Portfolio planning/management的策略。 比如新的产品满足什么条件能够拉入Portfolio backlog，产品优先级的排序考虑的要要素。
遗憾的是，一些组织在产品的Portfolio backlog的管理方面没有明确的原则和策略。 Ken Rubin的《Scrum 精髓》有专门的章节论述他建议的11条策略管理Portfolio backlog。
接下来我们聚集到一个点，讨论如何通过限制在制品（WIP）数量来加速价值的流动。
“Develop and deliver in small batches. Focus on finding the true MVP by relentless customer research”
当一个共享的稀有资源的利用率越高，生产速度就越慢。排队理论中的Little法则：
生产周期 = 在制品数量WIP/平均完成速率
因此，要想让产品交付的更快，减少在制品数量（也就是进行中的条目），或增加完成的速度。加快速度是一件相当困难的事情。所以，要缩短生产周期，有效做法是减少在制品的数量。
我们在规模化敏捷的实践中要考虑如何应用这一原则，即让团队聚焦在更少的在制品上，
这一思想可以从产品投资组合（Portfolio）的规划到每天的工作任务中。按四个维度来讨论：
(1) 限制在制品（WIP）数量的在产品Portfolio Backlog层面的应用：
终止僵尸项目。僵尸项目指的是不断延期，团队士气低落，花费很高, 结果未卜的项目。经常听到组织有的项目做了两年了，每天忙碌，发布遥遥无期。 僵尸项目的终止是很难的，人们没有勇气面前现实，心存幻想。好多组织新上任的CEO第一件事就是砍掉僵尸项目。
创建一个有优先级的产品Portfolio（投资组合）待办列表。就像团队给产品待办列表里的用户故事排优先级一样，我们需要按照商业价值给产品排序，形成一个投资组合待办列表。这样，我们的团队就可以从列表里选择最高优先级的条目。团队只专注在一个产品上。只有当团队发布这个产品后，他们才能从待办列表中拉出下一个高优先级的产品。当然组织也会根据它的capacity来限制产品在制品（WIP）数量，平行启动的产品数量。团队的可用性来决定启动相应数目的产品或条目，合理平衡。
减少产品启动的数量，加速已启动产品的完成 （stop starting, start finishing）。如果一个产品开始出现不好的迹象，在变成僵尸项目前要果断叫停。这样做的目的是创造一个重新排列的动态的产品投资组合列表，更好的平衡利益干系人的需求，匹配团队的交付能力。控制投资组合中进行中的产品数量，即限制产品在制品（WIP）的数量。
(2) 限制在制品（WIP）数量在Product backlog级别的应用：
把大的产品分解成小的增量，小批次规模 （small batch size）,比如最小可投放市场的特性（MMF）。我们可以把产品功能按MMF的增量来分次发布，尽早将价值投放到终端用户手中。减少在制品数量，缩短交付周期，敏捷鼓励尽早地发布，频繁地发布(发布的cadence)。
在批次规模大小上，我们可以通过用户故事地图的工作坊形式共创（团队，PO+干系人，客户等）来管理和控制发布层次。用户故事地图把发布计划和迭代计划打通，我们和客户一起确保系统功能被明确定义，发布到每一个小的批次中。在发布层面，每个功能特性批次尽量的小，功能特性(feature)拆分不超过3周的用户故事，即使是大的Epic，每个发布也不应该超过3个月。 度量一个史诗级用户故事的平均时间周期，来管理一个发布进展。一个作为产品负责人(PO) 能管理的Product backlog条目上限是100-300个, PO必须做出决定不做什么。PO的工作是通过最小化输出（output）来最大化成果（outcome），PO 要有勇气学会say No。
与传统的做法正好相反，团队成员精力不会被分散在多个项目上，团队专注一个产品，一个小批次规模的增量发布，不会被意外需求或紧急事件打断。如果需要快速转变， PO和干系人会快速做决定。预算的机制也是incremental funding。
(3) 限制在制品（WIP）数量在迭代的Spring Backlog层面的应用：
在批次规模大小上，体现在控制迭代开发层面。一个Sprint或迭代中的每个用户故事不应该超过3天的工作量，迭代周期控制在一周或二周。LeSS 推荐一个迭代一个团队专注4个PBI （WIP）。
随着团队的成熟，建立起自己稳定的交付速率（Velocity）。我们也可以度量用户故事的流入到在生产线上发布的平均lead time。
松弛度（slack time）的引入。满负荷或过载的系统所产生的负面效应就如同高峰时的高速公路。按照队列理论，当更多个体进入队列时，系统的处理机能就会下降甚至崩溃。系统必须保持一定的松弛度。我们 Sprint计划会议要避免超载，即团队不超过80%的capacity，保持20%的团松弛度。Google， Atlassian，Spotify, 留有20%创新。允许团队成员20%的时间自己支配，这样留有的冗余让价值能流动起来，而且会创造意想不到的额外价值。
(4) 限制在制品（WIP）数量在每天的Task board层级的应用：
避免多任务并行，当我们每次致力于一件或者两件事情时，生产效率最高。敏捷团队应专注于单一产品增量发布的同时，在迭代中团队专注一个PBI (Swarming)甚至Mob Programming，对团队成员而言避免多任务并行，任务的切分也不要大于一天。番茄时间工作法对个人时间管理非常有帮助。
总之，规模化敏捷的探索，我们要坚持Inspect and Adapt的理念, 持续迭代。学习是通过持续的个体反思，团队集体回顾，依靠环境（包括客户的市场）的反馈来实现的，而改进则是通过对策略和规则的增量调整来实现的。
现实中，我们面对着臃肿的组织和复杂的流程， 我们开发人员到底离客户有多远？ 我们的管理层与开发团队是否被隔离开来了，管理层更喜欢看报告，白天“浸淫”在一个接一个的会议中，周末邮件发号施令。规模化敏捷，邀请管理层要改变工作作风，去现场（Gemba）检查（Inspect），并实施改善 （Kaizen）以期持续改进。
现场（Gemba）日语意思是“真正的地方” （work place）。它指的是创造价值的地方; 比如我们敏捷团队所在的地方和客户现场。问题在现场表现得最明显，通过亲自观察现场正在进行的工作，更容易找到最佳的改进方法。比如走动管理是一项活动，管理层到进行实际价值交付的工作前，发现浪费和改进的机会。LeSS 中，专门设计了Sprint overall retrospective (回顾会)，有管理层，PO， SM，团队代表参加， 从组织层面来看障碍。
第三条原则：
组织是以多团队网络涌现出来的动态的有机体
“The Task Force was no longer a rigid machine, it had become ‘an adaptable, complex, organism’, constantly twisting, turning, and learning to overwhelm its protean adversary” – from Stephen Denning
一个敏捷团队在高绩效的状态下运行良好，达到其规模（size）限制，比如说团队有9名成员（我倾向一个团队不要超过6人），我们不会继续扩大现有团队的规模，需要构建另一个新的团队。
为了保证新团队正确建立，一个小的种子组可能会从原团队中脱离，形成新团队的核心。 这个种子确保把原团队的愿景和文化完整地传播给新的团队。这样避免了团队臃肿，也确保团队的敏捷性。2010年3月我在上海开始组建Endeca海外的第一个Scrum 团队，就采用这种有机增长的模式，2012年底Endeca高效敏捷的中国团队（共45人）被甲骨文收购。
如何确保团队结构灵活以适应快速的变化呢？利用特性团队的变化来实施Jeff De Luca所创立的特性驱动开发（FDD）。核心组保持一致性和连续性，团队中的一些成员的“位置”，会根据交付的功能不同，在不同的“Sprint”中被替换。
为了在团队之间建立联系，Johanna Rothman推荐了一种网络非等级制度。小团队网络，随着多个团队的形成，我们希望这些网络能够在团队中有机的浮现，不是自上而下支配， 而是自觉自愿的呈现。比如，团队成员可以关联在某个共同的规范领域中，专注于改进自动化测试的工作组中，他们可以关注持续改善小组中， 建立不同的社区实践（CoP）。
“对于一个运转的大型组织而言，它必须表现的像个具有团体相关性的小型组织群一样” （E. F. Schumacher）。这样的组织群体具备复杂自适应系统（CAS）的特性，通过简单而清晰的使命，目标，原则和规则来维持和管理这样的多团队网路。有机体是一个透明的，动态进化的生态系统，它不是一成不变的。 组织像一个系统一样运作，敏捷实践者和团队都将组织视为一个流动的、透明的以团队为单元的网络，这些参与者为了客户的共同目标而协作。LeSS, Spotify, Holocracy （合弄制）, Scrum@Scale 和Team of Teams 等框架，都是团队间的工作关系网络的不同设计和呈现形式。
当整个组织真正拥抱敏捷时，组织就不再像一艘巨大的军舰，而更像一支由小型战队组成的快艇。
这样的组织网路有机体，呈现出的状态：
（1）通过结构化的、迭代的、遵从Scrum框架的实践（Scrum as a core approach）
（2）整个组织，每个人，都致力于为客户提供更多的价值, 聚焦于客户 (the law of customer)
（3）团队之间共享,包括信息的共享，能力的共享，成果的共享。为实现一个有机的规模化敏捷组织，需要组织中每个人的主动性以及智慧(而非仅是管理者的智慧)。敏捷团队采取主动，并与其他敏捷团队交互解决常见的问题。创意可能来自组织的任何一个地方，管理者认识到能力存在于整个组织中。(The law of network)
（4）日常工作中尊重、平等、协作的工作氛围和环境；体现产品、服务、工作方法的透明和持续改进的价值观；开放的、对话式的，而非由上而下、层级制的沟通，而非官僚体制来指派工作。 (agile culture and leadership)
一个真正的敏捷组织是需要组织机制，组织文化来保障。而改变一个组织的文化，始于Leadership 和敏捷领导力。比如，管理层首先要放弃权力，团队有更多的自主权和决策权。这些话题我们在CAL课程中有讨论。
小结：
有了这些核心原则指导下的实践——培植小而稳定的践行Scrum的团队, 通过限制在制品（WIP）数量来实现价值流管理，建立并演进多团队间的动态关系网络， 我们以此为基础，就会探索和构建出一套以《规模化敏捷宣言》为指导的适应组织自身的规模化敏捷框架。
Jim Wang
写于2020年2月27日疫情期间
参考资料：
(1) The Age of Agile: How Smart Companies Are Transforming the Way Work Gets Done
by Stephen Denning (Author)
(2) https://blog.odd-e.com/yilv/2017/06/team-first-or-organization-first.html
(3) Team of Teams: New Rules of Engagement for a Complex World
by Stanley McChrystal (Author) etc.
(4) https://www.scrum.org/resources/blog/eliminate-dependencies-dont-manage-them
(5) 敏捷理念在生产管理中的尝试， Dr Sven Fang
(6) “Scaling Agile A Lean Jumpstart” Sanjiv Augustine
