“没有Scrum的LeSS”描述了我们在大规模敏捷导入中从应用LeSS的组织设计元素切入 – 而非直接引入Scrum团队 – 的一次经历。自下而上的团队先行的方式虽然更常见，但是在大规模领域的导入中采用多少显得有些天真。相比之下这里呈现的组织先行的方式更接近在《LeSS：大规模Scrum》书中描述的LeSS导入指南“三个导入原则”之一：自上而下和自下而上并重来导入。为什么需要并重？因为合适的组织设计为后续辅导提供了坚实的基础，从而能放大辅导的有效性。我们在同一公司的两个不同产品开发部门都采用了这种方式。两个部门的规模不同，分别代表了LeSS和LeSS巨型的案例。
1. 背景
这个报告描述的是发生在2015-2016年期间华为杭州的两个产品开发部门的经历。我的工作是作为一个咨询师帮助他们的大规模敏捷导入。公司规模巨大，在产品开发上就有几万人。他们组织成业务线和开发部门，每个通常都有几百到几千人。之前也尝试过敏捷导入，只是多少有些偏差，比如他们实现的“迭代”事实上更象小瀑布，经常把测试和缺陷遗留到下个迭代；而“持续集成”更多只是每日构建和测试自动化，而非开发人员真正持续地集成他们的代码。
在2015年中期当我受雇作为外部咨询师来帮助他们的大规模敏捷导入时，我的内部联系人陈光镜脑海里有一些候选的开发部门，但是并没有任何一个已经决定采用LeSS或者类似LeSS的方式。因此，我们做了一系列LeSS培训来提升大家的认识并对LeSS意味着什么建立合适的理解，更多细节在稍后描述。
大家从培训中意识到LeSS带来的变化要比他们预想的更大，这并不让人吃惊。事实上，在最初的工作坊后没有一个部门立刻表达想尝试的意愿。这是问题吗？根本不是！我们更感兴趣的是少数部门能够基于正确的理解和刻意的选择迈出真正有效变革的步伐，而不是大量部门玩着“变革游戏”。事实上，我们最不想要的是又一次假的变革，因为那样并不会带来任何有意义的好处。很多部门从未迈出下一步。
然而，还是有两个部门决定向前推进，他们成了这份报告中的两个案例。
1.1 为什么组织先行？
很不幸，在项目上试点Scrum的做法很普遍，因为一个项目团队天生是跨职能和端到端的。为什么这样的做法经常会注定失败？项目组织中遍布的是传统的矩阵结构，项目团队并不是一个真正的团队，而只是一组人，他们各自关注自己的诸如前端开发和测试之类的专业领域。尽管在“项目管理理论”上，即使没有进行有意义的组织结构变革，也是可能让“项目团队”里的每个人都对齐共同目标并承担共享责任的，但是这种对齐至少是脆弱的，就我的经验而言，很少能真正实现。
为什么会这样？
- 项目团队成员的部分分配导致了多任务。这不仅降低了个体效率，而且带来了下一个问题。。。
- 项目团队成员不交叉学习其它专业，因为他们被充分使用以获得“局部的高效”。这减少了学习，从而降低了作为一个团队的适应能力，这在下一个问题中就有所反映。。。
- 项目团队成员没有蜂聚来把条目完成。“团队”只是名义上的，他们其实只是一组个体而已，并不能一起工作来达到共同目标。这带来了下一个问题。。。
- 项目团队成员不能形成自管理团队。因为在实践中他们没法“同时同地”地工作于共同目标，需要其他人管理他们来达到目标，这便是传统项目经理的角色。而项目经理的存在又加重了团队自管理的缺失。
考虑到团队会面临其它诸如协作能力不足和工程能力弱之类的挑战，由组织结构引起的缺乏动力会让成功变得更遥不可及。在我的经验中，很多团队在一段时间后都步履蹒跚。一些组织通过改变组织结构得以继续向前，而另一些则回退到过去。
这一问题在Richard Hackman的工作中有很好的表达。图1来自他的经典书籍《Leading Teams》，其中展示的团队绩效、团队设计和辅导之间的关系极具洞察。团队设计和辅导都对团队绩效有影响，但相比之下团队设计起到更大的作用。
在Scrum中，ScrumMaster（SM）负责提供有效的辅导。但在我的经验中，大多数组织里最初的SM们还只是刚开始学习如何辅导，而许多暴露出来的障碍的根源都会和组织结构有关。由此带来的辅导复杂度对他们来说有些过于强大。除此之外，当开始导入时，辅导这一概念对我的客户而言是陌生的，他们很难想象一个没有指定管理者的自组织团队。如果我们在现有的结构（没有组织重新设计）下试点Scrum，让经验欠缺的SM去尝试辅导团队通往自组织，成功的几率将会很低。
因此，我们采用了不同的方式：1）首先专注建立合适的结构；2）然后再增加辅导的能力。
另一个首先专注于组织结构的原因是因为这个特定的咨询任务 – 我被期望能帮助到他们获得在大规模敏捷导入中应用LeSS的经验和好处。深入的组织重新设计是成功导入LeSS的必要条件。事实上，因为其重要性，它被突显作为一条导入相关的LeSS规则：“对产品组从一开始就建立完整的LeSS结构，这对LeSS导入至关重要”。
大多数组织试图避免组织结构变革，因为他们觉得这有些冒险。当它同时涉及成百上千人时，风险是客观存在的。但是到目前LeSS导入已经积累了很多经验，我们现在对这些风险具备很好的理解。基于此，成功导入LeSS的另一条原则是“狭窄但深入胜于宽泛但表面”。这意味着在“较小的”大规模场景，也就是50人左右或更少，我们从一开始就建立完整的LeSS结构。相反，在很大的大规模场景，也就是LeSS巨型的范畴，导入过程中的结构变革则采用演进增量的方式。
1.2 组织的约束
导入LeSS最初的关键决策之一是定义什么是我们的产品。在华为，几乎所有的产品开发都被分散到多个部门进行，而且那些部门都是组织实体，如图2所示。
有各种产品开发部门存在。“产品”的开发部门负责面向终端客户的真正产品，但它通常依赖于诸如平台或网管之类的其它部门。平台被进一步拆分成应用平台和基础平台，而对应的部门也做同样的拆分。复杂产品构建在应用平台和基础平台之上；而简单产品则只是构建在基础平台上。
举个例子，基站是面向电信运营商（比如中国移动）的一个真正的产品，它就构建在平台之上，并依赖于网管。这样一来至少涉及三个产品开发部门来交付完整的解决方案：基站（“产品”开发部门），平台（至少一个“平台”开发部门）和网管（另一个“产品”开发部门）。这只是一个简化视角，真实的情况是通常会涉及多个平台。
作为一条LeSS规则，“产品的定义应该是在实际的前提下尽量广并且以终端用户/客户为导向”。从把产品定义扩展得尽可能广来说，它应该包含整个栈。然而，因为和我们工作的是部门的管理层，他们只能在自己的范围内做结构变革，我们初始的产品定义也就受限于部门的范围。这与LeSS指南“定义你的产品”中的建议一致，一个常见的把产品定义缩小的约束力来自于现有的结构。如图3所示，“产品”开发部门的可能演进路径是扩大到至少包含“应用平台”开发部门；而“基础平台”开发部门可能演进成真正的通用平台产品，但是我们必须理解这意味着进入一个完全不同的市场，与完全不同的客户打交道。
我们工作的两个产品开发部门代表了两种不同类型：一个是基础平台，而另一个是产品。尽管这里的产品确实使用了这里的基础平台（是它使用的若干个平台之一），但是它基本就是拿现成的基础平台来用，而非要求平台做很多改动以支持产品。因此，虽然理想的产品定义扩展可以包含这两个“产品”，我们还是把它们作为独立的案例来对待。它们也代表了不同的规模，一个大约40人，而另一个大约120人，正好分别提供了LeSS和LeSS巨型的情况。我们在2015年晚些时候开始了LeSS的案例（基础平台部门），然后在2016年开始了LeSS巨型的案例（产品部门）。有一段时间我同时跟这两个部门工作。
2. 在“平台”开发部门的LeSS导入
在这个案例中的部门开发一个被多个上层商业产品所共享的平台，在辅导的时候是大约40人的规模。有必要重复之前的一个要点，在一个理想的更广的产品定义里，这个平台部门不应该是一个单独的“产品”，而只是更大产品的一部分。但是，组织结构边界使得一上来就定义更广的产品并不现实。这种可能的艺术也在LeSS对产品定义的规则中得到了体现：“产品的定义应该是在实际的前提下尽量广并且以终端用户/客户为导向。随着时间的推移，产品的定义可能会扩大。我们倾向于更广的定义”。
该平台提供了诸如操作系统扩展、通信、补丁之类的功能。它们处于下层，因此对其它开发部门很少有依赖，而是其它部门依赖于它们。对它们的需求并不是直接的客户需求，而只是由上层应用（另一个平台或者一个真正的产品）定义的解决方案的一部分。
2.1 建立认识
最初的一次LeSS工作坊发生在2015年8月。它是一个两天的工作坊，专注于理解一份产品待办列表和特性团队背后的组织设计原则。我们邀请了来自一些开发部门的关键管理者和有影响力的领导；其中有一半是来自这个平台部门。简而言之，我们以LeSS指南“启动”中的第零步“培训所有人”开始。然而，决定做组织结构变革已是2015年晚些时候了，大致是在工作坊过后的3-4个月。这也是LeSS导入中常见的做法：缓慢决策，在实际变革之前仔细学习和讨论。期间我们有过几次和管理团队的深入讨论。考虑到组织变革的风险和它涉及很多人员变更，这是寻常的节奏。
在变革开始之前很久它就已经开始了。
2.2 一个产品负责人和一份产品待办列表
工作重新设计的一个关键方面是创建一份且仅一份由多个特性团队共享的产品待办列表。这反映了LeSS规则：“对整个可以交付的产品有一个产品负责人和一份产品待办列表”。主要的改变总结于图4。
| 之前 | 之后 |
|---|---|
| 工作是散落的，包括客户需求、改进、维护等 | 所有工作都在一份产品待办列表 |
| 工作以项目群来组织 | 工作以产品（这里是平台）导向来组织，而项目群只是作为对外接口 |
| 多个项目群经理 | 一个产品负责人 |
| 完成是分阶段的（比如分析、开发、测试） | 对所有需求有共同的完成定义 |
收集所有的工作放入一份优先级排序的待办列表是工作重新设计的关键。我们去除了项目群，从项目群模式转换为产品模式。这与LeSS指南“产品胜于项目或项目群”是一致的。
我们遵循了LeSS规则“对整个可以交付的产品有一个产品负责人和一份产品待办列表”，设置了一个且仅一个产品负责人。之前组织里有多个项目群经理会给团队指令，可以想象得到，这些指令之间常导致优先级冲突。当我们去除了项目群时，我们也去除了项目群经理的角色。其中一个前项目群经理因为有着扎实的业务理解和与真正产品部门良好的工作关系，所以就成为了产品负责人。
为了在实践中让一个产品负责人能工作顺畅，比如不会工作量过载，有必要让产品负责人更多关注优先级排序，而让团队做更多需求澄清，团队尽可能直接地与客户工作。这样的做法符合LeSS指南“优先级排序胜于需求澄清”。我们在后续章节2.6 迭代实践中对此将有更多描述。
2.3 初始的完成定义
跟工作重新设计相关的另一个重要方面是约定完成定义。我们拿他们原有的迭代交付标准作为起点，与版本发布标准加以比较，澄清其中不清楚的问题。最初的完成定义是由产品负责人、领域专家和管理者一起起草的，然后在第一个迭代开始前经过了新组建团队的评审。这一步骤和LeSS指南“创建初始的完成定义”一致。初始版本的完成定义并不完美，因为它并没有以可交付的产品作为迭代结束。在（不完美的）“完成”产品增量和最终真正可交付的产品增量之间有大约两周的延迟。完成之外（也就是正式识别为暂时不包含在初始的完成定义之内）的工作主要有两类。
一类是完全由“平台”开发部门自己掌控的内部工作，其中最重要的是全量回归和安全检查。全量回归仍然部分依赖于手工测试；而现有安全检查流程带来的工作量很大。基于现状考虑在初始的完成定义中包含它们并不经济。
另一类是和应用层的集成工作，它需要和其它开发部门一起完成，因此也就不是自己能完全掌控的了。按传统的做法其它部门不会使用还在开发中的功能，他们依然抱有集成可以轻松完成的幻想，因此觉得没必要提前来做。
我们把这些完成之外的工作放入暂时还需要的发布迭代中来做。发布迭代的做法在LeSS指南“创建初始的完成定义”中的第三步“探索如何处理完成之外的工作”有提到，关键点是特性团队而非其它单独的团队来做完成之外的工作，以避免交接浪费。
后来我们在减少这两类完成之外的工作上都取得了实在的进展，这一点遵循了LeSS指南“演进完成定义”。
具体怎么做的呢？我们通过自动化和流程优化把内部工作移到迭代里做，也就是把它们包含到完成定义中。同时我们通过改善和上层应用的协同把部分需求的集成工作也移到迭代里做。
2.4 自设计团队
在导入LeSS之前，该平台有4个组件团队各自负责不同的组件，和1个测试团队。我们通过自设计团队工作坊将他们重组成6个特性团队，自设计团队的做法反映了LeSS指南“三个导入原则”中的另一个：“使用志愿的方式”。我们的目标是将单一职能组件团队的组织结构改成跨职能特性团队的组织结构。这符合与团队结构相关的LeSS规则 – “每个团队是：1）自管理的、2）跨职能的、3）同在一地的、4）长期的”和“多数团队都是以客户为中心的特性团队”，以及LeSS指南“构建基于团队的组织”和“LeSS组织结构”。
管理层和我制定了一些新团队的约束，最初的列表如下：
- 团队规模5到6人
- 团队跨职能
- 团队跨组件、特性导向，能够完成平台范围内的“端到端特性”
- 团队知识面广，从而具备适应性（灵活性），能够从一份共享的产品待办列表里挑选任一条目
针对最后一点，我们对每个团队发展成什么都能做但是什么都不够深入的可能性有所顾虑。尽管每个团队能做任一条目提供了最大的灵活性，它也给短期交付带来了最大的挑战。不幸的是总有更快交付的压力，由此导致拓展学习的间隙不够。为此我们应用了LeSS指南“偏好在客户领域的专业化”，是怎么做的呢？
该平台有4个相对明显的领域（比如操作系统扩展、补丁），重组后会有6个团队。我们试着兼顾广度和效率，通过两条约束条件：1）每个团队至少能做两个领域的工作；2）每个领域的工作至少有三个团队能做。这样一来，每个团队还能有一定程度的专业化，它对效率有利；同时也能做到整个组织仍以来自产品负责人输入的优先级顺序工作，而不用因为受限于能力不得不去调整优先级。
在决定了约束条件后，我们继续设计了工作坊的日程。我们参考了这篇文章中的一些做法，制定的大致日程如下：
- 开场（开发部门领导强调了自设计团队工作坊背后的动机）
- 自荐成为组长（参见后续章节2.4 对比SM和组长）
- 自组织团队第一轮（依据管理层设定的初始约束条件）
- 自组织团队第二轮（加上参加人员提议的额外约束条件）
- 自组织团队第三轮（修复“缺陷” – 未满足的约束条件）
- 创建团队简历并介绍给整个部门
- 收场（参加人员志愿分享感受和意见）
每一轮结束都有6个涌现出来的团队设置。第二轮开始时让参加人员提议额外的约束条件以帮助更好地组建团队。当他们看到第一轮中出来的一个具体的团队设置时，提议额外的条件要容易很多。比如，他们注意到有些涌现的团队全由资深人员组成，而另一些则全是初级人员。当这点被提出时，有一个简短的自由讨论，然后检查共识，有共识的条件就被加进列表。第三轮开始时则让所有人员给第二轮涌现的团队设置报“缺陷”。“缺陷”可以是1）某个团队缺乏测试技能，2）某个领域的工作只有两个团队能做，等等。然后他们自组织来修复那些未满足的条件。
整个工作坊花了两个半小时，6个稳定团队就此产生，还有因此充满的能量。前后状态的对比总结于图5。
2.5 对比SM和组长
对华为来说，导入LeSS – 更准确说是Scrum – 的一个挑战是引入SM角色。SM是教练，而教练角色在传统组织里几乎是不存在的。同时组长角色却很普遍，传统组织会让他们对团队绩效负责，其实这里的团队只是一个群组而已。这与Scrum和LeSS里的团队问责模型大相径庭。
当意识到在这点上没法达成共识时，我们决定保留组长角色，而把问责定义得相对模糊 – 由组长和团队共同承担。这样的安排并不理想，但却是我们的起点。随后我们给组长做了辅导自组织团队的培训，并通过引导站会和迭代回顾来具体示范。在那以后，有些组长拉我帮助他们进一步提升辅导能力。有些组长发展成更接近SM和教练的角色，而另一些组长则基本延续了他们指挥控制的传统方式。
2.6 迭代实践
在合适的组织结构（除了还保留的组长角色）到位后，我们就能相对直截了当地实施LeSS迭代实践了。
2.6.1 产品待办列表梳理
因为我们整个平台所有6个团队只有一个产品负责人和一份产品待办列表，我们从整体产品待办列表梳理开始。它不仅开始澄清工作，还协调团队间如何做后续的梳理。这跟LeSS指南“整体产品待办列表梳理”的做法是一致的。产品负责人和团队代表一起决定哪些团队会梳理哪些条目。对有些条目我们直接决定由哪个团队来做；而另一些则不定，因此让多个候选团队一起来梳理，直到迭代计划时再决定最终由哪个团队来做。即使团队是跨职能特性团队，具体的知识却不会均匀地分布在每个团队，因此不同团队的成员还是会按需被拉入帮助梳理特定条目。
2.6.2 迭代计划
迭代计划的两个部分都在一个大的共同空间里联合举行，如图6所示。参加人员包括产品负责人、所有团队成员、一些使用平台的开发人员，以及一些“技术支持”人员。因为多数条目的计划和澄清都能受益于多团队和多干系人的输入，所有人在一起确实帮助很大。在这个案例中有一个经验教训是我们并没有在迭代计划之前做足够的多团队产品待办列表梳理（我们多数时候做的是单团队产品待办列表梳理），这导致了在迭代计划时仍需要比正常更多的干系人参与和更多的澄清和协调讨论。比如说，有一次我们发现不同团队从两个（真正的）产品部门收到两个单独的条目，但它们背后其实是同一个需求。如果我们做更多的多团队产品待办列表梳理的话，就能更早地发现这样的问题。好在让多个干系人参加迭代计划还是能让我们看到它并加以解决。
迭代计划一的目的是理解要做什么。通常先由产品负责人大致讲解一下产品待办列表和接下来迭代的候选条目。团队一起决定那些条目分别由哪些团队来做。为了降低风险，产品负责人确保高优先级的条目被分布到多个团队。LeSS指南“迭代计划一”中就有“散布高优先级条目”的建议。对一些条目我们已经在产品待办列表梳理时确定了团队，而对有些条目由哪个团队做则在计划时决定。在选择完后，团队并行地澄清一些没有在梳理时考虑到的需求细节，并与会使用这些功能的开发人员直接讨论验收标准。当发现条目范围不清晰时，产品负责人就会被拉入到讨论中来。
注意我们的需求澄清是从产品待办列表梳理开始的，并在迭代计划一中继续。这实际上是混合了两个LeSS指南 – “多团队产品待办列表梳理”和“迭代计划一” – 中的活动。
迭代计划二的目的是理解要怎么做。我们的做法是所有团队在同一个大空间里继续进行迭代计划二，也就是以所有团队替代了LeSS指南“多团队迭代计划”中的部分团队。为什么所有团队在一起做迭代计划二呢？因为这能增加团队识别出协调机会的概率。经常会听到有团队只是喊一声“我们下个迭代要对组件X做大改动，有团队需要一起讨论基本设计吗？”，然后就有其它团队响应。
在迭代计划一或者二中，可能有些团队发现他们其实做不完那么多条目，而另一些团队则发现他们能做更多。当所有团队都在时，很容易由他们和产品负责人一起通过自组织来调整。
在开始迭代时我们的计划效率低，但是我们坚持对计划限制时间，这意味着前几个迭代的计划产出并不够好。最初我们只能识别出一些验收标准，并只能创建巨大且模糊的任务。当我们的计划能力提升后，在同样的时间内，我们能够草拟出验收测试，并通过对设计和协作的更多思考来创建更小更清晰的任务。
2.6.3 利用站会来辅导组长
组长对站会有着各式各样的理解，有些把站会误解为状态汇报会，站会是个通过示范进行辅导的好场合。每次我去都会观察他们的站会，并试着问有效力的问题，比如“我们这个迭代的目标是什么？”、“对我们达成目标最重要的风险有哪些？”、“什么让我们慢下来？”、“哪些是我们达成目标最重要的任务？”、“我们该如何调整？”，等等。通过问问题让团队自己思考并讨论决定如何推进这样的方式帮组长打开了如何带队的视野。他们中有些对辅导的方式很感兴趣，并开始学习问有效力的问题；而我则专注于给那些想成长为教练型组长的人更多帮助。
2.6.4 跨团队协调
他们整个部门都在同一层楼办公，这以非常简单的方式有力地帮助到了跨团队协调。
在迭代运作过程中从来没有涌现出对Scrum of Scrums会议的需要，这也和LeSS指南“可能不用Scrum of Scrums”相吻合。在产品待办列表梳理和全员都参加的多团队迭代计划二之后，团队通常对在迭代中需要与哪些团队保持紧密沟通心中有数。他们建立了各种渠道来分布式地协调，这也符合LeSS关于协调的规则，“偏好分布式的和非正式的协调，胜过集中式的协调”。具体怎么做呢？一个例子就只是让一个成员去观察另一个团队的站会，也就是LeSS指南“侦查员”的做法。
引入组件评审员主要是为了降低特性团队对组件知识欠缺所带来的质量风险，但是他们也有助于发现跨团队的协调需要。
测试社区是LeSS指南“社区”的一个实例。它不仅支持学习和提升测试技能，也同样有助于发现跨团队的协调需要。
这里的多渠道和着重识别协调需要正是LeSS看待协调话题的两个要点。
2.6.5 从质量控制到内建质量
在LeSS导入之前，这个部门传统的质量实践是“在创建后检查出缺陷”，而非“在创建时内建质量”。他们的质量实践包括设计文档评审和代码评审，都是在创建之后发生的。不幸的是，他们还没有掌握LeSS指南“多团队设计工作坊”和XP中结对编程这样的实践，而用这些“内建质量”实践替代事后“检查出缺陷”的活动将会更有效。因此，即使导入LeSS之后，他们还是继续了之前的评审活动，这些活动由少量指定的评审员来执行。
LeSS导入至少让这些实践带来的问题变得明显，因为它们延缓了开发和阻碍了持续地集成工作。
他们为此做了两个调整。第一个是增加了评审的频率，并提倡小批量频繁提交。第二个是增加了指定评审员的数目，以达到至少每个团队一个。
这些评审员同时在帮助团队增加对组件的知识，以避免在评审中出现大量的意见。随着时间的推移，在团队内的指定评审员被授权可以决定对某项工作的评审是否必须。
2.6.6 迭代评审。。。从“消费者”那里获取反馈
开始时我们想过邀请一些作为“消费者”的开发人员和干系人参加迭代评审，但是发现他们并不感兴趣。主要的原因还是在于这个平台并不是真正端到端的产品，而只是一个技术平台。迭代评审本义是要看并使用有意义的功能，而平台的功能最终都呈现为给上层应用的API和服务，这些并不适合在迭代评审中被“使用”。
因此，通常在迭代评审中就能获取的有价值的反馈在这种情况下只有当作为“消费者”的开发人员集成并使用了迭代产出的平台增量时才能获得。
我们都认同最有价值的反馈来自于对平台的集成使用，所以把焦点转向在迭代中，而非在迭代评审时，学习来自“消费者”的反馈。最终，我们扩展了完成定义来反映这一点，就是和上层应用的集成也要在迭代内完成。这提醒我们在决定条目优先级时问一下，“什么时候上层应用会消费这个条目？”。事实上，之前发生过在条目被交付后才发现已经不需要它们的情况。
当在迭代中对条目的使用就已经发生时，作为“消费者”的开发人员和团队直接交流，任何问题都能马上显露。到迭代评审时，我们只是分享期间的学习和反馈，讨论它们的影响并相应更新产品待办列表。
因为平台本质上是真正产品中的一个大组件，我们没法在迭代评审中根据完成条目和未来条目的真正客户价值来做检查并适应。真正的检查并适应发生在产品层面，而平台的工作则是集成进了真正的产品条目中。因此很不幸，我们的迭代评审更多的是在关注如何调整产品待办列表以满足各个产品的版本发布日期。
2.6.7 回顾和持续改进
针对持续改进，我们既做迭代回顾也做整体回顾。这里我把已经提到的一些过程改进例子总结如下：
- 从强制的评审流程演进为志愿的评审流程
- 把和应用的集成移到迭代内做
- 测试自动化以降低全量回归的成本
- 流程优化以降低安全检查的成本
从第一个迭代开始我们就引入了团队层面的回顾。传统的做法是组长会思考改进想法，然后让团队去实施。当过去组长询问团队想法时通常是一片沉默，这样的经历让组长不知如何让团队成员参与到持续改进中。我给所有的团队引导了至少一次回顾，示范了通过有效引导是能够产生不同效果的。比如，我们一起构造时间线来看到整个团队对过去迭代的视角；我们通过1-2-4-所有人的结构来共同产生行动想法。有些组长对引导的带队方式产生了兴趣，而我就会跟他们工作以帮助提升他们的引导能力。
我们也实施了LeSS规则“整体回顾”。我们在第一个LeSS迭代之前举行了一次全员参加的特殊整体回顾，它是就过去2-3个月开发上个版本的经历所做的反思。对于每个迭代的整体回顾，开始时只有组长、产品负责人和部门管理者参加。我们讨论了是否让团队代表参与进来，但是决定作为第一步先不让他们参与了。为什么呢？因为不幸的是让实际做事的团队成员参与到“组织改进分析”中这样的做法还是太过“激进”，所以我们决定在转变过程中采取小步走，先从组长开始，之后才把其它团队成员集成进来。
在持续改进中的一个焦点是缩短从不完美的完成增量到完美完成的可交付增量之间的时间。这是我们好几个迭代整体回顾的主题。通过系统性地移除障碍和扩展完成定义，参照LeSS指南“演进完成定义”的做法，我们在6个月期间将这个时间从大约两周缩短到三天。
整体上来看，在周期时间和效率上我们有了显著改进；而在质量上，就外部缺陷而言，在LeSS导入之前已经处在较低水平，之后则保持了低水平。
2.7 剩余的主要弱点和待改进方面
在我离开时，这是一些主要的仍待改进方面：
- LeSS导入的整个范围仍然只是局限在平台内，而跨越从上层应用到底层平台的更广的产品定义是继续演进的目标。
- 完成定义依旧不完美，还需要三天时间来处理完成之外的工作才能真正达到潜在可交付。
- 特性团队的专业化程度对完全按产品负责人的优先级工作仍有一定约束，有需要进一步拓展学习。
- 把问责从组长身上移除，然后完全给到团队。当然那样也就意味着移除组长角色。
- 更多的多团队产品待办列表梳理以增加学习广度，从而带来更强的团队适应能力。
- 加强结对或群体编程和持续地集成来提高“内建质量”。
- 在整体回顾中有团队成员的持续参与。
3. 在“产品”开发部门的LeSS巨型导入
我们接下来（更简短地）讨论的第二个案例是个LeSS巨型导入，它发生在另一个产品开发部门。如前所述，虽然这个产品确实用到了上个案例中的平台，它们的LeSS导入是各自独立进行的。
这个案例中的部门开发一个网络安全产品，由大约120人组成。这个组织的规模超过了较小的LeSS框架（适用于50人左右），因此用到了LeSS巨型框架。该部门有三组人，一组在北京，做web接口；另两组在杭州，做网络设备上的工作。有很多特性仍然会跨越前端的web接口和设备上的“后端”组件。
3.1 需求领域
在LeSS巨型中的关键决策是需求领域的建立。按照LeSS指南“需求领域”的做法，它既是工作的组合也是人员的组合。
一个较小LeSS框架的导入应该是“一步到位”的，但是LeSS巨型的导入是不同的。因为由此暴露的复杂度和弱点会是巨大的，所以我们需要考虑两个LeSS巨型导入的关键指南：“演进增量地导入”和“一次一个需求领域”。
这意味着在LeSS巨型导入的早期会是有些组处在特性团队的新模式，而有些组则处在组件团队的旧模式。举例来说，理想情况下我们应该解散北京的web接口组，因为它只是一个大的前端组件组（由此带来延期、交接和其它浪费）。但是考虑到这是一个在异地的组件组，而我们刚迈出LeSS导入的第一步，我们决定暂时保留那个组的传统工作方式。一开始就试着解决它实在过于困难。
所以我们决定先从杭州开始建立两个需求领域，而北京则暂时仍以一个传统的组件组工作。两个需求领域分别是“协同运营”和“系统支撑”。
为什么从一地开始？虽然LeSS导入可以是也通常是多地的，我们觉得在第一步不要引入太多的问题以确保有可见的成功非常重要。一下子引入两地或者多地增加了组织被太多问题淹没的风险，而初期赢得对LeSS导入本身的支持依然至关重要。
因此我们应用了巨型指南“演进增量地导入”，但是并没有应用另一条指南“一次一个需求领域”。为什么呢？在杭州“只有”80人，因此只会有两个需求领域，而且结构上需要调整的并不大，基于此我们觉得相对有信心在两个需求领域同时导入。
另一个有趣的决策是我们是否将需求领域和正式的直线组织结构绑定。我们决定将正式组织结构和需求领域分离，也是遵循了LeSS指南“LeSS巨型组织”里的建议 – “避免将需求领域等同于组织结构，因为这会导致需求领域难以改变”。为什么有这样的建议？我们在这个案例中就直接看到了那样做的问题。该产品的每个市场版本大约6个月，从这个版本到下个版本，优先级的重点会从一个需求领域转向另一个需求领域。我们希望有一些团队能在不同的版本周期移到不同的需求领域工作。如果这样的调整需要改动“汇报线”，考虑组织政治的因素，进行如此频繁的“汇报线”变更将会非常痛苦。结构具有粘性！为了能够适应两个需求领域之间优先级的波动，我们计划在每个需求领域都能有一个团队可以按需工作到任一领域。
3.2 产品负责人团队
我们按部就班设置了一个产品负责人和两个领域产品负责人，还有三个项目群经理角色也被保留下来，但只作为和公司其它部分的接口。他们一起组成了整个产品的产品负责人团队。
产品负责人是那个组织里最资深的人之一，他有能力与多方干系人工作并做出艰难的优先级决策。然而，我们没能在组织里找到同样经验水平的人来做领域产品负责人，这清楚地反映了该部门在产品管理上的弱点。领域产品负责人最终需要直接与干系人工作并能自己做决策，产品负责人以此为愿景扮演了领域产品负责人导师的角色，不只是帮助他们完成工作，还帮助他们成长。这跟LeSS指南“LeSS巨型产品负责人”里描述的他有培养和支持领域产品负责人的职责是一致的。
3.3 在需求领域中的扩展组件团队
因为北京的web接口组仍然保留作为一个组件组，我们没法一步到位完全实现特性团队。在这种情况下，LeSS指南“特性团队导入地图”提供了一个演进路径。我们是以扩展组件团队开始的，这意味着每个团队能在一定范围跨组件开发，因而减少了浪费增加了适应性，但是仍然没有达到完美愿景中能够全栈工作的真正特性团队的状态。
作为LeSS巨型导入的第一步，这些扩展组件团队是基于命令行接口对网络设备做自动化和手工探索测试的，而web接口组则做完整的端到端集成测试。
为了实现扩展组件团队，一个变动是我们把测试组分散到各个团队，以使每个团队都包含稳定的测试人员。
为了实现每个领域共享一份领域产品待办列表，我们需要创建有能力做领域内任何条目的团队。在变革之前，每个团队都工作于单一的专业子领域，本质上在每个子领域都有一份隐性的待办列表。如何创建领域内的全面团队呢？我们并没有进行团队重新设计，而是让已经存在的团队扩展他们的工作范围到更多组件，过程中他们得到之前相关专业人员的学习和反馈支持。这样的方式可行是因为子领域之间的技能差异并不大。
按照特性团队导入地图中的增量方式，LeSS巨型导入的未来步骤会是杭州的团队要学习web接口开发工作，从而变成全栈特性团队，当然也承担完整的端到端测试。
3.4 依赖
在LeSS巨型里多数的迭代活动通常是按需求领域进行的。这里是个真正的产品，而非平台，因此带来了更多的依赖复杂度。该产品依赖网管和若干平台，而它们都是由其它部门开发的。考虑到组织边界，把团队扩展到跨不同开发部门并不现实，所以我们不得不借助其它方式管理依赖。SAFe在公司的很多部门都有采用，所以我们对此的策略简而言之就是在部门之间做SAFe的“项目群增量”同步来管理依赖，而在部门内则转向特性团队来消除依赖。当我们能把工作同步到同一迭代时，集成就可以在迭代内持续地进行。然而，跨部门不同步的问题还是时常发生，这是因为在更大结构上有着根本性限制 – 其它部门本质上是在给我们的产品开发组件。
在未来有机会扩展到更广的产品定义时，它应该包含网管部门和“平台”部门的工作范围。那样我们就能扩展成真正从前端到后端的特性团队，从而消除那些依赖。
4. 我们学习到的
我们的经历对Richard Hackman的发现 – 合适的团队设计比有效的辅导更能影响团队绩效 – 有很强的共鸣。LeSS对组织设计的强调也反映了这一点。传统的方式是在现有结构里试点，而结构先行的方式会是一个更好的替代方案。
如果我们能约定一个针对有效辅导的愿景将会是更好的情况。因为在组织层面缺乏这样的约定，是否转向辅导方式的选择留给了组长个人，这限制了我们作为整个组织在自组织团队上能走多远。
在战术层面，我们主要的学习收获总结如下：
- 用渐进的方式来扩展领域专业能力以获得更多灵活性。
- 从传统组长到SM/教练的转型路径。
- 通过跨团队的联合Scrum活动来促进自组织。
- 让所有团队深入参与需求澄清和反馈，以使一个且仅一个产品负责人能够对应多个团队。
从某种意义上，这个经验报告并不是一个完整的故事。它没有讲我们参与之前发生的事。在组织里工作的人需要理解LeSS导入带来的变化是很大的，因此得准备发挥可能的艺术，并抱有耐心一直坚持到组织能够重新被设计。
5. 致谢
我想特别感谢我在华为的联系人陈光镜。我们在整个过程中都紧密工作，对如何帮助这两个部门推进有过很多深入的讨论，也分享了很多洞察。
这个经验报告最初的版本是在敏捷2017大会上发表的，我想感谢Chris Edwards对此的无私帮助。在随后将它变成一个LeSS案例的过程中，Jurgen De Smet作为我申请LeSS培训师的导师给予我了很多有用的反馈。最后，我想感谢Craig Larman帮助我再次改进它，最终成为了它现在的样子。
