第一部分 Part 1 LeSS结构
第3章 采用
生大材，不遇其时，其势定衰。生平庸，不化其势，其性定弱。
——老子
单团队 Scrum
Scrum简单，但采用Scrum却并非如此。为什么会这样呢？
Scrum不是一个过程，它不会如魔法般神奇地解决问题，并创造出“高产”团队。它是一个可以建立短反馈回路以大大提高透明度的框架。它就像一面镜子，能照出团队创造产品的能力，会暴露团队和组织中的问题。这种可见性是经验性过程控制的基础，它与检查-调整原则一起，将团队、产品负责人和组织置于一个持续改进的循环之中。
经理们正在思考如何通过改进来助力开发
这是个好消息，但坏消息是这太糟糕了。事实上，透明会令人不安，甚至具有威胁性，这会使方法的采用变得困难重重。
单团队Scrum对Scrum的采用描述不多，而只是讲“照着书本开始”。这并不是因为Scrum狂热者想要在世界上强制大家使用他们喜爱的规则，而是承认改进始于遵循和理解标准，或者像精益思想中所说的，“没有标准，就不可能有改善。”通过这本书体验Scrum可以让读者从一个系统思维的视角了解Scrum原则和实践之间的关系，这对Scrum的成功至关重要。
经验丰富的Scrum Master加上对Scrum有深刻理解的团队将极大提高成功采用一种方法的可能性。
3.1 LeSS采用
LeSS采用涉及大型组织和许多关于组织应该如何运作的根深蒂固的假设。成功的采用需要挑战这些假设，以及简化组织结构，所要用的武器就是大团体工作中需要的激烈的政治观点和敢于“丢面子”的勇气。方法的采用需要每个人参与改进，并朝着共同的目标努力。
当规模扩展时，与采用相关的原则包括：
持续改进以求完美——采用LeSS的团体自然会提出他们对采用的观点和习惯。这些观点和习惯会是什么呢？创立变革愿景，启动多项变革工程。当最初的目标明显已经实现时，
1.“变革完成”，而且
2．本组织将维持新的现状，直到
3．下一次变革需求出现，然后
4．撤销以前的变革。
这种经典方法类似于软件开发中的顺序“大批量”方法，其中变更作为一种例外受到许多变更控制委员会的控制和严格管理。
在LeSS采用中，没有变革的倡议，没有变革的群体，没有变革的管理者。在LeSS框架中，变革通过试验和改进来进行，并且其是连续的，变革就是现状。
3.1.1 LeSS规则
对于产品组，要把建立完整LeSS结构“作为起始点”，这对LeSS的采用至关重要。
对于超越产品组的较大组织，通过使用“现场观察”实践，演进式采用LeSS，从而创建一个以试验和改进为准则的组织。
3.1.2 指南：三个采用原则
这些原则对于组织的LeSS采用至关重要：
❑深而窄优于宽而浅
❑自上而下与自下而上
❑使用志愿服务
深而窄优于宽而浅
在一个产品组中采用LeSS
比在许多产品组中采用LeSS效果更好。
不良的LeSS采用具有危害性。缺乏深刻的理解会破坏作为经验性过程控制和持续改进的关键因素：透明和反馈回路。我们甚至看到“LeSS”被滥用作一种非凡的微观管理工具。故而，在微观管理式LeSS采用成为既定基准之后，那就真的很难再做改变，因为重新学习已知的东西是很困难的。
因此，只需将LeSS采用的工作集中在一个产品组上，为其提供所有必要的支持，并确保其确实能正常工作。这样做可以最大限度地降低风险，如果遇到大问题，它就会触发一个具有针对性的学习机会。成功的时候，它则会激起正面的“传言”，这是进一步实施采用的重要营养素。
自上而下与自下而上
我们经常被问到一个问题，方法的采用最好是自上而下还是自下而上。这是一种错误的二分法。只做任何一种，则可能招致失败，需要两者都做。
纯粹的自上而下——经理驱动的“你应该做LeSS”式的采用会引起阻力，并使组织面临失败。命令团队去管理自己是一个矛盾体。LeSS采用需要深刻的理解，它不是来自指令，而是来自讨论。只有通过理解、选择和个人安全感，人们才能承担起反思和改进的额外责任。缺乏这些因素所造成的不良局面会因“我们-他们”，即经理与员工之间的关系而被放大和加剧。在这种情况下，强迫LeSS进入组织会助长受害者行为，并进一步降低管理层和员工关系的融洽度。人们会说：“我们别无选择，我们的经理说我们必须做LeSS!”他们会秘密地或许是不知不觉地、舒适地，或者至少是熟悉地躺在受害者的位置上休息。
纯粹的自下而上——这种LeSS采用是不可持续的。一开始，这种方式创造出一股令人愉快的能量，这些能量其实来自于那些想做正确的事情的人。这带来了思想开放、学习加速和理解加深的景象。真的很棒！然后呢，这些精力充沛的人以精力充沛的方式撞上了组织的壁垒。砰！在没有来自高层的支持的情况下去改变组织结构和政策，热心的人逐渐失去了原有的精力，对眼前的障碍和僵化感到沮丧。许多人最终放弃了希望，或者因为希望破灭而感到痛苦。这也让我们感到难过。
自上而下和自下而上——成功的LeSS采用既需要人们做正确事情的精力，也需要那些有组织权力的人的支持。管理者的心态必须是支持，而不是控制。他们需要确保适当的支持结构及时到位，使基层的能量蓬勃发展，不断扩大。
我们经常听到希望得到管理者支持的心声。但要小心自己希望的究竟是什么！
❑没有管理层支持往往会导致受害者行为。“没有经理的支持，我们什么都做不了。”
❑有了管理层支持则可能导致更糟糕的情况。“我们必须做LeSS，因为我们的经理是这么说的。”这种不动脑筋的服从会破坏LeSS的采用。
需要什么样的管理层支持？
所需要的管理层支持，来自于那些有组织权力并能在团队中进行结构变革的人，通常是产品组的负责人。这种支持必须是……真正的支持。
真正的支持始于自我教育。产品团队中的所有经理都需要花些时间学习LeSS，对自己进行自我LeSS教育。这包括参加几天的入门培训和读几本相关的图书。除了教育之外，管理人员还需要就以下方面与团队进行明确的沟通，并采取明确的行动：（1）LeSS采用的意图；（2）结构变革的承诺；（3）提供教育和辅导。
不需要什么样的管理层支持？
监督多个产品开发的高级经理，他们的支持往往适得其反。为什么这么说呢？他们会忽略实际问题——因为他们没有充分参与实际开发。他们的支持通常就是做出一些“优化”和“协调”的决定，这些决定从他们高级职位的角度来看似乎很有意义，但实际上很少能为真正创造价值的现场（gemba）带来真正的好处。结果是，为了应对这些用心良苦的决定，团队处理实际问题的精力被不断消耗。
团队也不需要获得这些管理人员在管理方面的支持，因为管理人员们还没有深入了解LeSS及其产生的影响。我们经常被要求在一个小时的演讲中概述一个为期3天的深度培训，因为这些经理“太忙”了，他们没有时间参加为期3天的课程。到目前为止，我们还无法将需要3天时间来理解的内容压缩为1小时的演讲。好吧，是我们不对。
使用志愿服务
如何组建新团队？谁会加入社区？这些问题，以及更多的问题该如何回答呢？
使用志愿者！真正的志愿服务是一种激起人们身心参与的强大方式。如果它没有得到充分利用，则可能是因为管理人员觉得他们会失去控制。但是对于那些自愿的团队来说，志愿服务就是力量的象征。
志愿服务始于教育。假设只是要求志愿者做一个混合结对试验，这可能不会得到很多人的支持，即便有人回应，这些人在最好的情况下也是感到困惑的。但是如果首先解释混合结对是一种使用频繁结对和交换的方式来增加学习结对编程技术的机会，那么效果就会不同，就会有越来越多且越来越优秀的志愿者加入。因此，首先提供足够的教育和讨论，让其他人了解他们做志愿服务的目的。
以下是志愿服务工作的一些例子：
初期产品志愿服务——哪个产品组将采用LeSS，并且可能包含所有的组织设计变革？游说高级研发和产品经理，要求成立一个志愿者小组。
初始团队志愿服务——假设初期产品组的LeSS采用已经很成熟，并且有大约50人。但产品组之外可能有人真的对加入感兴趣，而且里面也有人想离开！那么，在“翻转整个团队”之前，请再次使用志愿服务方式，即向整个公司发出邀请，邀请大家志愿加入（解释是什么和为什么）。然后请原小组的成员离开。因而，最初的人员将更容易接受学习和承担责任。他们很可能会使初期团队取得成功，因为他们不再只是被计数的人头，他们的心已在里面。
团队组建志愿服务——LeSS中，如何组建团队呢？LeSS支持“自我设计团队”。这个过程是在一个所有未来团队成员都参加的研讨会上完成的。主持人首先介绍产品和研讨会的目标。然后，他们按照之前商定的所有约束条件一起定义典型的团队模板（主持人已经有建好的模板，但最好是让小组自己来明白这一点）。示例模板如下：
❑每个团队都位于同一地点。
❑每个团队都是跨职能的，因此他们可以做到“完成”。
❑每个团队对若干个组件都有深入的了解。
❑每个团队都约有7人。
模板定义过程中讨论并列出了“跨功能”和“跨组件”的详细信息。接下来，开放空间，并留出一段不长的时间（例如15分钟），供人们以模板为导向，以志愿的方式组建新的团队。然后，他们对照模板检查新生团队。如果不够好，小组将继续进行多个回合来讨论，直到组建完成；通常需要2到4个回合。
3.1.3 指南：启动
三个采用原则意味着LeSS采用在一个产品组中的启动。怎样才能增加它成功的可能性呢？
1．教育每个人
2．定义“产品”
3．定义“完成”
4．拥有结构合理的团队
5．只有产品负责人为团队提供工作
6．让项目经理远离团队
1． 教育每个人
我们所看到的最好的LeSS采用是首先让每个人参与几天的Scrum和LeSS培训。随后提供团队、组织以及技术性的指导。
这并不意味我们在兜售Certif ied LeSS Practitioner（LeSS认证师）课程，尽管我们并不介意这么做。任何优秀的教育方式都可以使用；关键在于，如果没有教育，即便使用志愿服务原则，也不会有很多志愿人员加入。
教大家为什么——除了教大家了解什么是LeSS和如何采用LeSS外，更为重要的是要帮助大家理解其中的缘由，即为什么。毕竟在不了解原因的情况下，盲目遵守流程的情况已经太多了。
伟大的培训师和伟大的教练不仅会关注为什么，还会使LeSS的采用更为独到和精彩。那么如何选择这些人呢？使用以下准则：
❑拥有实践经验：不论是内部的团队成员还是外面的教练，都需要有LeSS实践经验。
避免找那些从不关心由谁来教的培训服务机构，避免选那些只懂理论知识的培训者，他们没用。
❑评估个人，而不是公司：要选的是独一无二的人。伟大的教练是个体，找到教练并建立长期的关系。避开大型咨询公司和培训公司。
❑需要有技术深度和理解能力：LeSS需要卓越的技术。技术、团队和组织决策密切相关，教练需要有这种广阔而深刻的视角。避免选择没有技术专长或技术专长有限的人，他们通常是前PMI项目经理。
❑期待长期合作：LeSS的采用需要耐心和时间。找一位能够承诺多年一直致力于帮助组织完成采用工作的教练。避免找那种“开车经过”式的教练，他们只是过来、评论、批评和离去。
❑关注质量而不是成本：雇佣便宜但糟糕的教练（忽略前面的因素）确实是一件花小钱犯大傻的事情。有缺陷和失败的LeSS采用肯定是会出现的；这时糟糕的教练帮不了什么忙。
❑不要委托选择权：这个决策太重要了，不能把选择权送给那些不会直接参与其中的人。避免将选择权委托给某一个部门，如PMO（项目管理办公室）、采购部门或人力资源部门，因为他们参与项目的程度远远不够，无法看到一些重要的因素。
❑不看重认证：大多数资格认证和课程认证几乎毫无意义。认证可能没有什么坏处，
但仅仅认可认证是不可靠的。以上各点更为重要。
❑评估多人：小组最好在做出决定和长期关系投资之前，对多个人进行评估。
2． 定义“产品”
产品定义决定了采用的范围、产品待办事项列表的内容以及谁是合适的产品负责人。广泛的产品定义益处更多，但实际的定义必须足够实用，才能开始使用。
创建产品定义包括：
❑通过扩展问题来扩展产品定义，例如，“客户认为我们的产品是什么？”
❑通过限制问题来限制产品定义，例如，“在我们当前的组织结构中，哪些是实用的？”❑为扩展产品定义探索一些改进方法。
本书第7章将详细介绍为什么广泛的定义更好，以及如何创建产品定义。
3． 定义“完成”
要制定出更好、更强的完成定义（DoD或“完成”），需要团队内部拥有较广的技能面。例如，如果DoD中包括性能测试，那么团队就需要获得该项技能。它可以通过学习获得，但通常的做法是，将具有性能测试技能的人员从其所在的专门性能测试组转移给团队。另一方面，如果性能测试不在DoD的范畴之中，那么单独的性能测试组可以继续保持其原来的工作方式，直到DoD定义的范围扩大。因此……
更好和更强而不是更糟和更弱的完成定义会导致更多的组织变革（例如消除团体、角色、职位，……）。
弱DoD会造成额外风险和延迟！我们将在第10章中进一步探讨所有相关主题。
对组织变革程度的影响使DoD成为采用LeSS的一个关键管理工具。管理者需要在强大的DoD（导致更多的组织变革、更少的延迟和风险）和弱小的DoD（导致更少的组织变革、更大的风险和延迟）之间进行权衡。关键问题是，“我的组织此时有能力处理多大程度的变革？”
4． 拥有结构合理的团队
每个团队都有共同的责任去实现他们共同的目标。为了支持团队的成功，需要确保每个团队都有适当的结构。对初始团队的要求是：
❑敬业——每个人都是一个而且只是一个团队的成员之一。
❑稳定——团队成员不应频繁更换。
❑长期存在——团队不是临时项目团队，而是能多年在一起工作的团队。
❑跨职能——团队具备完成产品功能开发所需的职能性技能。
❑同一地点——团队位于同一个地点，通常实际上是围着同一张大桌子坐。通过面对面的交流，信任度得以提高；通过相互教学，学习得以加强。
本书第4章将详细介绍每个团队的属性。
这种新结构意味着人们离开他们所在的职能部门，永久加入新的跨职能团队。专门的职能部门则应予以撤销。
为什么不建议继续保持向职能部门经理汇报这样的关系呢？因为这样做会导致忠诚度冲突，破坏团队的共同责任感和凝聚力。“这是不是夸大其词？我们公司就是这样运作的。”我们已经见过很多组织这样做了，但都没有成功，所以不要这样做。相反，所有团队的成员应只汇报给同一经理，而经理有明确的责任，就是为团队的成功营造良好环境。
5． 只有产品负责人为团队提供工作
经常有这种感觉吗？……一整天都在工作，忙、忙、忙，到底完成了哪些工作？这是情景切换的吸血鬼，在吮吸着人的生命。不见成效、漫无目的、消极失意。
初始团队肩负着艰巨的任务：既要专注于产品开发的共同目标，又要解决开发环境中的一大堆障碍。障碍（较差的测试自动化程度、工具、策略等）是通过在一个跨职能团队中短时间内“完成”工作而被揭示出来的。
这些开拓者正在为未来的团队打基础，他们需要集中注意力，这一点非常重要。可为什么会做不到呢？是因为那些貌似意图良好、合情合理的中断，以及来自直线经理、销售、首席执行官和人力资源等的额外工作要求。别让这种事发生！
要防止这种情况的发生就需要确保产品负责人作为唯一人员为团队提供工作（参见第8章）。这不仅能支持团队集中注意力，而且还能帮助团队减轻因为要竞争工作而产生的压力。确定优先级是产品负责人的问题，而不是团队的问题。
6． 让项目经理远离团队
对于有经验的LeSS组织，产品组中的项目经理角色不复存在。不再需要该角色的原因是项目管理的责任已由产品负责人和团队来共同分担。
大多数LeSS采用可以立即消除项目经理的角色。在一些罕见的采用案例中，这个角色仍然需要，但只是暂时的。这通常发生在产品的完成定义或跨产品边界的协调能力还处于薄弱或不完善的时候。在这些情况下，组织可能不会立即放弃项目经理的角色。
所以有时候项目经理的角色还会存在一段时间。但带来的问题是什么呢？他们很可能会经常打断别人的话，引入相互冲突的优先事项。所以，虽然暂时有项目经理的角色，但不允许项目经理打断团队、协调团队或为团队分配工作。
本质上，此建议与“只有产品负责人为团队提供工作”相同，并且也适用于其他管理角色。我们已经讨论过，明确这一点非常重要（参见第5章）。
并且……将所有项目经理重新命名为Scrum Master也是行不通的。
下一步做什么？
本节指南认为要把正确的组织结构作为启动点。下一步是确定产品待办事项列表，这可以通过初始产品待办事项列表梳理的有关活动来进行；有关这方面的指南，请参阅第11章。
3.1.4 指南：文化跟随结构
文化跟随结构实际上是“拉尔曼组织行为法则”的第四条。组织中的人员善于表示对改进的支持而实际上不做任何事情。我们已多次观察到这一点。为什么会这样呢？
克雷格在他的职业生涯中有长期的开发经历，从1979年的APL编程开始，发展到帮助大型产品组织采用现代管理实践。在啤酒喝多了的时候，他往往会提到退休，并且最近他发现没有什么法则是以他的名字命名的，这使他感到不快。于是他决定创立“拉尔曼组织行为法则”，提醒人们注意困扰许多组织的、自私的机能失调行为。
拉尔曼组织行为法则：
1．组织会被隐式优化，以避免改变目前的中层经理、一线经理以及专家的职位和权力结构。
2．作为1的必然结果，变革举措将被减少到只重新定义或过度定义新术语，使其与现状基本相同。
3．作为1的必然结果，任何变革举措都将被嘲笑为“纯粹主义”“理论化”“革命化”和“需要针对本地问题进行实用化定制”——这偏离了加强薄弱环节和解决管理人员/专家现状问题的方向。
4．文化跟随结构。
大家一定会想到，反向（即结构跟随文化）也是事实（尤其是在初创企业）。但这仅仅是简练而富有诗意的短语，不要按字面意思去理解。
那么文化跟随结构是什么意思呢？只要组织结构的要素——团体、角色、层级和策略，或者更广泛地说，组织系统/设计不变，行为和心态就不会改变。系统思维的思想领袖约翰·塞登这样解释“文化跟随结构”：
试图改变一个组织的文化是愚蠢的，它总是以失败告终。人的行为（文化）是制度的产物；当制度改变时，人们的行为才会随之而变。
我们观察到许多组织试图采取LeSS，但拒绝对其组织结构、角色和策略做相应的变革。所有这些都会导致LeSS采用的全部好处无法兑现。
问题的一部分是个人的工作安全。人们不想因为结构变革而失去工作。这就是为什么LeSS采用强调精益思想中的工作安全原则，而不是角色安全原则。
3.1.5 指南：工作安全，而不是角色安全
当一个人的工作依赖于不用理解某件事时，则很难让他理解它。
——厄普顿·辛克莱
当改进的结果可能是失业时，谁会为持续改进而努力？没人。在LeSS采用过程中，当制定一项政策时，确保没有人会因执行该政策而失去工作是至关重要的。至少不是由于LeSS采用所产生的结构改变而导致职位或角色消失。请在组织内清楚且反复地传达这个意思。
被解散的职能部门的员工可以加入LeSS团队。职能部门的前管理人员也可以，因为他们通常都能在实际中熟练地从事创造价值的工作。组织必须积极帮助每个人在新的结构中找到新的角色（有关管理变革，请参见第5章）。
3.1.6 指南：组织的完美愿景
组织是极其复杂的系统，在这种系统中没有人能控制一切或知道一切。
每个人都在不断地做出各种小决定，组织行为就是从这些决定中产生的。人们做决定时根据的是他们的经验、目标、原则和价值观。当决定不一致时，各种有明确目标的人就会朝不同的方向匆忙前进，造成组织死局或僵局。当这些决定协调一致时，便能释放出能量，让事情向前推进并不断改善。
在做改进时尤其如此。我们已经看到过大量愿望良好的改进，但带来的只是额外的官僚主义和更多的痛苦。什么时候对改进进行改进呢？显然，它必须是系统全局的改进，而不是局部优化。但怎么知道呢？以下两个问题将有助于把大多数真正的系统改进与局部优化区分开：
❑改进是否会让我们更接近组织的完美愿景？
❑改进是否是对现场或实际工作场所的改进？
关于“现场”，本书将在第5章中做详细介绍。该章中的相关指南将重点介绍组织的完美愿景。那么首先，什么是完美愿景？
经典的精益完美愿景是丰田的准时制（just-in-time system）——每一次当客户购买一辆车时，就会刚好生产出一辆车。这种完美的愿景产生了理想的“单件流”（one-piece f low）流程，在这种流程中，生产系统被设置为处理小批量工作，理想的批量大小为1。其实这一理想可能永远不会实现，但几十年来，它一直指导着丰田不断改进其生产系统。
以下是我们使用LeSS时的完美愿景：
创建能够随时交付或随时改变方向而无须额外成本的组织。
完美愿景与愿景不同。愿景的目标是实现它，而完美愿景的目标是引导改进。当愿景实现时，人们会庆祝，但当完美愿景实现时，人们会感到悲伤，因为它恰好变得不再有用。
与我们合作过的成功产品团体都有组织的完美愿景——这是一个无法实现的关于产品团体将成为什么和如何运作的目标。那么他们的完美远景是如何使用的呢？人们会根据决策是否更接近完美愿景来讨论和评估形形色色的决策。
讨论是一项重要的工作，但往往会话不投机。所以人们想通过白纸黑字地写下一个愿景来帮助每个人理解愿景，至少在字面上的理解保持一致。例如，以下是客户在其产品组中采用巨型LeSS框架时所建立的原则的早期版本：
1．完美的目标是始终拥有可发布的产品。发布稳定版本的周期需要缩短并最终消除。
2．位于同地点的、自管理的、跨职能的Scrum团队是基本的组织单元。责任和问责是在团队一级。
3．大多数团队被组织为以客户为中心的特性团队。
4．产品管理层通过产品负责人角色来指导开发。对产品发布的承诺不会强制在团队一级执行。
5．直线组织是跨职能的。职能型专门化直线组织逐步融入跨职能的直线组织。
6．避免特殊的协调角色（如项目经理），要由团队来负责协调。
7．管理层的主要责任是改进——提高团队的学习能力、开发效率和开发质量。团队的工作内容总是来自产品负责人。
8．不设开发分支，不在版本控制系统中反映产品变体。
9．除了探索性测试、易用性测试和需要移动物体的测试之外，所有测试都需要自动化。所有人都必须学习测试自动化技能。
10．新方法的采用是循序渐进的。每一项决策都需要考虑到上述原则。
当然，这只是一个例子，不过请随意使用它作为讨论组织完美愿景的起点。
管理者们——连同整个产品团队——必须建立这种组织完美愿景来指导决策的制定和实施。通常，通过非正式讨论和研讨会可以产生一些指导性的完美愿景和原则。可以用以下两种方式来想象这种完美愿景：（1）想象自己到了工作岗位，完美的组织是如何运作的；（2）想象完美的产品，然后想象组织正在创造这个完美的产品。
3.1.7 指南：持续改进
只有达到完美和能够控制一切的程度，LeSS采用才算结束。做不到这一点，就总有事情需要做改进。
经理的工作是打造一个供团队持续交付和持续改进的环境。最好是他们自己的团队做最多的改进，但经理和Scrum Master也要经常参与组织层面和环境层面的改进（参见第5章）。
提示
❑集中注意力！
因为每个人都忙于思考新的改进主意，结果没有做任何改进，这是持续改进的最大失败。“还是再评估一下目前的状况吧。”“嘿，这两种方法一样，不知道为什么？”或者，另一种流行的说法，“让我们采用NooDLeS吧，LeSS在这里行不通”（其实从来没有真正尝试过LeSS）。
出路呢？停止评估，开始行动！始终记住排在最前的两项改进事项，并将精力集中放在它们身上。如果改进没有完成，团队就会很快失去兴趣，不再考虑新的改进。
❑利用回顾会议发现改进点。
发掘新改进的首选场所是团队回顾会议和全体回顾会议（参见第14章）。
❑专注于真正的改进。
并非所有的改进都是真正的改进。有些只是局部优化——不能改进整个系统，而只能从一个角度改进。两种常见的局部优化是：（1）职能局部优化；（2）基于假设且不受质疑的局部优化。职能局部优化是职能专门化方面的改进，从系统输出的角度来看，这种改进通常是有害的。例如，“在每个Sprint测试方面有一种障碍：应该在系统开发完成后开始测试，这样测试才更有效。”基于假设且不受质疑的局部优化是指基于对“事情的工作方式”的假设而进行改进，但假设可能是错误的。大系统的改进往往需要挑战各种假设或已有观点；但对局部改进却很少能产生影响。体现这种观点的例子有：“必须在测试之前完成编程”和“如果每个人只专注于一项技能，做事就会更有效”。
局部优化的改进建议对学习和扩展视角可能是有价值的。在这些建议被提出时，请与建议发起人或团队一起分析它们。这样的讨论有助于拓宽改进的角度，为进一步改进奠定基础。
❑避免设立质量、流程、转型或改进人员。
大型组织通常为质量和流程部门配备有六西格玛黑带，负责运行改进工程。甚至更近一步，有些组织还设有专门的转型部门。要避免这么做！我们需要的是每个人都必须随时随地不断改进。用一个部门专门负责改进是消灭改进和消灭团队参与度的最强方法。相反，要使用现有的直接组织结构来支持采用和改进。
❑避免改进团队；使用常规团队。
与上一个提示有关。组织普遍会专门创建一些改进团队，并向他们分派任务，实现改进条目。而更好的选择应该是让常规团队来处理改进条目。这可以与常规的工作条目一起进行，也可以只在某几个Sprint中专门实现要改进的条目。这样做的优势在于常规团队可能是他们自己所做改进的未来用户，因此他们会把改进项实现得更加易用和更加有用。
❑避免设立改进项目；使用产品待办事项列表。
此外，组织通常认为所有的改进都必须通过“项目”来进行。项目被单独管理，要么配备以改进团队（见上一点内容），要么更糟糕，削减常规团队人员，增加改进团队人员。后者会导致组织对“资源”的争夺和团队焦点的不足，并打破团队的共同责任。正确的做法应是，让常规团队参与进来，把要改进的事项加入到产品待办事项列表中。这样，所有的工作都可以在产品待办事项列表上可见，把持续改进变成了一种正常的制度（参见第9章）。
持续改进失败的最常见原因是无法进行实际的改进。这会导致团队的沮丧，丧失对经理的信任。当这种情况发生时，经理需要停下来反省一下，问问自己：“作为经理，我们应该提供什么样的服务？”
3.1.8 指南：扩大采用范围
第一个LeSS采用大功告成！接下来做什么呢？我们达到完美和掌控一切的标准了吗？如果没有，请做以下几件事：
❑把采用扩大到多个产品，保持相同的支持环境。
扩大是一定的，但要扩大到多少个产品呢？也许是两个产品而不只是一个，但不可太多。关键的限制是每个产品在采用LeSS时，能够为其带来多少相应的人员、资源和关注度，并保持支持力度不变，甚至提高。我们看到的一个共同问题是，第一次采用所给予的关注度在扩展采用时往往变得不再那么集中，并且还缺乏活力。需要阻止这种情况的发生！每个新产品都需要相同的支持环境和关注。
❑强化完成定义。
“完成定义”不太可能完美无缺。通过增加团队的跨职能能力来强化完成的定义；发现新障碍，努力去逾越（参见第10章）。
❑扩展产品定义。
初期产品定义往往受到组织结构的限制。尝试扩大这一定义的范围，以获得更好的优先级、更多的客户关注和更简化的组织（参见第7章）。
❑提高团队的产出，并分享经验。
初始团队的产出不太可能那么美妙。但是他们发现了环境和开发实践中的局限。许多东西需要学习，许多地方需要改进，许多限制仍然存在。努力解决这些问题，那么团队的产出就能得到相应的提高。请务必向所有团队以及其他产品团体分享这些问题的解决方案。
❑改进支持工作。
对初始团队支持的有效性如何？从团队中获取反馈并使用它来改进支持工作（教学、指导、组织变革等），以供今后采用LeSS的产品团体使用。
❑利用自下而上的能量。
初始团队在第一个产品中采用LeSS的积极成效可能会激励其他产品组中的团队在未经高级经理批准的情况下采用LeSS。与其扼杀它，不如让它自己发展并支持它。请充分利用这种自下而上的能量。
3.2 巨型LeSS
规模进一步扩展时，另一个问题是：
一次全部完成结构变革难度过大——在一个庞大的产品团体中，很难一次做出巨大的结构变革。困难的原因不仅仅是人数多和思想繁杂，还因为：
❑组织对一大群客户都有在特定日期前交付新功能的承诺，这使得大规模的变革面临风险；
❑组织政治会使变革发展成为人们的“职业限制”；
❑这么大的规模无法保证足够的教育和辅导。
因此，巨型LeSS的采用需要以一种更加演进式的方式来完成。
3.2.1 巨型LeSS规则
巨型LeSS的采用，包括组织结构的改变，应采用演进增量的方式进行。
每一天都要记得：巨型LeSS的采用需要几个月或几年的时间，需要有不尽的耐心和充足的幽默感来支撑。
3.2.2 指南：逐步增量式采用
LeSS采用最好一次全部完成，但巨型LeSS采用必须循序渐进地增量式完成。巨型LeSS的采用有两种方法可循：
❑在整个产品组中渐进增量式地采用。
所有团队都在以相同的步调逐步提高自己的采用规模和能力。这可以通过扩展产品级完成定义和使用特性团队采用路线图等工具来实现（参见4.1.4节）。
❑在产品组的某一部分专注而深入地采用。
改进专注于首先让几个团队变得真正优秀，然后把他们逐个分散开。深度采用可以通过扩展某几个团队的完成定义，让他们实现特定的改进事项，并通过集中指导来进行。
这两种方法都有效。迫不及待的渐进式采用有一定的优势，有希望在产品范围内快速获得成效，尽管这种情况通常不会发生，因为所有团队必须同时解决一些相同的问题——结果又导致新的问题。专注而深入地采用看起来缓慢一些，但它可以避免让所有团队都经历痛苦。当然，缺点是依然存在的痛苦仍无法解决，因为这些痛点（还）不是采用的关注点。
LeSS采用原则更倾向专注而深入的采用，这一点在此做了讨论。第4章将介绍逐步增量式采用方法。
3.2.3 指南：一次一个需求领域
启动巨型LeSS采用最简单的增量式步骤是在一个需求领域内采用LeSS框架。这里的重点在于，LeSS采用首先要放在效益高和风险低的需求领域，或者至少是风险低的需求领域。
这意味着一次只创建一个新的需求领域。
现在事情变得有点棘手了：这个新创建的（也许只有一个）需求领域仍然是产品的一部分，因而它和庞大的“旧组织”之间仍将存在依赖关系。困难的地方在于，在破坏“旧组织”以支持这个年轻的需求领域和坚持遵循现组织接口之间如何寻求平衡。
最后的选择是战斗。“旧组织”中有一条规则必须瓦解，即放弃个人/团队代码的拥有权；否则，年轻的需求领域就没有机会了。
3.2.4 指南：并行组织
前面的指南是一个比较通用的技术实例，说明了在不做任何改变的情况下如何进行组织结构变革，即构建并行组织。这意味着现有的组织保存不变，并从几个特性团队或一个需求领域开始，逐步建立并行的新的组织。这种方式对于特性团队很合适，因为他们没有实质上的依赖关系。一旦第一个团队工作良好，就可以逐渐将团队从传统组织中转移出来。当动力足够时，便可以把旧的组织合并成新的组织。
注意事项：
❑并行组织不是试点组织，并行的结果之一是组织的报告线必须与传统组织分开。
❑不要让并行组织建立代码库分支，因为这会导致令人痛苦的代码合并开销。它们是独立的组织，但要使用相同的产品和相同的代码库。
❑要非常清楚地告知团队，每个人最终都将进入新的组织。这个信息很重要，这样旧组织中的人就不会专注于无谓的竞争了。