我们想要向宝马集团致谢，感谢他们给我们机会去学习、成长，并分析一个在高度竞争且挑战的环境中极有吸引力的LeSS巨型案例。我们也想感谢所有参与到这个宝马集团的旅程中的LeSS培训师和教练们。
我们真诚感谢我们的导师Mark Bregenzer和Viktor Grgic, 他们从最一开始就陪伴着我们。而且我们要特别的感谢Viktor Grgic，因为他对于经验报告的反馈和改写以及随时随地的讨论。
Craig Larman，感谢你在不停的改写和辅导我们时的无限耐心。Bas Vodde，感谢你的支持和不停的回答我们的问题，以及一路的支持。
还要非常感谢我们的同事和朋友的支持！而且，最重要的是，感谢我们的家人，是他们在这段旅程中给了我们无尽的精神上的支持。
对于我们来说这是一场持续的、深入的且变革性的学习经历。
宝马集团决定经历一场重要的变革，为了组织能够交付最高的客户价值、比竞争对手更快的学习速度，以及创建一个容易适应的组织以确保前两个目标的实现。目前依然是在旅程中。
本篇报告是关于在宝马集团ADD（Automated and Autonomous Driving Department/自动驾驶部门）深入实践探索LeSS导入。它包括了从2016年年中到2019年10月的实践，目前LeSS导入仍旧在进行中。
本报告的作者是Konstantin Ribel和Michael Mai。由于法律原因，涉及到的人并没有使用真实姓名。
报告基于变革的多个视角组织如下：
- 时间线视角
- 技术视角
你可以从任何喜欢的视角开始！
在宝马集团作为汽车设计师和制造商的旅程中，其致力于通过L3级AD（Autonomous Driving/自动驾驶) 提供更多安全性、舒适性、灵活性和质量（见图1）。在通往AD的道路上要克服许多挑战，也许最重要的是AD固有的复杂性。
为了创造像AD这样复杂和软件密集型的系统，宝马集团必须从一家拥有100年历史的机械工程和制造技术公司转变为一家软件公司，并将AD视为一项复杂的软件研发计划。这听起来像是一场革命和范式转变。的确就是这样！
作为早期的一步，宝马集团召集了所有参与AD的人员，并将他们集中在一个地点 - 宝马自动驾驶园区。为什么？因为他们预计，如果涉及多个地点，成功解决如此困难的问题 - 结合范式转变 - 将更加困难。
然后，宝马集团做了一件出乎意料的事情：他们深入改变了传统的组织设计，转向一种为大团队更容易学习和适应来优化的组织设计。为此，他们从LeSS中获得了灵感。
到目前为止，这个旅程充满了失败和痛苦，但也充满了积极的影响，例如部门之间的协作更加紧密，减少了库存和团队之间的交接。对团队自管理的更高关注和频繁的回顾，导致团队设计和拥有他们自己的流程。对技术卓越性的高度重视导致了更好的软件设计、更简洁的代码和更具适应性的技术堆栈。
三个代词我、我们和他们在时间线视角中提供了不同的角度。先从作者的个人经历开始 - 我和我们。然后过渡到他们，对许多情况呈现外部观点，提供更客观的观察，然后再是根因分析和建议措施。
在2015年成功推出新车后，我（Konstantin Ribel）正在寻找新的挑战。当时，高度自动驾驶项目刚刚开始。我在2016年初加入了这个项目。
我的主要任务之一是创建一个高效的工作模式来开发我们复杂的AD开放平台，该平台涉及宝马集团、合作伙伴和供应商。对于一个标准复杂度的ADAS（Advanced Driver-Assistance Systems/高级驾驶辅助系统）的ECU（Electronic Control Unit/电子控制单元），我们通常用一个团队对接一个供应商来开发它。对于AD开放平台及其多处理器硬件设计，我们估计复杂度要高5-10倍，需要多个供应商和合作伙伴。我们进一步发现，如果我们以线性方式扩大规模，仅是用于供应商的项目管理接口，我们可能就需要增加10-15倍的人员（参见图2）。我意识到必须改变一些东西来改进。
在寻找解决方案时，我阅读了几本Scrum和敏捷开发书籍。然后我被推荐与敏捷教练和LeSS培训师Mark Bregenzer交谈。我遇到了Mark并解释了我们的情况。他的回答是：“你需要的人比你想象的要少得多。你需要改变组织结构。” 会议结束后，Mark建议我参加Craig Larman的CLP（Certified LeSS Practitioner/认证LeSS实践者）课程。
我于2016年6月在柏林参加了CLP课程。在CLP课程的第二天，我意识到我在工作中的所有角色都体现了精益浪费 - “没有增加价值但消耗资源的时刻或行动” [1, 第58页]。谁希望自己的工作是一种浪费？我很沮丧。课程结束后，我意识到我想减少我工作环境中的精益浪费，我确信我的同事也会想要这样。
当我回到办公室时，我试图说服我的LM（Line Manager/直线经理）的上司（“Paul”）应该在我们的部门导入LeSS。最初，我并没有成功。我们对这是否在我们的环境中永远不会工作存在争议。这对我来说是一次非常令人失望的经历。然而，我记得Craig在CLP课程中经常重复以下说法：“[在引入变革时]像政治家一样思考和行动，而不是像工程师一样。” 我意识到我需要采取不同的行动，并停止强推这个话题。
让我们从不同的角度来看这个故事。
2015年9月至2016年3月期间，我们试图为未来的ADAS系统（包括AD）建立一个组织单元。多个部门的主管齐心协力完成了这项任务。2016年4月1日，来自不同组织单元的多个部门为AD与ADAS合并组成了新的部门 - ADD。
在ADD启动后不久，我们发现在现有设置中，除其它问题外，部门、组和角色之间的大量协调开销和交接使我们放慢了速度。 对于具有许多不确定性和未知数的复杂产品（例如AD）来说，这是一个薄弱的起点。为了改善这种情况，ADD执行委员会在2016年6月至2016年12月期间就新的工作模式和组织设置进行了工作。
在此期间，Craig Larman在现场教授我们的开发人员遗留代码的测试驱动开发。我邀请Paul在2016年11月末与Craig会面。他接受了这个提议。Carig和Paul谈了大约二十分钟。见过Craig的人都知道他可以多么坦率和尖锐。在他们交谈时，我不知道让他们互相交谈是否是个好主意。除了其它话题，Criag还向Paul介绍了Larman的组织行为法则，并与他分享了英语谚语“在自己的土地上，你永远不是先知”。谈话越深入，我就越不确定谈话的结果会如何。当Paul和我离开房间时，Paul说：“这是我经历过的最好的推销。” 成功了！Paul成为高管级别里第一个与我志同道合的人。变革的势头开始上升。
在2017年1月份，一个所谓的迁移团队成立了，而我是其中一员。为了代表整个组织体系，这个团队由不同层级的经理和员工组成。这样的团队使我们可以在不同的抽象层次上讨论想法。我们继续完善ADD执行小组前一年提出的工作模式。我们讨论了不同的用例、日常情况，以及如果我们采用这种工作模型它们会是什么样子。我们一直在努力提出改善我们所面临情况的建议。
与此同时，Paul说服ADD高管与Craig Larman一起举办为期四天的研讨会，主题是大规模敏捷开发的系统思考和组织设计，也称为CLE（Certified LeSS Executive/认证LeSS高管）课程。我们想要确保所有高管的参加，但是由于他们的时间安排，该活动不得不在几个月后举行。为了在那之前能动起来，2017年4月，我与Mark Bregenzer组织了一个为期一天的介绍研讨会。
Mark介绍的内容激发了参与者的灵感。很明显，我们需要朝着这个方向前进。这个最初的研讨会创造了下一个重要的转变动力。
在这时，ADD高管确信，要真正改变行为和组织的工作模式，他们需要改变组织结构。
开始阶段的复盘总结
- 像政治家一样思考和行动，而不是像工程师一样
- 在不同的组织层级中获得盟友并对齐共同目标 - 真正的改变只有作为一个群体才有可能，既自上而下又自下而上。LeSS指南：三条导入原则 [3, 第55-59页]
- 培训所有高管和董事，尤其是那些拥有真正决策权的人 [3, 第57页]
- “在自己的土地上，你永远不是先知。” 聘请在敏捷开发的大规模组织设计方面经验丰富的外部专家。这位专家 - 一位出色的培训师和教练 - 将专注于为什么这么做，并将在你的LeSS导入中产生积极影响。有关此主题的更多信息，请参阅《大规模Scrum》[3, 第3页]一书中“教授为什么”的部分 *（LeSS指南：启动）
LeSS导入涉及到大型组织和许多根深蒂固的假设组织应该如何工作的想法。成功导入LeSS需要挑战这些假设并简化组织结构，而这一切也都是伴随着在大团队中存在的政治和“丢脸”。LeSS导入需要每个人都朝着共同目标前进。[3, 第54页]
我们的起点是一个常见的层级结构（见图6）。
ADD从原先部门继承了超过15个不同角色，这些角色定义了接口，用以清晰地描述某人工作的开始和结束。通过这种设置，我们曾经成功地向客户交付了许多优质汽车。然而，它却是精益思考中浪费的沃土，例如交接和协调开销都造成浪费。由于浪费抑制了复杂产品开发 - 尤其是大规模产品开发 - 的适应性，因此我们有强烈的动力去改变。
这一阶段于2017年5月开始，紧跟在与Mark Bregenzer为期一天的介绍研讨会之后。在这一时间点上，针对以下问题的答案都是开放的：
- 我们想怎么工作？
- 我们将采用哪种工作模式？
- 如果它是基于Scrum的，我们会使用哪个规模化框架？
为了回答这些问题，我们需要包括整个组织系统，这就意味着包括来自宝马集团其他部门的所有利益相关者。我们成立了两个团队。现有的迁移团队太大，因此我们将其缩小。第二个团队是高管团队，成员最多为10人，如图7所示。
通过这种设置，我们让高度参与产品开发的人员和具有深远决策权的管理者都参与进来。它使我们能够验证想法并快速做出决定。
此外还有Mark Bregenzer，他挑战我们对组织结构的假设，并就’为什么’辅导我们。我们全职投入在这项工作上。
团队和Mark在发散-合并的周期中工作。迁移团队和高管团队代表探讨了以下问题的答案：我们希望如何工作？在多团队设置中，两个团队就可能的解决方案背后的基本原理进行了辩论。代表们依据解决方案制定了组织设计。然后，整个ADD委员会（C-1和C-2级别）和执行团队评审了两个团队的提案，即“我们想如何工作？”的答案以及对应的组织设计。
两个团队密切合作，以使他们的想法可以快速反馈并且迭代时间较短。
几周后，在两个团队都获得了很多见解之后，组织设计的优化目标变得明显。首先，世界上没有人确切知道如何做可以量产的自动驾驶汽车。因此，学习做什么以及怎么做变得至关重要。这也就要求组织成为一个学习型组织。
其次，更快的反馈循环可以改善学习。由于还没有人制造出（L3级及更高级别的）自动驾驶汽车，因此任何成功的希望都必须是从现实中学习、调整产品待办列表，并处理最高优先级的条目中得来的。这意味着短周期时间、早期集成和在公共道路上行驶的原型车。换句话说，使用反馈循环来学习，然后决定下一步做什么。因此，始终处理新发现的最关键条目的能力需要一个适应性强的组织。
以上这些发现得出了如下优化目标：
- 比竞争对手学得更快的能力
- 基于学习，致力于和交付最高客户价值的能力
- 易于适应的组织，以确保 (1) 和 (2)
有必要消除浪费以实现优化目标。首先，需要减少协调开销。例如，识别具有经验和专业知识的合适人员来进行聚焦的讨论，尤其是排除中层管理人员，以避免个人战术职业游戏干扰这些讨论（通常会增加开销）。
其次，需要清除交接浪费，尤其是在组件团队、单一职能筒仓和个人职责之间。指导目标是：增加职能部门之间的共同责任。
我们详尽分析了在我们的领域中使用LeSS是否可以实现所有这些。对于此分析，我们邀请了不属于迁移和高管团队的人员，他们承担不同的角色，有着不同的用例。我们让这些人挑战LeSS工作模型，并彻底讨论了他们的用例，例如缺陷处理和在安全关键软件和共享公共代码的背景下获得公共道路的驾驶批准。讨论的重点是我们如何用LeSS来实现这些用例。
我们不停寻找没法实现的用例，但最终我们没有找到。
除了LeSS之外，执行团队还有其它关于如何实现结果的方案。只有这一个需要对组织结构进行更改 - 艰难方式。其它的方案只需要改变实践 - 简单方式。高管们已经了解到，仅仅改变实践而不重新组织设计的方式并不会改变任何事情。一些高管称这些尝试只是贴了不同标签的“老调重弹”。
相比之下，LeSS需要对组织结构进行深刻的改变 - 这是一种更难的方式，但更有可能支持我们达到目标。在2017年6月我们决定导入LeSS。
AD由客户需求和法律要求驱动，新技术和无缝连接正在为实现需求铺平道路。技术挑战是巨大的，例如建立数据中心、训练AI算法、虚拟测试和验证、从头开始开发新传感器、将非汽车高性能硬件引入汽车并使其符合汽车使用要求，以及复杂的系统架构等等。
产品定义决定了你的产品待办列表的范围，以及谁会是好的PO（Product Owner/产品负责人）。导入LeSS时，产品定义决定了你可以预期的组织变革程度以及需要参与的人员。[3, 第157页]
客户很可能会认为AD就是一种移动服务，涵盖范围从智能手机应用程序、移动网络、汽车、传感器、算法、执行器、轮胎到道路基础设施。这个清单很长，但这只是从技术视角来看的清单。如果从法律的角度来看，则需要处理保险问题、道路清关、法律变更等。为了满足这个产品定义，则需要多方参与，除了宝马集团，还包括各国政府、保险公司、供应商、服务提供商等等。客户的观点可能是正确的，但同时，没法从这样的规模开始导入LeSS。
有一些因素会限制产品的定义：
- LeSS导入的组织边界；
- 能够参与进来的各方
这两个因素将产品定义限制在以宝马集团为主的具有自动驾驶特性的汽车上。该产品定义需要与宝马集团内的其他部门以及未导入LeSS的供应商合作。
图11概述了宝马集团的组织结构。研发的每个部门都有其专门的高级副总裁。是ADD高级副总裁支持这次LeSS导入，这也自然限制了LeSS导入在ADD的组织范围内。因此，与ADD之外的其他部门和各方的现有接口和工作模型需要保持不变。
大多数产品开发都是按项目组织的 - 每个新产品发布就是一个新项目。组织通过管理项目来管理产品开发…… [1, 第236页]
这句话完美地描述了宝马集团的情况。我们以ACC（Active Cruise Control/主动巡航控制）为例。宝马集团于2000年发布了其第一个版本的ACC。随着每一次发布，ACC获得新的改进，可以处理越来越多的交通情况。通过多个版本的产品增强使其成为产品开发案例。
在继续之前有个术语需要定义一下。
SoP（Start of Production/开始量产)：作为一个重要的里程碑，涉及更新或新的汽车模型的量产将在此版本之后开始。此外，技术栈（硬件和软件）也会被更新。
尽管是长期的产品，但SoP仍以项目来组织。
ADD有两个大项目，SoP2018和SoP2021。为了确保SoP2018的稳定交付，相关人员被排除在LeSS导入之外。他们可以在发布后加入LeSS组织。因此，他们的组织设置基本保持不变。
该决定还将SoP2018产品范围排除在可能的产品定义之外。
因此，LeSS导入的产品定义变成了SoP2021的发布范围，不包括SoP2018。主要是SAE（Society of Automotive Engineers/汽车工程师学会）L2级的ADAS功能和L3级的AD。它涉及传感器、计算硬件和软件的开发。它还需要与没有导入LeSS的ADD以外的部门和供应商合作。
此外，AD应作为单独的ADP（Autonomous Driving Platform/自动驾驶平台）提供给其它汽车主机厂。
LeSS要求小型的、端到端的、自我管理的团队为实现共同目标而进行协调，同时分担实现该目标的责任。我们的起始位置与预期的位置相去甚远（参见认识到组织变革是必要的章节）。此外，我们数十年来形成的思维方式支持单一职能团队、英雄主义、组件团队，并且只有一条需要从技术转向管理的职业通道。我们担心如果不改变奖励制度，人们就不会改变。因此，我们面临这样一个问题：“如果人们合作时，他们个人的情况会变得更糟，他们为什么要合作？” [6]。
它使我们认识到需要创建一种组织设计，以培养一种文化“……在这种文化中，合作变得对个人有利”[6]。你可以在文化跟随结构指南中找到有关此主题的更多信息。
我们遵循LeSS规则“……‘从一开始’就建立完整的LeSS结构”。我们以典型的LeSS巨型组织结构图为指导设计了新的组织结构（参见图12）。
在审视以前的组织结构并应用系统思考改变组织以转向“学习和适应”的目标上，迁移团队和高管团队都发挥了重要作用。
我们担心，随着时间的推移，任何跨职能和基于团队的组织都会不可避免地回归到单一职能团队的旧范式。根深蒂固的宝马文化和结构与理想的文化和结构截然不同，它曾经（并且仍然）是一股强大的力量，再次证实了我们的担忧。我们决定通过立即对结构进行重大改变来解决这个问题（参见图13）。我们采用这种方法来对抗回归旧习惯的趋势。以下段落解释了结构的每个部分。
首先我们完全去除了一个层级，即TL（Team Leader/组长）的角色（C-4级别，参见图14），结果是留下的LM每个人都要负责大约六十名产品开发人员。这随之创造了一些机会来组建跨职能和跨组件的团队。
如何建立特性团队成员与LM的汇报关系（这在宝马集团是必需的）？我们考虑了两种选项。
一个选项是为每位LM安排八个团队（也就是一个需求领域）。
好处？除了局部优化以外我们想不出任何其它的。
缺点？需求领域的概念需要灵活性。它们必须易于设置和解散。将团队从一个需求领域重新分配到另一个需求领域必须方便。选项1会带来一定程度的组织僵化。如果需求领域是一个组织单元，向一位LM报告，那么比如将团队从一个需求领域重新分配到另一个需求领域，或解散需求领域，都将需要正式的组织变更。
当考虑到时间和规模时，此选项的其它缺点：
当接近发布日期时，交付压力会增加。此时，旧的行为模式可能会复活。管理者会肩负起对他团队绩效负责的重担，从而导致指挥-控制的行为模式的复活。在这种情况下，管理者可能会关注团队而不是团队的系统。这随之会导致经理干扰团队和他们的SM（Scrum Master）所关注的方面。
此外，在之前的设置中，未来的LM是C-3级别的单职能经理（例如架构组经理），C-4级别的TL向他们报告。因此，他们很可能倾向于（1）他们最初的单一职能活动和（2）建立一个非正式的TL层（即使TL的官方职位被取消）。他们为什么要这样做，为什么这是一个问题？
首先，请注意升职仍将由经理驱动。在宝马集团攀登职业阶梯需要在某些时候展示管理技能。因此，更多地关注经理的专业（例如架构师）的员工可能会获得更多的青睐，甚至得到经理的非正式支持，以让他们在团队中扮演更积极的“领导”角色。这可能会在一个表面上的自管理团队中创建一个非正式的层级结构，并“……破坏团队的共同责任和凝聚力”。[3, 第63页]
第二个选项的主要目标是在根据需要改变需求领域时具有高度的灵活性。
我们考虑团队中的开发人员有不同的LM（参见图13）。通过这种设置，每个LM将有大约六十名产品开发人员分布在多个团队中。
好处？组织结构高度灵活，无需更改正式组织结构即可轻松更改需求领域。
此外，这种设置预计会迫使LM进行全局优化。怎么做到的呢？此选择使得各个LM对团队的权力趋向均等。这可能会降低管理者利用他们对特定的“我的团队”的权力在本地进行优化的效果。它将创建一个环境，LM们能以一致的行为面对团队。 - “文化遵循结构”模式的积极应用。
缺点？我们没有看到明显的，但的确是有一些悬而未决的问题。以前，组织结构图反映了单一职能组和个性化的职责，这使得为问题找到负责人很容易。由于跨职能团队和分担责任，这些信息在组织结构图中不再可见。保留在传统组织架构中的其他宝马集团部门将如何与ADD进行沟通？
此外，当责任分担并且组织结构与产品架构分离时，如何升级问题以及向谁升级问题？
现有的LeSS指南可以解决这些问题, 例如致力于诸如与相关部门合作之类长期主题的领头羊团队[3, 第308页]。但由于ADD之前没有经历过这些做法，很难想象它们会如何工作。
我们选择让这些问题保持开放，并使用检查和调整来回答它们。
这些优势对我们来说非常重要，因此我们决定从这个设置开始。
谁应该是PO？如根据开发类型来找到PO指南中所述 [3, 第173页]，寻找PO的第一步是了解你的开发类型。
一方面，我们的产品（AD）是更大的产品（汽车）的一部分。从这个意义上说，它就像内部组件开发。另一方面，客户需要额外付费以在汽车配置中添加AD特性。
关键点在于，最初由ADD负责人设定的产品愿景是将AD作为单独的ADP提供给其他汽车主机厂。 从这方面来看，它本身就是一个外部产品。
对于外部产品，LeSS指南谁应该是PO？[3, 第173页]建议在产品管理部门寻找PO，例如产品管理的负责人。此外，该指南定义：
作为PO，你拥有独立的权力来做出重要的业务决策，选择和更改内容、发布日期、优先级、愿景等。当然，PO需要与利益相关者合作，但真正的PO拥有最终决策权。[3, 第175页, 添加了强调]
有几个因素限制了PO的选择。
宝马集团拥有（并且仍然拥有）范围广泛的产品，包括复杂的系统。其中的开发和维护涉及数万人。该公司的结构反映了汽车的子系统，多年来这些子系统的复杂性和分散性逐渐增加，尤其随着每个子系统中软件的重要性日益增加。
因此，任何人都无法的独立的制定或改变重要的商业决策，即使是CEO也不成。相反，所有重要的商业决策都是在委员会中共同做出的。由此，我们知道未来的PO的独立决策权会受到一定的限制。
从ADD中选择PO有两个理由：(1) 向其他汽车主机厂提供ADP的愿景；(2) 正在ADD导入LeSS，而不是在整个宝马集团范围内导入。
先前存在的部门负责人已经负责所有ADAS和AD客户产品；他还掌握了开发它们的预算并有权决定如何使用它。在独立决策权的意义上，他不拥有最终的决策权，但的确拥有很多权力。当然，他需要与利益相关者保持一致，并在做出决策时考虑整个宝马集团的产品系列。因此，这个人成为了PO。APO则是从ADD的不同部分招募的。
不幸的是，正如稍后将探讨的那样，“很多”权限不足以建立一个结构合理且优先排序的产品待办列表。
无论怎样，PO和APO组成了PO团队。
软件是由人创造的。改进人就改进了产品。[3, 第111页]
坚持不懈的培训和辅导对于在任何方面达到精通以改进产品都是必要的。为了践行这个观点，我们创建了一个能力和教练部门，如LeSS巨型组织结构指南[3, 第111页]所描述的。它由SM、技术教练和与流程相关的员工（例如行业标准化专家）组成。
为什么SM在这个部门？SM的职责是教授Scrum（和LeSS）以及如何利用它获得价值，指导团队、PO/APO、LM以及应用它的整个组织，最后也是同样重要的一点是，充当一面镜子。这种教练，尤其是在充当镜子时，要求每个人都与SM处于同一角度去思考。当个人以前的职业道路和等级会影响不同角色和他们层级的看法时，这一点就更加重要了。
宝马集团的典型情况是，工资级别越高，这个人在层级中的地位也越高。级别通常取决于经验和展示的技能。大多数SM的级别低于APO和LM。这导致了两个问题：
- SM在指导时将如何看待和接触更高级别的APO和LM？
- APO和LM如何看待“经验不足”（基于他们的级别）的SM？
让我们也将IPA（Individual Performance Appraisal/个人绩效考评）添加到教练的角度。一个人的LM进行年度IPA，这会影响到一个人的级别和工资。此外，LM决定他们使用哪些数据进行绩效考评。
考虑以下假设情况。假设几个团队和他们的SM有相同的LM。SM观察到LM的行为助长了自我管理的反模式。SM会做什么？
- SM是会不偏不倚地充当LM的一面镜子，并让这种行为变得透明，冒着伤害自尊和冒着负面IPA的风险。或者？……
- SM会接受这种行为，或者为了自己更好的IPA结果而支持这种行为？
在讨论新的流程和组织结构，尤其是能力和教练部门时，我们推断大多数SM会有偏见，会选择第二个选项。但我们想创造一个环境，让SM尽可能可以做到无所畏惧和不偏不倚。
此外，考虑到上述情况，宝马集团的员工不习惯在没有事先咨询LM的情况下直接与高层管理人员交谈。因此，高层管理人员有从SM那里获得过滤信息而不是真实情况的风险，这被认为是有害的。
为了解决这些问题并创造一个让SM可以尽可能自由地开展工作的环境，我们明确希望SM拥有与团队成员不同的LM。这个决定导致我们将SM安排在能力和教练部门。
最终产生的组织结构如图15所示。
ADD内有三个主要部门。PO、APO及其支持人员组成了PO部门。所有产品开发人员和LM都在开发部门。能力和教练部门包含所有SM、技术教练和其他行业标准化专家。
这三个部门共同输送组成了需求领域：来自PO部门的APO、来自开发部门的团队以及来自能力和教练部门的SM。
三条导入原则中的第一条[3, 第55页] - 深而窄优于广而浅 - 意思是LeSS最好应该优先在单个产品组中深入地导入，而不是在许多组中粗浅地应用LeSS。在LeSS巨型的情况下，其导入应该从一个需求领域开始，达到良好的状态后，再进一步扩展。
这是一个LeSS巨型的案例，ADD遵循了上述原则，LeSS的导入从一个需求领域开始。
图16展示了需求领域范围随LeSS导入的进展而变化的可视图。X轴代表团队的跨职能程度。它显示了跨职能的难度水平。右侧的活动并不是由左侧的活动组成的。在快速原型平台上开发并在汽车上测试比在目标平台和汽车上集成并测试相同的软件要简单。将范围扩大到多个ECU会增加一个团队必须面对的复杂度和难度。扩展到共同创造移动服务意味着团队需要工作在整个系统上，至少在今天，这是不现实的。
Y轴显示的是产品范围，从单一组件到某个客户问题。
起点是在快速原型平台上开发组件（图16中的第1步），离完整的产品范围还很远。
第一个需求领域的关注点需要包括演进到跨职能特性团队。包括以下内容：
- 开发一个满足规模化和更多需求领域的构建系统
- 简单的DCC（Dynamic Cruise Control/动态巡航控制），因为它只涉及几个软件组件。
图16中的第1步。
使用志愿者！真正的自愿是吸引人们的思想和心灵的有力方式。[3, 第58页]
我们的意图是与志愿者一起从小做起。
在这时，我们给管理者安排的培训包括一天的LeSS介绍、Craig给LeSS管理者课程的阅读准备，以及Mark Bregenzer的教练辅导。紧随其后是CLE课程，以及参与第一个需求领域的所有人会参加CLP课程。
设立第一个需求领域的约束条件如下。
- 第一个需求领域的规模应该是70人左右。
- 第一个需求领域的转变过程必须从8月初开始，意味着是在学校暑假期间。
- 在过渡到LeSS组织期间，现有职能/组件团队的职能经理需要暂时扮演双重角色。这些人将是（1）LeSS组织里的LM，和（2）原组织里的职能经理。这种设置将确保尚未加入LeSS组织的员工仍有他们的职能经理。
约束条件1和ADD的规模（大约800人）导致我们有一个并行组织，正如指南[3, 第74页]中所描述的那样。观察图16可以清楚地看到，构建系统和简单的DCC（第2步）将在LeSS组织的范围内。其余的（第3、4、5步）则需要保留在以前的组织架构中，以确保稳定的交付以及与ADD和宝马集团外部稳定的接口。图17可视化了LeSS、非LeSS组织和SoP2018项目这些概念。
并行组织和“只有志愿者应该加入第一个需求领域”的概念导致了第3个制约因素。
在产品定义章节中有提到，ADD有两个主要的里程碑，SoP2018和SoP2021。从事SoP2018工作的人员仍留在原组织中以确保发布；他们不能加入LeSS组织。因此，几乎所有的至少有过一次将汽车交付到量产经验的产品开发人员，都不能参加第一个需求领域。以项目思考 - 围绕工作来组织人员 - 限制了一些拥有成功产品开发所需技能的人参与进来。关于围绕工作组织人员与围绕人员组织工作这一主题的更多信息，请参见按客户价值组织[3, 第78页]。
此外，8月初也是德国巴伐利亚州学校暑假的开始（见制约因素2）。这个时候，有家庭的人都在享受暑期假日，这进一步减少了可参与的人数。因此，潜在的志愿者队伍主要包括从未经历从汽车研发到交付生产阶段的长期研究人员、刚加入ADD的人，以及少数有经验的关键人物。
可用人员的短缺，加上导入LeSS的第一个需求领域需要八个团队，这导致人们被迫成为“志愿者”。第一个需求领域之前的行动顺序放大了这种影响。首先，潜在志愿者群体自愿加入 - 有些人是因为一些推动才进来的。然后，在有了一份“志愿者”名单后，管理人员才马上开始安排CLP课程以给志愿者培训LeSS，并让他们了解在LeSS组织中工作意味着什么。
在CLP课堂上的观察表明，一些“志愿者”并没有真正知道和理解在LeSS组织中工作的含义。这时，“志愿者”才明白他们自愿参与了什么。有些人不喜欢他们课堂上学到的内容。他们不想成为第一个需求领域的一部分，变成了系统的囚犯。
如何开始指南[3, 第59页]则建议采用相反的顺序 - 第0步：在寻找志愿者之前，首先培训每个人。这一点并没有做到。
在宝马集团导入LeSS之前，经理们通常参与决定实际工作是什么以及如何处理。此外，他们会做IPA和其它与LM相关的任务，例如，与供应商和组织变化相关的问题升级。我们把这种类型的经理定义为传统经理。
在LeSS中，PO对产品的愿景负责，并通过对产品待办列表 - 做什么 - 进行优先排序来优化影响。团队，也只有团队，才能决定怎么做将这些特性或需求转化为产品。是有意让这两个角色的工作有所重叠的。他们应该互相支持。
ADD现有的范式 - 有明确的责任线 - 导致大家认为那些角色的职责或任务是互相排斥的。于是就成了：PO决定做什么，而团队决定怎么做。
Scrum和LeSS在这方面并没有定义LM的角色。LM应该做什么？
……管理角色发生了很大的变化，以前是管理工作，现在变成了为团队的发展成长创造条件…… [1, 第241页]。
换句话说，他们的角色是提高组织系统的价值交付能力。
ADD正是这样定义了LeSS组织中的职责。PO部门负责做什么。开发部门的LM角色是提高组织系统的交付能力，而团队则决定怎么做。
约束条件3（见前提条件和制约因素）讲到，经理从传统经理过渡到在新组织中的LM，需要暂时承担双重角色。第一重是他们以前作为传统经理的角色。第二重是他们新的LM角色。只要之前组里的下属还有在非LeSS组织中，这种双重角色的情况就会一直存在。换句话说，一个属于LeSS组织的经理仍然会在非LeSS组织中进行传统的管理，决定做什么和怎么做。
双重角色的设置影响到了产品所有权、LeSS中的直线管理和传统管理的区分。对破坏角色和组织边界的顾虑导致了大家拒绝第3条约束。因此，非LeSS组织中剩下的人变成没有管理者，没有人为他们协调做什么和怎么做 - 这对这些人来说很不正常。
此外，大多数拥有完整系统知识的关键人物，如果有可能，都转到了第一个需求领域。
这些情况综合在一起使得ADD组织的其他成员对LeSS组织产生了强烈的依赖，不依靠LeSS组织的人，他们就无法交付。
同时，LeSS组织专注于提高其作为需求领域的交付能力。但是，整个SoP2021组的交付能力下降了，与宝马集团其他部门的联系也削弱了。为什么呢？主要是因为在非LeSS组织中大约有250人缺乏一个可理解的组织架构，从而迷失了方向。许多人不再做他们所负责的任何事情。
此外，LeSS组织中的一些人非常关注需求领域，以至于他们放弃了与组织其他成员的沟通和联系。找到解决方案的压力迅速增加，首席教练（在这次LeSS导入中的第一位LeSS教练和培训师）开始大量参与帮助找到解决方案。其他的LeSS教练也参与到第一个需求领域的持续辅导中。
非LeSS组织的人需要与LeSS组织的同事一起工作。通常情况下，是因为有人需要在主题X上得到帮助，而主题X的专家在第一个需求领域。但两个小组的工作方式明显不同。“我们想在我们的跨职能团队中做X”与“我们想把X拆分到几个单一职能的团队来做”。解释为什么LeSS组织中的人想用不同的方式来处理和解决事情，导致了激烈的讨论和两组之间更紧张的关系。两组人不再说同样的语言了。
基于这个洞察，CLP课程独立于实际LeSS转型来进展。整个ADD在一年内都上了CLP课程。然而，当相关人转变到LeSS组织时，他们已经淡忘了从CLP课程中获得的知识，这给新的需求领域带来了进一步的困难。
建立和运行LeSS组织、为非LeSS组织的人创建一个解决方案、明确哪些遗留代码应该是未来开发的一部分，诸如这些活动以及许多其它问题都耗费了大量时间和精力。因此，进展是相当缓慢的。
存在扩大LeSS组织并开始第二个需求领域的渴望。有几个因素促使了它。首先，大家有强烈的愿望变得更好。看起来从几乎没有结构的非LeSS组织转变成LeSS组织会解决一些问题并减轻痛苦。其次，大多数来自非LeSS组织但参加了CLP课程的人都主动想尽快加入LeSS组织。第三，ADD需要向他们的利益相关者和媒体展示特性。因此，ADD的高级副总裁自然希望看到并体验在汽车上的特性增量。
值得注意的是，要保持LeSS组织的健康，必需满足一些条件，特别是在增加团队时。这些条件是：
- 一个所有团队和需求领域产品待办列表的共同结构
- 一个能确保快速反馈的可工作构建系统
在这个阶段，第一个需求领域的产品待办列表开始变为一个多层次的、树状的需求集，引入了条目之间的依赖，这掩盖了要做工作的整体概况、演进的方向，并对只是一个需求领域的优先级排序也已经带来了负担。产品待办列表开始偏离大多数与其相关的指南，特别是不要“管理依赖”而是最小化约束[3，第198页]和最多三层[3，第222页]。
在导入LeSS之前，有两个“项目组”为自动驾驶的某些方面已经创建了原型代码；这两套实验性代码中包含了很多重复和不一致的地方。为了“加快”进度（又一个速效方案），来自这两个代码库的整个遗留代码被合并到新的主干分支，几乎没有自动化测试，使得特性和代码的覆盖率处于不足的水平（更多细节见仓促合并仓库）。因此，共享代码所有权变得更加困难。构建系统和基础设施还没有准备好应对这种结构和负载。整个系统变得很慢，反馈时间也大大增加。因此，有着快速反馈周期的主干开发变得不可能（更多关于这个主题的内容请见技术视角章节）。
第二个需求领域以一个破碎的待办列表和构建系统拉开序幕。而LeSS组织的范围扩大到所有的软件组件和传感器，但仍然只在快速原型平台上开发（图16中的第3步）。
为了在从一个需求领域扩展到许多需求领域的同时保持产品待办列表中条目优先级的透明度，对所有需求领域必须有一个共同结构。它使PO能够更好地掌握当前的状况，进行优先级排序，并在需求领域之间改变团队 - 组织适应性的一个特征。但是，被用作电子产品待办列表的工具，以及使用它的人，造成了障碍。加上产品待办列表中晦涩难懂的多层次、树状的需求集合，不同需求领域（现有的和计划的）的产品待办列表结构大约在这个时候开始出现分歧 - 一种局部优化。也请看指南：大型产品待办列表的工具[3, 第210页]。
不幸的是，即使存在这些明显的问题，在接下来的几个月里，仍在继续增加新的需求领域（见图18）。
每一步推进都扩大了LeSS组织的范围。增加四个需求领域后，范围扩大到图16中的第4步。有了所有的九个需求领域时，范围达到了最大，即整个ADD的范围（图16中的第5步），然而，这种过快的扩张背后有无数的弱点。
必需进行大量的实验，以为每个需求领域找到一个有意义的范围。这经过了多次重组、检查和适应周期。在这些重组过程中，基于LeSS结构的组织的灵活性变得明显。由于需求领域不是组织架构图或部门的一部分，重组过程很快。最快的一次需求领域重组（从开端到完全实施）一周之内就完成了。
这是个好消息：一个适应性强的组织。但坏消息是，这种频繁重组的一个关键驱动是扩张太快。
尽管LeSS巨型组织结构允许这样的灵活性，但它的目的是为了适应以客户为中心的视角下不断变化的优先级，它也伴随着一些切换成本。由于中断了在一个需求领域内已逐步发展的团队间关系和已建立的协作，以及团队转移到一个新领域所需不少的领域学习，需求领域的频繁重组是有问题的。
调整组织架构相对容易，但改变思维方式需要时间、讨论、反省和学习。[1, 第229页]
宝马集团LeSS的导入可以借助萨提亚改变模型来进行展现。图19显示了通向当前状态的历程以及未来可能的样子。
这个历程包括5个阶段。这里的回顾视角只是详细阐述了混乱阶段。
在引入LeSS后，ADD很快就进入了这个混乱阶段！认知偏差和所有人所在的系统影响了我们的心智模式，进而我们的行为。人为错误和积极破坏是它产生的效果，导致了本报告中描述的情况。
问题是：混乱的程度能否被最小化甚至避免？
可能它可以! 也许读者可以从这些经验教训中受益。文章中的回顾视角涵盖了最初迈向LeSS的两年时间，揭示了痛苦动态的原因，并提出了预防或减少它们的方法。
产品开发系统 让我们用Jay Galbraith的组织设计框架 - 星型模型（见图20）- 来阐述什么是产品开发系统。
Craig Larman和Bas Vodde在他们的《精益和敏捷开发大型应用指南》一书中指出，Scrum或LeSS的导入直接改变了流程和结构的要素。在ADD的案例中，在准备导入LeSS时，正是聚焦于这些要素。
结构和流程只是一个组织设计的其中两个部分，我们往往在这两个部分上花费了太多精力，而在其它要素上花费的精力则太少。
结构通常被过分强调，因为它影响到地位和权力…… [14, 第4页]
星型模型的各个要素是高度交织在一起的，它们互相影响，又一起影响着组织的行为、文化和绩效。因此，所有要素之间的对齐一致对于一个组织的有效性至关重要。否则，组织能力就会下降。Galbraith这样说：
一个组织要想有效，所有的政策（星型模型中的要素）都必须保持一致，并和谐地互动。[14，第5页，括号内的解释是后加的，强调是后加的] 。
这篇回顾性分析是使用星型模型的要素来组织的。
除非有权威人士为团队的工作指明方向，否则不可能实现有效的团队自我管理。[12, 第62页]
尽管引入了LeSS并决定将产品开发作为产品开发来管理，现实依然感觉像是项目开发。
宝马集团有（现在仍然有）一个产品管理部门，该部门的人员负责规划和管理宝马集团制造的所有车辆的整个生命周期，从创意到开发到维护。这个部门与开发汽车零部件的其他部门订立了模块化系统合同。这样的合同通常涵盖了一组不同的车辆、它们的发布日期、一般范围、预算，并旨在实现各部门开发的部件/系统的高度重复利用。
在导入LeSS之前，这样的模块化系统合同（一个实际的文件）是在ADD和产品管理部门之间签署的。
传统的汽车行业仍然是做长期延迟的集成，而不是频繁的集成。因此，过去（现在也是）有一个宝马集团范围内的通用汽车项目时间表，它定义了固定的集成步骤和所有参与部门在开始量产途中的其它里程碑，以便他们可以在一个缓慢的周期内同步工作。
图21说明了在模块化系统合同、通用汽车项目时间表和ADD之间的设置。
几十年来，经理们传达了这样的讯息"我们需要按时交付所有的东西"，也就是在约定的发布日期前交付合同的范围。这个讯息变成了一个口头禅，被许多人传播并相信，而不仅仅是经理们。因此，交付一切的愿望很高，而且这样的讯息继续在传播。此外，这种风气是在创建电子机械部件的背景下产生的，如制动系统；与创建AD软件的艰巨工作相比，这些部件的复杂性、可变性和研究导向性都大大降低。
有趣的是，传达这一讯息的人忽视了这样的证据，至少在过去的十年中，产品组从来没有在一个给定的期限内交付 "一切"。通常有一个密集工作模式（就像一个任务组），有人把不太重要的主题放在次优位置，以专注于关键的任务。
此外，模块化系统合同中描述的范围在某种程度上是可以协商的。这个程度是什么？客户在最新车型中可以体验到的所有特性也必须在新模型中提供。因此，现有特性范围是必须具备的。然而，新特性的内容是可以协商的。
尽管已有证据，那样的环境还是降低了对讨论缩小范围（至少在早期阶段）的接受程度，这导致没有优先次序，因为“每一项都很重要”。由此产生的行为是“我们需要每一项”。一厢情愿的想法! 当然，如果所有东西都同样重要，那么所有东西也同样不重要。只是在发布前一年，调低优先级才开始 - 意味着对范围和日期的重新谈判。这种晚期的重新谈判在过去和现在都很常见，并且与宝马集团的其它项目相一致；因此，这是在意料之中的。
还有一个方面导致了没有优先级的所谓“产品待办列表”（所谓是因为根据定义，真正的产品待办列表会被优先级排序，提供一个明确的方向）。大多数并非真正APO的“APO”们是之前也做过开发的项目经理。
第一个需求领域以这些“APO”作为伪PO来开始工作，是因为只有一个需求领域，而后来成为PO的人当时又在忙别的。在第一个需求领域开始后的某个时候，两个“APO”都拒绝了辅导，特别是在建立一个真正的产品待办列表方面。为什么呢？
首先，最初辅导中的学习内容无疑是令人不安的。例如，接受通过将产品分割成很小的部分来管理产品复杂性的想法是一种错觉，相反，经验控制、从产品经验反馈中学习以及优先级排序是更好的方法。
身居高位的“APO”拒绝接受他们认为地位低于他们的人来做LeSS辅导 - 基本上是我们聘请的所有教练。
由此产生的缺乏PO/APO和产品待办列表能力，导致“产品待办列表”中充满了多个抽象层级的技术任务，而且这些任务之间存在诸多依赖关系，这也是PO对产品待办列表进行优先级排序的主要障碍。
关键点：大多数“APO”不能保持整体产品焦点并为下一个迭代准备有价值的条目。相反，他们试图把所有的东西分成很小的部分 - 这是几十年来的习惯，也是害怕忘记某些东西的反应。
那样的情况对团队来说非常方便，因为技术任务将他们的注意力缩小到了一两个组件上，但并没有激励他们去学习客户语言，也没有激励他们学习更广泛的组件和技能，以增加他们的学习和适应性。因此，所谓的“产品待办列表”主要由技术任务组成，而不是以客户为中心的条目。其结果是另外两种反模式。(1) 在产品层面上重新确定优先级变得很困难 - 事实上，几乎是不可能的 - 因为技术任务自然是相互依赖的。(2) 在为客户导向的问题寻找技术解决方案时，很难找到团队之间的合作和协调机会。为什么呢？因为技术任务通常只反映整个系统的一小部分，例如一个组件，但客户导向的条目通常跨越多个系统元素。
这两种反模式导致了所谓的“APO”的工作超载。他们有些人的行为更像是单个团队的“PO”，在他们的需求领域内针对团队的产品待办列表排优先级，这加强和放大了条目从产品需求到技术任务视角的螺旋式下降。
其结果是什么？缺乏整体产品焦点和优先级考虑，导致了高度的忙碌和完成技术任务的高产出，但完成客户特性的产出却很低，因此没有什么有用的结果。这种来自技术任务的冲击使PO不可能拥有一个有意义的整体产品视角，也不可能给所谓的“产品待办列表”排序，这使他失去了权力，只能依赖于参与技术的“APO” - 他不得不相信“APO”告诉他的东西。
PO为什么没有收拾这个烂摊子？为什么他没有推行一个真正的产品待办列表，使他能够排序？一个原因是他作为PO的工作时间太少。扮演PO角色这个人有许多其它职责；例如，他是一个部门的副总裁，一个外部但与ADD相邻的项目的项目经理，最重要的是，他的时间被SoP2018的发布所占用。很可能还有其它我们看不见的原因。
这引出了一个问题，为什么不选择一个“空闲”的PO，为什么我们认为一个负担过重的人可以有效地学习并采用一种复杂的新方法？
因为至少据我（这里指Konstantin）了解，没有人质疑过这个人是否应该成为PO。所有层级的人都认为他是一个非常适合担任PO角色的人。为什么呢？因为在导入LeSS之前，他是客户交付部门的副总裁，重新排优先级是他工作的本质。
有时间来履行PO角色并不被认为是一个问题，因为他可以将其它活动委托给他的下属，将自己释放出来。
因此，更好的问题是：为什么他变得负担过重，以及为什么他没有接受PO辅导？
首先，PO陷入了传统的管理模式。他将大部分的PO任务下放，并相信他的下属会正确执行这些任务。
此外，他知道技术任务“产品待办列表”的问题。但是，他决定支持这些所谓的“APO”们，主要是因为在“APO”们的眼中，首席教练是一个从未向生产交付过汽车的人，这让教练在“APO”们和PO眼中的地位降低了。因此，PO更信任他的"APO"们。
……如果不能确立一个令人信服的方向，就会有两个重大的风险：团队成员会追求他们个人喜欢的任何目的，但没有任何共同焦点；或者他们会逐渐淡出……[12，第80页，强调是后加的]
如何解决这种情况？
关键是要确定谁有制定方向的合法权力，然后确保这个人或团体能胜任地、令人信服地、毫无歉意地行使权力。团队的绩效在很大程度上取决于这一点做得如何。[12，第63页，强调是后加的] 。
一个更好的方法是释放PO的其它职责 - 与产品所有权关系不大的那些职责。此外，用真正的APO取代所谓的APO，他们应关注产品而不是技术解决方案。
此外，降级和调解会议可能会有助于重新建立对PO和APO的辅导。
此外，从以软件组件为中心的技术任务到以客户为中心的特性的产品待办列表（PB）的转变，将使针对PB进行优先级排序成为可能，并使团队能够解决真正的客户问题。
整体产品焦点是至关重要的! 邀请用户、付费客户和领域专家参加产品待办列表梳理（PBR）会议，将有助于建立客户语言，获得整体产品焦点，并通过不断发展的客户特性，而不是完成技术任务，增量地交付ADD产品。
如何让客户参与PBR并遵守信息保护政策呢？值得注意的是，宝马集团的许多员工也是客户。他们驾驶宝马汽车，亲自体验产品。唯一的限制是让那些不了解技术细节、只会说客户语言的人参与进来 - 例如，来自人力资源、法律或采购的人。
管理者的工作是建立一种环境，在这种环境里，团队能够不断地交付并不断地改进。[3, 第69页]
管理者的职责是改进产品开发系统，通过进行现场观察、鼓励停下来修复，以及“实验胜于遵从”。[3, 第115页]
开始的结构具有高度的组织适应性，我们在重组需求领域时体验了这点。由于需求领域不是组织架构图或部门的一部分，重组过程是快速的。
ADD利用这一优势来频繁地改变需求领域，这主要是由于LeSS组织扩张过快造成的（参见增加更多需求领域章节）。为什么LeSS组织扩张得如此快？
其中一个原因在于宝马集团的传统职业发展路径，即优秀的、动手能力强的工程师在其技术生涯的顶端成为平庸的管理者。因此，晴转阴的管理者比例很高，降低了管理者组织和管理非LeSS组织的能力，随后导致其处于不健康的状态，这驱使人们更快地进入LeSS组织。
另一个原因 - 可能与前者有关 - 是由于缺乏专家，非LeSS部门无法独立于LeSS组织工作，这些专家主要在SoP2018项目和LeSS组织中。这种情况是围绕项目而不是产品进行思考和组织人员造成的结果。
尽管在组织架构上做了周到的基础工作，并努力实现自管理团队和实践社区的合作，但人们认为自管理，特别是社区的自管理是低效的。这是因为大量未经过深思熟虑的决定和薄弱的决策过程，部分原因是开发人员缺乏决策的经验和能力（因为以前是由专家和经理完成的），部分原因是SM缺乏经验和技能，他们没有有效地指导团队或社区的参与式决策协议。
作为一个速效方案，因为这个以及相关原因，高层管理者在开始第一个需求领域的两年后恢复了C-4级别的管理人员和专家角色。此外，组织架构固化使需求领域成为正式的组织单元，这导致了它僵化并难以消除，而不是适应性地诞生/成长/收缩/消亡，而这在LeSS巨型中至关重要。此外，官方的组织团体强化了筒仓问题。不幸的是，这种洞察在ADD要么从未出现过，要么被遗忘了，从而导致忽视了LeSS巨型组织指南。
避免让需求领域等同于组织架构，因为这将导致它们难以改变。[3, 第110页]
让我们来阐述一下为什么许多决定是未经过深思熟虑的，决策过程是低效的。
当从管理者领导转变为自管理团队和社区时，管理者 - 有时也有SM - 的想法是，“要么团队/社区自管理，要么我需要介入，从而打破自管理。”
关键点：这是一个错误的二分法。相反，它应该是："我需要帮助他们实现自管理"。
由于害怕打破自管理，经理们让团队和社区主要靠他们自己。因为他们必须做出决定，最不充分和最幼稚的决策协议，即少数服从多数，成为他们的默认方式。这是又一个没有看到的速效方案，更糟糕的是，它得到了初级SM的支持。有经验的人是少数，大多数时候都被投票淘汰。因此，大多数的决定都是没有经过深思熟虑的和无效的。
关键点：我们没有成功建立一个技能等级制度（没有专家角色），也没有引入适当的决策协议，比如由一组达到法定人数的有技能和经验的人来做决定。
这种情况变得与Jo Freeman在她的文章“无结构的暴政”[15]中描述的情况相似。
……这场运动产生了很多行动，而结果却很少。不幸的是，所有这些行动的后果并不像结果那样无害，它们的受害者是这场运动本身。[15]
没有专家角色的技能等级制度会是怎样的呢？
首先，让谁拥有初级、中级、高级或专家技能以及他们的领域都透明化。
其次，确保拥有高级和专家技能的人形成达到法定人数的决策组，并引入参与式决策协议，如核心协议中的决定者/决议制[19]。
第三，使技能水平之间的差异透明化，以便人们知道如何提升。
第四，帮助人们获得高级和专家级的技能。从初级到中级，通常可以通过获取知识来完成。从中级到高级，再到专家级，需要时间；在这个过程中，知识会被经验所充实。
我们想遵循深而窄优于广而浅[3, 第55页]的导入原则，一步一步地导入LeSS，一个需求领域接着一个需求领域。教练的合同定义了一个固定的价格包，即每次将70人带入LeSS组织。
尤其是在开始时十分强调遵守合同。否则，花同样的钱会得到更少的“价值” - 一个合同游戏。这种动态导致了……第一个需求领域必须有70人！再加上要求在暑假初期开始导入LeSS，因此几乎没有人可用，这导致了被迫的“志愿者”（见前提条件和制约因素以及伪志愿者）。因此，大多数需求领域都是从这个人数开始的。
合同还包含了一个项目计划 - 描述LeSS导入开始和结束时间的甘特图。这个项目计划，体现了对巧妙的变革和改进的无知，只是为了遵守采购流程和宝马集团的政策。当然，在幕后，那些理解适应性的人并不打算把它作为一个实际的项目计划来使用。
但是，墨菲定律当然应验了：高层管理者发现了这个项目计划，然后ADD就遵循了它，主要是因为它指明了一个持续变革的结束日期。结果，这个计划只是一个原因，LeSS组织主要是在按照计划而不是按照更合理的方式扩张。请参阅增加更多需求领域和结构。
关键点：追求完美的持续改进被看作并运行成一个项目，而不是持续地进行。
每当一个现有的流程需要调整，或符合行业标准需要一个新的流程，大多数时候，PO团队和开发部门都会将这些任务下放，自己则退出（见图15）。这是为什么呢？
一个原因是人们已经习惯了这种工作方式。另一个原因是，在很大程度上，并没有实现让使用和遵守流程的人来创建流程的重要想法。
关键点：在LeSS中，团队要对他们的流程负责。这是建立自管理团队的一个直接结果。见指南：理解泰勒和法约尔 [3, 第115页]。
自管理团队和经理领导的团队之间的区别之一是对他们流程的责任。自管理团队拥有他们的流程。由于宝马集团整体缺乏这种认识，并且由于组织规模和ADD外部的依赖性，大多数人是租用流程而不是拥有它们。
让我们来看看人们没有对他们的流程负责的原因。
在导入LeSS的头两年，人们怀疑自己是否有能力按照LeSS原则和规则来改变现有流程或设计新流程。为了解决这种情况，SM就LeSS原则进行辅导，并帮助创建或改进流程。这是一种健康的动态。
在准备阶段，这种动态在LeSS导入之前就被预见了。为了确保LeSS和行业标准保持一致，由SM和行业标准专家组成的能力和辅导部门成为了负责流程的官方机构。
为什么SM们会允许自己参与到如此明显不应该参与的事情中去？由于整个ADD几乎没有Scrum经验，人们骨子里认为Scrum在某种程度上是一种流程。作为一个推论，没有Scrum大师。相反，有的是一些初级SM，他们并没有预见到“负责流程”的标签会造成紊乱。
官方的"对流程负责"的标签在人们的头脑中造成了一个心理障碍。大家对任何流程的改变都要寻求能力和教练部门的批准。一段时间后，这变成了把问题交给能力与教练部门，并期望他们推动问题的解决。
作为一个速效方案，能力与教练部门被分成了两部分：（1）一个行业标准专家单元和（2）一个同质化的SM组织单元。两个职能部门，每个部门都有其单一职能的LM。这个例子展示了“默认的组织问题解决技术：（1）发现一个问题 - 某某某问题。（2）建立新的角色 - 某某某经理。（3）将问题分配给新的角色。”[3, 第120页]
从长远来看，一个负面的、未曾预料到的副作用是，工业标准化专家小组最终为团队创造了各种不恰当的流程，因为他们没有什么实践经验和洞察力。现在回过头来看，如果更加关注实验 - 避免……有自上而下管理层支持的导入[2，第374页]，我们也许能对此有所预期，因为这正是它警告的问题。
总之，让一个组织单元对流程负责在几乎任何情况下都对人类员工适得其反。这是非常根本的泰勒主义方法的一种表现，即在制定计划的人和无脑地执行计划的人之间区分不同的工作。
关键点：事实上，“对任何事情负责”的标签都会造成瓶颈、延迟、交接、各种其它浪费的动态，以及最重要的，拥有责任的问题。这发生在当负责X的角色或小组与拥有X的其他人之间的心理联系被打破时。
能力和教练部门得到了“负责流程”的标签，以便其他部门的人知道在改变流程时应该向谁寻求建议。然而，这个标签创造了一个不想要的动态。
一个达成同样目的的更有效手段是：（1）让行业标准化专家加入团队，获得实践经验；（2）让普通团队成员集中参与创建流程。
在准备导入LeSS的过程中，教练们十分强调改变奖励制度（包括工资模式）的重要性，以支持产品开发系统的其它要素。
具体来说，主观的经理驱动的晋升和基于经理的个人绩效考评（IPA）需要重大改变，以支持自管理团队。为什么？
经理驱动的晋升推动了对基于经理的IPA的渴望，然而经理（考评者）几乎从未掌握有深刻洞察的信息来扎实地进行考评。还有就是偏见 - 有意识的和无意识的。再加上IPA之间的长周期（这里是12个月！），反馈变得肤浅，并与个人的具体行为无关。因此，对个人改进的反馈质量是非常值得怀疑的。
此外，由于经理驱动的晋升是主观的，人们开始相信，晋升与绩效关系不大，而与拥有“正确的”关系和讨好的个性有关。Jeffrey Pfeffer在他值得一读的哈佛商业评论文章“关于薪酬的六个危险神话”中描述了这种动态。
这导致了个人主义、英雄主义和其它在预期自我管理的团队合作环境中的紊乱。
在ADD，C-3级别的管理人员和人力资源部门一起，有志于改变现有IPA以支持团队合作，并使个人职业发展的规则透明化。但他们失败了。
这种状况并不是一个问题，直到……
……下一轮的IPA。由于没有任何改变，人们仍然期望他们的LM来做他们的IPA。但是！……C-4级别的经理被取消后，每个C-3级别LM的管理范围增加到了大约60名员工，他们现在要做很多IPA，而同时却没有更多的视野和洞察。
这一动态使本来就很主观的IPA变得更加主观。后来，一项员工满意度调查证实了人们对这种情况和他们的经理的挫败感。有必要采取紧急的改进。
作为一个速效方案，高层管理者恢复了C-4级别的经理，以减少管理范围，并在下一个IPA周期产生一种虚假的客观性。回到现状!
结论
当引入一个诸如LeSS导入的重大变化时，只改变结构和流程，而不改变奖励政策和其它要素时，这个变化将会失败。这是一个系统!
星型模型表明，奖励制度必须与结构和流程相一致，从而影响战略方向。只有当奖励制度与其它设计选择（星型模型中的要素）结合起来形成一致的组合时，才会有效。[14，第4页，括号内的解释为新增内容] 。
如果上层管理者不进行系统思考，那么系统就会“恢复到均值”，仅仅是因为每个人都知道它。只改变系统的一部分，但有很高的期望值，会造成痛苦。它形成了这样的观点，"我们已经尝试过X，它不起作用"，并导致被动响应，通常造成快速修复的反应。
有怎样的替代方案呢？
在评估替代方案之前，一个有共识的目标是必要的。如果目标是员工的短期服从，那么行为操纵可能是最好的方法。在这种情况下，努力实现自管理团队是毫无意义的，因为这两个目标是相互矛盾的。
接下来的段落会假设大家对自管理团队这一目标达成了共识。为了详细说明替代方案，需要对个人绩效考评和晋升的做法进行一些解构。
个人绩效考评
绩效考评的两个常见目的是：
- 反馈以变好（改进和发展，比如增加新的优势或增加现有的优势），和
- 为晋升提供输入。
反馈以变好应该是一个双向的对话，经常进行而不是每年一次，而且与晋升完全脱钩。
为员工提供反馈，使其能做得更好，这与通过提供（或不提供）奖励来控制他们决不应该混淆或结合。[17, 第185页]
当一个经理既作为顾问帮助一个人提高他的绩效，同时又作为法官主持同一个人的薪资时，他在担任自我矛盾的角色，这似乎是愚蠢的……[18] 。
在Scrum环境中，团队成员和他们的SM - 他们紧密合作并详细了解对方的工作 - 有机会在每次迭代回顾中互相反馈。由于这是标准实践，IPA中反馈目的的价值消失了。
剩下的就是晋升了。
晋升（和奖励）：（由另一方）决定将某人归入一个新的角色分类，被认为是“更高”和令人向往的一步。它通常包括以下其中一项的提升：工资、权力、知名度、声望、影响力、决策权、认可度等。
人们通常感兴趣的不是晋升本身，而是随之而来的东西，而晋升通常提供不同类型的奖励。Frederick Herzberg在他的哈佛商业评论文章“再一次：如何激励员工？”中将一些奖励分为两类：（1）保健因素和（2）内在激励[16]。根据Herzberg的说法，保健因素执行不力会导致工作不满意。然而，把这些做好并不会导致工作满意。相反，它导致了没有工作不满意。内在激励则是导致工作满意的因素。
在这种情况下，工资只是一个保健因素。因此，把它作为补偿，而不是一种依据绩效的奖励，是很有用的。考虑到这一点，整个由经理驱动和影响的工资调整的做法变得无效，并可以被取消。
尽力确保他们（员工）不会感到被剥削。然后尽你所能帮助他们把钱抛在脑后。[17，第182页，括号内的解释为新增内容]
请注意，与晋升相关的非货币奖励（如决策权和认可）更有可能作为内在激励。
Richard Hackman博士（哈佛大学研究团队的主要专家）提到了奖励发挥作用的三个条件。(1) “团队成员必须明白想要的和奖励的是什么。”(2) “必须有可以信赖的指标来衡量想要结果的实际达成程度。”(3) “……成员必须认识到他们对这些结果的达成具有影响，他们的集体行为直接塑造了触发奖励的结果。”[12, 第138-139页]。
公式化标准的晋升可以帮助实现所有这三点。它们也将指示PD（Product Developer/产品开发人员）级别。
什么是公式化标准？在LeSS背景下，这些标准必须有助于提高组织系统的适应性。例如，要从PD_n升到PD_n+1，员工必须表明在四个不同的技能领域达到了X级，展示他们具有适应性。这样一来，公式化标准的晋升就变得更加客观、透明，而且对每个人来说都很清楚。
那么如何评估员工呢？与任何评估一样，评估者必须比被评估者更有经验。因此，它可以由内部广泛认可的专家或专家小组来做，或者由诸如评估和认证某项技能专长的团体那样的外部机构来做。此外，也可以利用同行的反馈。
如果人力资源政策保持不变，该怎么办？
就像在ADD的案例中，管理者不能改变人力资源政策或取消IPA。《精益和敏捷开发大型应用指南》一书中包含了这方面的两个实验。
第一步，管理者和团队需要讨论基于经理的IPA和经理驱动的晋升所产生的紊乱。在他们达成共同理解，明白这是笨拙和浪费的过程之后，他们必须约定未来如何处理未改变的人力资源政策。
第二步，在认识到这个流程是种浪费之后，他们用最少的精力和注意力去走这个流程，然后迅速回归到有用的工作：交付产品。
基本的系统思考 - 和星型模型的交织本质（见图20）- 表明，人们需要一个整体适当的组织设计才能成功。
关键点：人员的态度和星型模型的其它要素需要结合在一起，才能使组织有效。
团队成员来自一个传统的组织，由经理领导，并组织成单一职能部门和组件团队。LeSS导入则要求人员想要在共享代码中跨组件工作，并跨职能地解决客户问题 - 这是很不同的态度。
不管他们是否希望如此，许多人在以这种方式工作时都遇到了困难。随着时间的推移，大多数团队又恢复了类似组件团队的设置。让我们探讨一下这一现象背后的驱动力。
一个强有力的原因是，技术任务工作清单被错误地称为“产品待办列表”。参见战略与任务章节。
另一个原因是大家希望将他们的注意力缩小到更少，最好是一个软件组件。这至少有两方面的原因：
原因一：
在LeSS导入之前，ADD估计过（基于软件组件）开发AD所需的人数。每个软件组件会变复杂多少，我们还需要多多少人来应对？这意味着关于组织结构的主流心智模式是基于组件而不是基于客户导向的特性。
在LeSS导入之前，招聘工作吸引了许多具有组件思维的新人，因为找的就是在特定算法领域具有特殊专长的人。此外，大多数新员工来自大学，或这是他们的第一份工作，几乎没有产品开发经验，特别是在共享代码中工作的经验。
随着LeSS的引入，初始的客户导向的端到端产品待办条目很少涵盖人员现有的专业知识。对失去能力的恐惧和失去市场价值的错觉使得大家要求只做涵盖他们专业的“条目”（即单一专业的任务），尤其因为这也是ADD当初雇用他们的原因。
传统管理需要利用人员的专长，再加上一些经理不愿意帮助他们的下属解决问题，导致管理者接受了大家的要求，为他们的单一专长来设计工作（任务而不是客户特性） - 又一个速效方案。
一个更有用的方法是只带真正的志愿者进入LeSS组织。此外，帮助每个人逐个解决他们的问题，主要问题是普遍存在的错误二分法 - “要么我做我喜欢和擅长的事情（单一专业），要么我是一个通用的特性团队成员”。如果是实在不想在这样的环境中工作的最坏情况，管理者应该协助个人寻找其它职位。
原因二：
从CLP课程中学到的知识激励了许多人跨组件和跨职能地工作。然而，在LeSS导入之前，由于缺乏软件工艺精神，积累了大量的技术债务，阻碍了以共享代码的方式同时工作。
由于有这么多的新团队参与，而且或多或少是在同一时间，这个问题进一步恶化了。在这么多人参与的情况下，以软件工匠精神来处理脏代码变得不可能。
例如，低测试覆盖率和组件之间的高耦合度使大家不知道他们的修改是否破坏了系统的另一部分。从而不得不依赖组件专家对他们的修改是否会破坏某些东西进行判断。因此，当碰到不是他们专业的部分时，他们就不愿意修改。
因此，人们不能有效地处理技术栈的广泛范围，并要求减少关注点。这些影响变得很明显，尤其是在LeSS组织扩张的时候 - 这是扩张过快的又一个影响。
关键点：大量的技术债务、LeSS组织的过快扩张，以及很少的软件工艺技能，导致了随着时间的推移出现更多组件团队 - 一个增强的向下螺旋。
当时，ADD提供大量的技术辅导。不幸的是，许多团队并没有使用它。团队对他们有的问题的感知与教练认为的不同。例如，团队并不清楚学习TDD（其价值在比较长时间后才会被意识到）将如何解决他们当前和未来的短期挑战，比如设计应用的模块化（在应用生命周期里会有不同的传感器特性）或安全目标的可证明性（比如在快速驾驶时不能有硬转弯）。教练错过了帮助团队解决他们的问题，并从中改善团队的技术卓越的机会。
那些经过技术辅导的人提高了他们的软件工艺技能。不幸的是，改进的软件工艺技能所带来的积极效果，要在巨大的代码库中变得明显，将会有一个很长的延迟。考虑到LeSS组织过快的扩张，技术辅导在当时的影响不大。
产品开发系统的各个部分是相互交织在一起的，并且相互之间有很大的影响。它是一个系统！ADD没能理解这一点。
本节将研究一些症状和它们的影响。除了下面介绍的内容外，我们想知道是否有我们没能看到的更深层次的力量在起作用。常见的组织紊乱的深层力量包括个人关系的偏袒，破坏挑战管理者职位现状的变革（以至于恢复现状成为一种选项），以及其它更多因素。
在ADD的一个关键观察是，许多（到目前为止所描述的）问题被正确地预见了。但是，许多选择的“解决方案”避免了（实际上只是推迟了）这些问题，而不是直接面对和解决这些问题。
造成这种影响的一个原因是太少系统思考。主要是由于 - 往往是自己造成的 - 时间压力，从问题空间到解决方案空间的快速跳跃，确信手头问题的原因是显而易见的。因此，导致了更多的问题，时间压力，和更少的系统思考 - 一个增强回路。
另一个原因是许多晴天经理 - 缺乏技术职业路径的延迟效应 - 不理解，因而也无法警告或解释，人们无视协议和准则或直截了当地忽视约定的任务会有什么后果。主动破坏几乎没有任何后果（对破坏者而言），导致了更多的紊乱。一个结果是LeSS组织的过快扩张 - 这是一个总体症状，也是许多其它有害影响的原因。
在时间线视角上的回顾得到了五种症状类别。
- 规模化适应性产品开发的先决条件未得到满足
- 过快地扩张到许多需求领域
- 缺乏对现场观察的理解和驱动力
- 缺乏团队合作的驱动力
- 缺乏对技术扶持和卓越的关注
一开始，组织害怕一场深刻的变革会扰乱SoP2018的交付能力。再加上把产品当作项目，增加了参与SoP2018和SoP2021的人之间的距离。项目结构对SoP2018的交付施加压力。因此，虽然我们开始了LeSS导入，但是大多数有量产汽车开发经验的人都不在。SoP2018和SoP2021之间的技术、设计方法、复杂性、组织设计和工作方式都完全不同。所以，让SoP2018的人参与到第一个需求领域会不会让LeSS导入不那么痛苦也是非常不确定的。然而，他们在实际交付方面的经验，以及当一个团队接近交付时对整个产品概述的必要关注，对于SoP2021非LeSS组织来说是非常宝贵的，尤其是在早期阶段。
强制的“志愿者”导致了第一个需求领域的紊乱。为进一步扩大规模，需要展示一个积极的结果，但这在当时做不到。然而，由于将持续改进作为一个项目（因此，有一个终点）而不是持续进行，ADD仍然执行了“扩张”计划。
更重要的是，由于缺乏大规模敏捷软件开发的经验和薄弱的软件工艺技能，一个坚如磐石的构建系统和持续集成行为的重要性被低估和忽视了。
在ADD和产品管理部门之间的模块化系统合同和“我们需要交付所有的东西”的精神导致了没有优先级和对讨论缩小范围的接受度较低。失败的PO/APO辅导导致了所谓产品待办列表充满了技术任务。
两者都导致了缺乏整体产品焦点和优先级考虑，导致了高度的忙碌和完成技术任务的高产出，但完成客户特性的产出却很低，因此没有什么有用的结果。这种来自技术任务的冲击使PO不可能拥有一个有意义的整体产品视角，也不可能给所谓的“产品待办列表”排序，这使他失去了权力，只能依赖于参与技术的“APO” - 他不得不相信“APO”告诉他的东西。
此外，经理和大量的初级SM未能在实践社区和团队中建立有效的决策协议。
首先，现场观察实践被误解，或根本不被理解。软件开发中的现场观察是指在创建代码过程中观察代码和人们当下的体验，并从中掌握真实情况，不管是积极的还是消极的。
这不是“在产品开发人员工作的大楼里去现场观察”，而是例如，当一个团队正在进行群伙编程时，坐在房间的后面，通过观察在这种情况下的开发人员以及他们正在写的代码来掌握情况。
关键点：软件开发中“现场”的核心是……源代码。
也请参见相应的指南，指南：现场观察 [3，第125页]，和指南：管理者作为教师和学习者 [3，第128页]。
其次，管理者关注的领域过于宽泛；这就分散了他们的工作，限制了他们实践现场观察的积极性。个人的激励目标和管理人员的IPA支持这种行为；但它不包括团队的反馈，而只是由他们的LM来做。
缺乏团队合作的驱动力
导致团队合作驱动力缺失的一个原因是未改变和不透明的IPA，在某些情况下还融入了另一个因素：某些人员的奖金与一些特定目标或结果关联。这促进了个人主义，而不是任何层面的团队合作。
缺乏对技术扶持和卓越的关注
对技术扶持和卓越的关注不够导致了负面的增强回路。在真实的目标平台 - 或者至少是一个模拟环境 - 的部署这件事没有被重视，这主要是由于过去几十年开发中习惯于组件开发和较晚集成导致的。相反，ADD在很长一段时间内使用了一个（不适合生产的）快速原型平台。因此，软件朝着只适用于快速原型开发平台的方向发展，隐藏了设计缺陷并损害了整体产品焦点。
首先，也是最重要的，确保理解持续改进，并强调持续改进没有“完成变革”的固定终点！追求完美的持续改进是一项终身的事业。在ADD，理性上大家可能已经理解这个道理。然而，由于文化遵循结构，人们的行为显示出相反的情况。
其次，建立一个稳定的并行组织。两个组织共有一份产品待办列表。这将驱动一个代码库，防止代码分离。此外，它还会影响整个产品组工作在最高客户价值上。
用真正的志愿者建立LeSS组织，只有在前提条件具备的情况下，慢慢地、小心地扩张它。前提条件包括：所有团队和需求领域共享一份有优先级排序的产品待办列表，以及一个可用的构建系统来确保快速反馈。
最重要的是，遵循LeSS巨型的标准建议，逐步扩张，每次只扩张一个需求领域。
将产品看作产品，而非项目，这样可以消除复杂性。如果仍然把它们当作项目来对待，就会导致人们仅仅围绕任务来组织，并产生进一步的紊乱。这种方法将使SoP2018和SoP2021的人更加紧密地联系在一起。他们将能够从彼此的经验中受益。这也将使整个产品组有一个共同的产品待办列表。
为了将变革的速度和规模保持在可控的水平，从SoP2018开始是一个更明智的选择。在SoP2018中，已知的东西 - 例如目标平台、流程、构建流水线 - 要多得多。这些情况会让我们更容易从单一职能和组件团队转向特性团队。此外，SoP2018设置的变化将被限制在一个需求领域，重点是向特性团队的过渡，避免过早扩张LeSS组织。
IPA应该被取消或改变，以最小化其负面影响，并支持团队合作和自管理。深入的教育，包括Scrum的基础知识，将为导入奠定更坚实的基础。
LeSS导入开始时，大家的兴奋度很高，对整个新组织的期望也很高。随着时间的推移，明显期望远没得到满足，欣喜变成了痛苦。这种痛苦来自哪里？
……在一个较大的产品组（比如说500人）导入大规模Scrum时，组织设计 - 结构、流程、奖励、人员和任务 - 中的系统性缺陷会暴露出来。[1, 第290页]
事实上，ADD之前的组织设计的弱点也是如此，导致了现在的情况。期望几十年组织和技术债务的积累，突然在一夜之间，坚如磐石的构建系统和持续集成的行为就会到位，这是天真的想法。还清这些债务需要数年时间，而实践和技术敏捷性也将逐渐改善。
技术敏捷性制约着组织敏捷性，或者反过来说"组织敏捷性受制于技术敏捷性"。因此，ADD高度灵活的组织架构，只提供了有限的好处。相反，ADD想要的工作方式与现有技术基础设施和产品代码库所允许的工作方式之间的差距才是痛苦所在。一些变化不得不被回退，一些则被调整，以使组织重新运转（见图22）。
不要指望这个过程会很快，它需要几年甚至几十年的时间 — 事实上，考虑到持续改进这个支柱，它将是永远的。良好的幽默感，非正式的支持性实践社区，以及耐心在组织改进中特别有帮助。庆祝小的进展。特别是在组织重新设计的工作中，我们鼓励我们的客户牢记系统思考和局部优化的动态。[1, 第284页, 强调是后加的]
LeSS的一个关键目的是让已经存在的问题再次显现。因此，当兴奋的情绪稳定下来，产品的关注度提高后，本报告中描述的问题和失败就变得明显了。然后，为了纠正错误，弥补ADD到目前为止的损失，开始引入必要的改变。
尽管ADD处于紊乱和痛苦中，但这些都带来了积极的影响和学习。
一个重要的学习是，整体产品焦点和鼓舞人心的产品愿景对于成功的适应性开发至关重要。
既定的跨领域活动，如评审、产品待办列表梳理，以及回顾，推动了部门之间更好的合作。此外，更少的角色和更高程度的跨职能团队减少了部门之间的交接和政治斗争 - 更少“我们与他们”的想法。
多个部门，甚至那些与ADD相邻的部门，都在基于相同的原则来工作。因此，在部门边界上必需发生的问题升级变少了。
自从引入LeSS后，有更清晰的对团队而非个人的关注，同时要求并支持自我管理。到目前为止，比之前更多的决策是由团队做出的，这导致了更少的交接和信息分散。
此外，每个迭代都会发生回顾、检查和调整，这在LeSS导入之前几乎从未发生过。这意味着更频繁地分析和解决根因。
随着LeSS导入的开始，对技术卓越的关注度明显提高。它带来了对虚拟化和自动化的高度重视。
对技术卓越的辅导提高了人们对其重要性和影响的认识。它带来了现代的C++、代码整洁、TDD等等。将研究与开发小组合并扩大了技术卓越方面的进展。此外，跨团队合作提高了共享代码的所有权。
也有更多的尝试、检查和适应，从真实的产品环境中学习，而不是不写任何代码就找到问题的"解决方案"。
当一个外部教练参与帮助一个公司导入LeSS时，教练通常会扮演驱动者的角色。从积极的方面来说，这种方式在一开始会导致较少的失败。从反面来说，一旦教练离开，公司必须学习独自继续，在没有教练的情况下可能会艰难。
在这个案例中，宝马集团的内部人员承担了驱动者的角色。教练非常注重让内部员工自己推进导入。因为内部经验仍然有限，这样做导致了一些失败，但ADD从中得到了学习。这样一来，即使在所有外部教练结束合同后，产品组仍然可以自己推进LeSS导入。
ADD习惯了真正的适应性。因此，在必要时更容易发起改变。
从这一点来说，变革必须是连续的、可持续的，以小步进行，朝着最初的优化目标前进。
前进两步，后退一步，仍能让你进步！
在本报告撰写期间，ADD进行了进一步的调整。直到现在，一个需求领域的团队和他们专门的LM在一个组织部门。LM的关注范围变窄，可以专注于一个需求领域内的团队。APO和SM则仍在其他独立的组织部门中。
优先级排序开始发生了。对产品的关注度正在快速增加，使每个人都能根据产品相关问题进行检查和调整。
似乎ADD正在进入萨提亚改变模型的第四阶段 - 整合阶段。将萨提亚改变模型模式与守破离阶段叠加在一起，可以更好地理解为什么如此发生，以及未来会是什么样子（见图23）。
面对直率的现实，理解并践行规则和实践有助于进入整合阶段，这也与*“破”*阶段相关。在“破”阶段，组织中的人必须反思他们所学的一切的意义和目的。因此，他们对这一艺术 - 这里指的是大规模的适应性开发 - 有了更深刻的理解，而不是纯粹的重复实践。
从最近的调整中得出任何结论还为时过早。它们需要经过一段时间的密切观察和分析。这方面的结果可以是本报告的下一卷。
在这一部分中，探讨了几个技术方面：哪些进展顺利，哪些不足，以及下一次需要学习什么。为了更好地理解起点，这里简要介绍了转型开始之前的技术情况。以下章节将提供更多详细信息。
宝马集团在转型之前几十年就开始探索ADAS。在博士研究、外包和其他学术研究等众多不相关联的研究项目中，探索路线有所不同。在大多数情况下，项目计划和特性描述将这些路线链接起来，但在实际设计和代码中却有很大的脱节。这导致了各种各样的代码库和工具。
顺便说一句，作为一名技术教练，我（Michael Mai）发现，当软件开发被视为多个项目而不是一个产品时，这是一种常见的模式。
学术项目经常使用Matlab和Simulink。宝马集团雇佣的外包商使用Matlab或C。这使得协作复杂化，也解释了代码库中一些分歧的概念。
值得注意的是，关于实现至少L3级AD的高难度目标，宝马并没有关注现代机器学习方法，这与该领域最有成就的领导者（如Waymo、Tesla）采取的以机器学习为中心的方法形成鲜明对比。相反，宝马集团继续探索和应用传统的控制方法，如基于公式的指令式编程，就像之前在巡航控制里相对简单的驾驶控制问题中使用那样。
宝马集团将一些研发工作集中在三个大的内部组：SoP2018、SoP2021 HAD（Highly-Automated Driving/高度自动驾驶）和SoP2021 FAD（Fully-Automated Driving/全自动驾驶）。那些组在车辆级产品开发方面有不同的知识、经验和参与程度。此外，那些组在不同的时间加入到转型中（参见图24）。另请参见图17和伪志愿者。
SoP2021团队主要由研究人员和大学刚毕业的新员工组成，他们紧密合作，形成了LeSS转型的起始种子。因此，他们中经验丰富的软件开发人员很少，车载产品开发的经验有限，并且只具备ADAS中分隔的领域知识。
在准备ADD计划时，管理层认为团队中增加的大学刚毕业的新员工可以将现代软件开发技能以及现代整洁和设计良好的代码引入代码库 - 这是管理人员缺乏软件开发技能的另一个迹象。鉴于这些新的非顶级加入者（来自大学或者行业中）能够贡献的经验有限，这次团队扩张是徒劳的。人员章节探讨了其它原因。
缺乏经验的SoP2021团队做出的基础架构决策是直接使用基于机器人研究的消息中间件平台ROS。ROS被用于许多机器人技术的研究论文，但它的设计理念与汽车平台并不兼容。
由于（1）分为HAD和FAD项目组，以及（2）他们被分成多个组件团队（这是管理人员从构建物理组件中所熟悉的传统模式），以及（3）缺乏软件开发和大规模协调的技能，在这些团队创建的多个代码库中，软件概念和设计基本上没有一致性。这些项目组的不同代码库仅在ROS消息级别上有交互。
由于项目目标的差异，概念和软件的“一致性”被评为较低优先级 - 尽管它是交付一个真正产品的关键。这是管理层和开发人员缺乏大规模复杂软件开发经验的另一个迹象。因此，HAD和FAD的代码库差异很大。除此之外，这两个项目组独立组建了各自的组件团队，正如宝马管理人员之前在相对次要和较小的软件项目中所提倡的那样。在开发一个高难度的研究密集型端到端AD机器人时，需要大量基于学习的反馈和改变，宝马管理人员天真地没有意识到由此带来的风险以及缺乏学习和适应性。这些原因导致了几乎没有一致性。
SoP2018组是具有产品开发经验的资深传统工程团队（参见规模化适应性产品开发的先决条件未得到满足以了解为什么存在该团队，以及为什么LeSS转型一开始时没有将该团队纳入）。由于受限于部署目标的工具链，他们不得不使用受限的C++子集，并且他们主要是一群传统的C程序员。他们在诸如面向对象设计（OOD）这些基于较新行业标准的现代大规模软件密集型设计方法上几乎没有经验。缺乏OOD技能这一因素促成了不将SoP2018的代码库融合到新产品代码库的决策。请注意，如果没有这项技能，开发人员就无法在一个新的系统中有效地设计现代C++代码，新系统比他们以前做的任何事情都要复杂和不同。
不同的小组在交流和思考中，对共享软件设计和概念很挣扎。他们不同的过去、目标和代码库并不支持联合开发。然而，管理层的目标是将这些小组联合起来，尽管他们存在差异。为什么？（1）他们是宝马集团的员工，应该能参与开发新产品，（2）错误地评估进一步开发将需要大量增加员工（详见人员），（3）将十年研究成果放到一个产品中 - 要求不只是研究人员，（4）弥合研究间的差距，获得洞察，并将洞察应用于客户产品。
说到第（2）点，“大项目需要大团队”，宝马的大多数管理层都有机械和电气工程和制造业的背景，他们错误地将软件研发视为一个生产问题，而不是研发问题，在生产过程中，更多的人意味着进展更快。但是，在软件研发中，增加大量的人而不是合适的人，会恶化问题和阻碍进展。因此，这是自董事会层向下的另一个缺乏现代和大规模复杂软件管理专业知识的迹象。
以下章节重点讨论组织、政治和人的障碍以及导致这一有挑战的技术环境的系统动态。还包括并讨论了解决这种情况的一些想法和尝试性建议。
在LeSS转型之前，有150多个代码仓库和数百个分支。如前文所述，各组以项目制和组件团队的方式工作严重影响了代码库的设计和仓库结构。
管理层和开发人员缺乏现代大规模开发经验的另一个迹象是，他们没有意识到当不同的团队必须合到一起并交付一个共同的产品时，众多仓库和分支会导致许多问题。以前多个项目和组件团队的模式由于延迟集成也就延迟看到了这一问题。
幸运的是，新的ADD部门早期行动之一就是对产品进行定义。单一产品的定义开始使各小组形成一体，并为一个仓库和一个分支创造了动机。导致决定一个仓库和一个分支的主要需求是：
- 将工作重点放在产品上
- 否则里程碑将受到威胁
- 法律要求和修正案的持续实施
- 否则产品的销售不合法
- 业务和用户体验需求的持续实施
- 否则产品卖不出去
选择的版本控制工具是GIT，“一个分支”就是指“主分支”。仅工作在主分支（相当于许多工具中的主干）上的实践被称为主干开发。
然而，仍然存在一个主要的延迟集成问题：之前，两个组分别关注L3级和L4级驾驶。考虑商业风险管理，L3级功能首先需要可靠，因为愿景是至少提供L3级AD，因此它在产品待办列表排序上有着更高的管理关注度和影响力。尽管如此，许多管理者意识到，如果L4级开发被抛弃，在市场L4级竞争上就将输给竞争对手。因此，两者被并行跟进。我将在合适的章节中探讨这些对立的心态，及其对集成 - 并且在更广泛程度上对产品开发 - 的有害影响。
ADD单一产品定义带来的仓库和分支合并所产生的活力也推动了其与宝马集团内部其他部门的分离。
这种分离显示出管理者希望彼此区别开来。从其他管理者的角度来看，ADD管理者创建了一个超级部门，该部门吞噬其他部门 - 也就是这些管理者的部门。部门缩减通常是为了产品和高层的利益，但很少是为了这些部门（中层）管理者的利益。因此，一个/更广泛的产品定义的附带结果是，其他部门的经理需要区分自己，例如通过在其部门局部优化以有理由继续存在。
例如，负责人机界面（HMI：车机屏幕、HUD抬头显示、方向盘、广播按钮等）开发的部门认为，他们也有其它车型项目的客户。因此，他们的管理层主张（1）集中设计是“最优的”（当然，实际上是一个局部优化），（2）分离设计团队并加入ADD团队会破坏他们的多个人机界面项目，以及（3）如果设计团队分散，则每个项目的时间计划都会有风险。不用说，这个传统的人机界面和设计部门与宝马集团的许多其他部门一样，组建起来的目的是控制供应商的设计、用户体验研究以及相关软件和硬件。
宝马集团组织车型开发、车型制造和车型项目的方式也被各部门用来声称他们独立于ADD的产品愿景。潜台词是，任何“超级”部门都不应改变或挑战已经存在的（局部优化）现状。
由于整个系统部门间协作的组织设计是董事管理层的责任，而且董事管理层显然不理解现有系统对于ADD的成功是存在问题的（因此没有改进），这说明董事管理层也不具备管理大型复杂软件的知识和技能。他们可能继续将问题视作是需要他们传统的供应商管理模式。
将研究结果集成到产品和产品代码中对于ADD来说很重要，因此ADD维护了几个这样的研究项目。
管理者决定这些项目使用单独的仓库，因此集成的时间很晚。管理者决定这样做的一些原因是：（1）研究成果是否纳入到产品中有高度不确定性，（2）有一些非宝马集团的研究人员参与；因此，管理层限制了无关宝马集团代码的数量，（3）研究代码中的软件设计和代码质量差得令人无法接受，（4）研究人员使用不同的编程语言。
较晚集成的一些后果是：（1）不同的概念，（2）对后续算法、数据结构和评估的影响，以及（3）对研究代码解决问题的理解及细节存在很大差异，这导致了在集成以及对软件设计修改有很大挑战。
在宝马集团，一种常见的方法是为每个合作伙伴（取决于合同协作级别）将代码库分割成多个片段（一个片段=一个仓库）。ADD管理采用了这种幼稚的方法。这带来的问题有：（1）它强调符合现有（传统）合同模型，（2）因此，它局部优化于合同，而非产品成功或端到端协作，（3）为了优化于传统的合作伙伴-合同模式，有效集成和协作受到影响，以及（4）需要适应性协作和频繁集成才能取得成功的整体解决方案受到严重损害。所有这一切都表明，缺乏现代大规模适应性开发实践经验，缺乏对这一举措的复杂性、所需的协作和集成以及仓库管理实践的理解，高级管理层更关心“好”的合同而不是工作软件。
尽管现在有“一个产品”的定义，但由于管理层和开发人员缺乏洞察力和经验，他们继续延迟集成，并为各种组件和“项目”创建多个仓库或分支。
例如，数据中心和数据检索相关组件长期未与常规产品开发进行集成。这影响了数据中心和处理集群的数据检索和再处理能力。由于未集成，用于验证或仿真的大量数据处理无法进行，因为存在不兼容数据或无效数据（较晚集成导致集群处理存在过时代码）。
只有在这个问题非常明显之后，开发人员和管理人员才开始整合代码和人员。然而，将员工转移来处理这些自我造成的创伤 - 又一个速效方案 - 阻碍了管理层思考人员的合适组织和根本原因，因此，ADD的员工规模甚至增加了更多。
高层的愿景是，ADD是一个可以提供给众多汽车主机厂的平台。考虑高研发难度，以及宝马及员工以前并未有相关经验，这其实是投资者和管理层的一厢情愿。
无论如何，一厢情愿的想法还是赢得了胜利。管理层决定将平台依赖（=供应商特定）代码和平台独立代码拆分到各自的代码仓库，因为管理层和开发人员不了解或不具备在架构上分离代码而只保留一个仓库的软件技能。这样拆分造成了包括ADD在内的所有参与主机厂更为复杂的开发和延迟集成问题。
第一个需求领域是从2021要发布代码库的一个子集开始；它也只包括第一批伪志愿者。甚至在转型开始之前，管理层就决定了人员升级，也被称为组织切换。管理层明确表示，任何员工在完全加入转型后，以前有效的东西现在也应该有效，否则这些员工应该留在旧的组织架构中。这导致了多个几乎没有对齐的仓库（代码库）的仓促合并。除了催促开发，管理层将如何实现这一目标的具体方法交给了开发人员。
由于这一管理指示和催促“加快”，出现了瞬间大爆炸 - 先将所有仓库同时合入一个仓库中，之后再整改对齐。该方式是基于复制旧构建系统中的步骤，然后将构建工件拼接在一起。这种“拼接大爆炸”方法并没有为统一软件设计或不一致的概念创造出时间或者兴趣，而只是推迟了这些关键问题。这将在以后导致许多问题，呈现了经典的常由管理团队推动的“快即是慢”的动态。
首先，一些广义的背景和影响：
如前所述，大多数开发人员都是ADD的研究人员。这影响了他们对软件设计的选择。起源于个人英雄主义的环境，例如获得博士学位，他们对开发的自然掌握是孤立的。这导致了大合并之前有许多仓库。
另一个影响因素是：作为大公司的一部分会影响思维方式。其中一种是由于沉没成本而坚持弱解决方案。
更多的上下文：（1）代码库需可维护20年以上，（2）法规要求影响更新周期，（3）传感器的变化性，（4）不同主机厂之间协议和语义元素的可变性，以及（5）正在进行的研究和实验。
ADP的一般架构方法是基于规则编码。特别是与其他重要的供应商及他们宣称的成功、失败以及他们越来越关注接近“100%”的机器学习（“AI”）自动驾驶方法相比：为什么ADD坚持传统的方案？
大多数开发人员的起始是做研究。他们（德国）的学术经验倾向于深入地工作在某个假设上，并注重个人的卓越。这培养了毅力和奉献精神，但也造成了思想狭隘。这导致减少了解决自动驾驶挑战的选项。有些选项是机器学习或者规则编码与机器学习的组合。
为什么管理层没有更严格地质疑当前的方法，尤其是因为全球行业领导者越来越公开强调，他们学到的一个关键教训是关注端到端的机器学习？
首先，大多数管理者都被自己（德国）的学术生涯蒙蔽了双眼或带有偏见。
其次，他们对研究人员有过度的信任。只有少数管理人员具有大型、复杂和自适应软件开发的经验，也只有少数人具备学习这种经验的必要背景和技能，大多数不愿意真正访问实际工作地点，查看代码并了解软件细节中的真实情况（参见缺乏对现场观察的理解和驱动力）。这些因素加起来导致了相信员工，特别是那些拥有学位的员工，是在实际创建大型复杂软件和AD设计方面的专家。由于缺乏和不愿质疑他们的“专家”，他们只是附和。没有质疑现状和“专家”，或是去调查外部有经验的专家在做的工作。
第三，一些管理者确实怀疑过所选择的路径是否正确，但没有设法挑战内部权威或他们的同级管理者、认真探索替代方案。导致他们没有对怀疑采取后续行动的原因是多方面的，没法在此进行全面讨论，因此主要是猜测。但管理者不对现状拉响警报，以避免争议或损害他们未来的职业前景，是商业上的一种常见模式。
第四，想想管理者是否曾经想过采用机器学习的方式。哪些员工能够进行产品的实现，以及对时间线有什么影响？没有人有这样的技能和经验，而且“要花的时间太久了”。早期的技术教练之一Craig Larman认识到人才的缺乏，很早就向高级管理层建议了一项风险缓解战略，启动第二个平行计划，由花钱可以雇佣到的最优秀的全球专家组成，包括机器学习专家，但遭到拒绝。
考虑到许多开发人员都是来自一个崇尚英雄主义的学术环境的研究人员，他们的论文中绝大多数都是基于规则编码的解决方案，相比花精力探索机器学习架构的截然不同方法，拒绝替代方案要容易得多。
为什么拒绝替代方案对开发人员来说很容易？研究人员因为专业知识而得到认可。建立足够的专业知识来质疑一个常见的方法需要时间、机会和奉献精神……这些在公司里的竞争环境中很难找到，尤其是在命令与控制的组织结构中以及不崇尚探索替代方案的个人奖金系统中。允许一个另类的外部观点几乎等同于承认自己不是“专家” - 这是大多数学者所避免的。
为什么ADD只考虑他们的“专家”（研究人员）意见，而不考虑更具现代技能的软件开发人员的意见？在传统工程领域成熟且成功的公司将自己视为专家。去询问顶尖的外部人员挑战了他们的自我认知。
管理者的典型思维是：待的时间长的员工为长期产品提供坚实的论据，因为他们必须坚持长远的决策。这种想法是被误导的，因为决策与员工时间长短之间的联系是错误的。员工通常有其它强烈的理由留下来，例如家人、朋友、当地关系和公司附带福利。如果预算和管理人员允许，外部人员也会选择留下来，外部人员因而比内部人员更能体现明智的战略。
为什么ADD没有雇佣最顶尖的软件开发人员？顶级开发人员倾向于（1）自我管理的工作（管理人员的干预非常有限），（2）与其他优秀开发人员密切合作，（3）有目的地工作，（4）为了被认可而工作，以及（5）不愿意为传统和软件技能不强的管理人员工作。
将软件设计方法与招聘过程进行类比会有一种意想不到的效果。宝马集团拥有完善的人员配置和招聘流程。通过宝马集团的董事管理决策将AD开发作为紧密相连的部门运营，ADD继承了这些招聘流程。
招聘过程中的基本组成部分包括与将来可能共事的同事进行面试和编程。面试官和编程题目的选择在如何增强或削弱软件工程和软件设计方法的多样性方面起着重要作用。想象一下，一名候选人被一名具有资深传统、非OOD和非机器学习思维的宝马员工面试。任何具有很强OOD或机器学习技能的候选人都会提出对立的设计建议。此外，如果编程题目是为了测试基本编程技能，而在大规模设计或应用OOD或机器学习上没有挑战，那么候选人会得到这样的印象：ADD没有足够的挑战，也不是一个能在里面成长的地方。
现在，ADD确实有一些研究人员在机器学习和相关基础设施方面有一定的学术关注。他们也被聚集在一个机器学习社区中。但要想有所作为，他们需要有充分的证据（来自数据）。产生强有力的“证据”需要大量的时间和精力，但持怀疑态度的管理者无法提供支持。
最后，在德国，关于基于规则编码vs机器学习算法的整个讨论被尚未明确的法规所掩盖。不清楚是否允许机器学习做出驾驶车辆的决定。在目前的情况下，宝马集团经理的方式是遵循传统方法，因为担心不明确的法律后果。
在一个产品、一个仓库、一个分支之前的许多独立代码库复杂化了协同组件的创建，并延迟了集成。由此产生的集成噩梦通过许多修改、修复和临时操作得以解决。大多数这些“修复”在集成阶段一完成就被抛弃了 - 大多数开发人员忽视了这些“修复”，因为它们对组件的核心能力并没有什么贡献。
集成挑战的根本原因之一是不同的概念、想法和软件设计，而这又是在转型之前的体系所造成的。在仓促合并仓库的过程中，这些问题都没有得到解决（请参见仓促合并仓库）。
为什么管理者没有解决设计问题？他们的主要关注点是让所有开发人员再次进入直接的专业（和职能）控制，这意味着关注将断开和不同的代码连接起来，而不是和谐一致的设计和概念。此外，这些管理者由于现代大型软件开发经验有限，对解决这些难题有些过度自信。
为什么开发人员没有解决设计问题？ADD的大多数开发人员的指导原则是他们的组件，因为正如所讨论的，他们大多按组件团队而组建，没有合作创建有紧密结合大规模产品的经验。
宝马集团过去将其大部分软件开发外包。ADD是宝马公司第一个现代化且真正大规模的开发。因此，ADD提出方向性的问题以驱动良好的长期软件设计的经验和能力都很有限。
为什么设计好的软件产品需要提出好的方向性问题？这些问题引发并界定了产品的当前和未来使用、当前和未来的灵活性、当前和将来的挑战。拙劣的问题分散了时间和精力。通常，只有通过经验、领域洞察力、多样性、足够的预见性和对市场的把握，才能将好的问题与拙劣或没有帮助的问题区分开来。
哪些系统动态会导致ADD提不出好的方向性问题？非常强调外包软件相关的工作造成了这种能力的缺失。宝马集团试图分析问题领域，将问题分解为子问题，并将其交给供应商。这带来的影响是：（1）通过将问题空间分割成更小的块，失去对原始问题跟踪的风险是巨大的（特别是当自动驾驶的成熟整体解决方案实际上还没有找到），（2）丧失了从“更底层”领域来解决原始问题的机会，（3）拆分导致次优解决方案，（4）拆分导致狭隘思维模式。
“绿色构建”是（1）完成的集成，（2）完成的自动化代码质量检查，没有任何错误，以及（3）完成的所有规定的测试（单元测试、集成测试、集成试验、（子）系统测试），没有任何错误。因此，“绿色构建”指标表现了组织的持续开发产品能力、以及为学习和适应提供强大且重要反馈，和……潜在收入的能力。
在开始转型之前，各个组按独立的工作组织（图24），这反映在他们的代码库和构建系统中。他们只是简单地将构建工件缝合在一起，由于集成问题只是偶尔能运行。
关键点：并不是每个组件构建或分段构建就会导致有短反馈的敏捷端到端开发实践。
随着代码库的仓促合并（仓促合并仓库），构建系统随之必须进行更改。这暴露出构建过程、工具和基础设施的不一致性。
缺乏技能的另一个迹象是难以建立新的有效构建系统。花费了好几位外部专家和软件产品开发的资深人士才让大家理解到，在宝马集团的一些管理人员中根深蒂固的“不要对能运行的系统进行改动”是最确定（如果不是最快的话）的陷入僵局的方法之一，构建系统也是如此。
一个好的构建系统的关键是：它能提供关于产品集成的快速反馈。即使是用了多级构建。
为什么PO、APO和管理层坚守陈旧不足的构建系统？部分原因是宝马集团的管理层习惯将一切都视为一个项目。按项目方式意味着从以下方面进行思考：开始、结束，中间没有任何东西。这种想法不鼓励频繁反馈，因此快速集成反馈的想法被视为浪费。
为什么开发人员没有采取任何行动来改进构建系统？有几个方面在起作用：（1）个人激励计划（IPA）不支持此类活动，除非事先说服了管理者，（2）开发人员被按照独立工作进行优化，（3）开发人员被分配的是任务细节而不是产品需求，（4）大多数都不是真正的开发人员，而是关注在学术问题上的研究人员（5）只有极少数开发人员体验过好的构建系统带来快速集成反馈的乐趣。除此之外，（6）与其他小组的交流主要是在研究主题上，而不是产品开发相关。
为什么管理层在集成产品开发方面没有更多的指导呢？首先，宝马集团的管理层从部门而不是产品的角度思考问题。即使是车型项目也以，（1）项目和（2）哪个部门在做，来思考。只有在几次CLE培训后，ADD才开始有所改变。在转型开始几个月后，ADD的副主管开始坚持在车上评审迭代成果，这使“构建和集成”社区得以启动，来寻找替代旧构建系统的更优方案。
负责将代码集成到车辆的一个接口部门正在尝试Bazel，因此，Bazel是替换旧构建系统的主要候选。
概念验证是悄无声息地被完成的，这意味着它不在产品待办列表中。为什么要这样做？
在一个健康的Scrum和LeSS的环境中，产品待办列表由改进和需要实现的条目组成。当时，将任何内容都纳入产品待办列表的过程受到以前工作模式的严重影响，即：项目需求、项目经理和非常特殊的非开发个人贡献的条目。
此外，在一个健康的Scrum和LeSS的环境中，除了有关特性和产品的影响之外，不需要与PO、APO或经理讨论技术细节。因此，产品待办列表中无需建立所谓的重构或者技术细节的实验条目。
为什么团队要寻求APO对此类技术工作的批准？在重研究的环境中，同行、APO和管理层都非常需要合格的数据来证明一个观点或开始一种方法。产出合格的数据非常耗时，在评估替代构建工具的可行性和缺点时，需要开分支和迁移代码库的相关部分。这不是每周花一个小时就能完成的事情，而需要花团队的很大一部分时间。当需要花“很大一部分”时，宝马集团的公司文化是需要“更高”管理层的批准。在大规模Scrum环境中，(A)PO看起来像是一个更高的管理层，即使这个(A)PO不应该涉及技术细节。
将这些研究和探索任务单独放在团队的迭代待办列表中，而不是放在产品待办列表中去体现透明度，会产生什么后果？通常，小型研究和重构任务只存在于迭代待办列表（而不是产品待办列表）中，没有任何麻烦；因为在大规模开发的背景下，每次迭代永远都有些小任务，把它们纳入产品待办列表只会给PO或APO带来许多小噪声。另一方面，如LeSS指南“处理特殊条目”[3，第207页]中所述，大型“工程改进”或涉及重大投资决策或有学习收益的研究型任务，或能够给团队创造有益冲突讨论的条目，都值得纳入产品待办列表。这里的区别在于（1）变化的幅度，（2）对变化的熟悉程度，以及（3）对公司流程的影响。在这个领域的变更并不常见，因此需要工作于这个条目上的人额外学习。绕过产品待办列表缩短了正常的学习、验证和改进机制。这样“不跟APO说”并将这些任务放入产品待办列表的结果是延迟、失望、沮丧和更大的混乱。
为什么团队认为让这个实验偷偷进行而不是放在产品待办列表中是个好主意？ADD的PO和APO重点关注增量特性，而不是整体产品。这两者有区别吗？*就产品而言，没有区别；就与上层管理层、董事会、市场营销部和其他部门约定的产品特性清单而言，特性与产品之间存在很大差异。*换句话说：当时ADD中的APO对产出单个特性进行了局部优化，而不是一个可行产品中的特性……这只有良好的构建系统才行。
不同之处在于，当时产品待办列表中几乎没有“特殊条目”。产品待办列表中增加潜在条目的过程仅针对特性相关条目而设计。因此，开发团队担心的是，如果他们开始为这个特定的实验条目与APO进行讨论，这些实验条目会被推到SoP之后考虑，大约是当时的两年之后。另一个经典的“快即是慢”动态，当目标是适应性时，管理层不了解现代构建系统或大规模软件的现代构建，加剧了这种情况。
这种情况还突显了技术变革和组织之间的牵扯，没有充分利用社区的理念，以及将团队使用率达到100%的错误做法（见“避免……通过增加并行任务或利用率带来虚假的队列减少”[1，第99页]）。后来，SM在团队的支持下，通过推动社区来贡献产品待办条目，PO和APO最终听取了他们在与其它产品待办条目之间如何排序的意见。
在分别向各个APO展示了一个实验性构建系统的有希望的结果后，大家的兴趣提升了，但由于初步估计需要2-3个迭代才能完成迁移，因此没有创建产品待办条目并进行产品待办列表梳理来改善估算。应该记一笔APO的功劳，他们相信了开发人员；但是他们没跟开发人员确认对范围、流程集成、对运行环境的影响、迁移工作量和整体基础设施的理解 - 尽管估算明显偏低。
因此，没有APO将构建系统实验当成重点。结果是没有任何团队专注于构建系统实验。只有来自不同团队的一些开发人员加入进行相关工作。这一次，一些APO说随时将情况告知他们。
问题的积累在某个时候引起了“真正”的管理层关注。管理层最终认可给予更果断的支持，这引发成立了三个专注于以下方面的临时小组：
- 从catkin和cmake到Bazel的完全迁移
- 提升构建速度
- 将构建的可靠性稳定下来
关键点：避免创建新的（临时）架构；给现有团队提供重点关注和能力，以及支持。
通过将这些任务分配给临时工作组而不是长期特性团队，管理层限制了组织的学习。在一个健康的LeSS环境中，遇到新课题时特性团队将邀请专家加入，并向专家学习，以便特性团队能够维护系统，甚至自己改进它。专家可以是外部专家也可以是内部专家旅行者。
为什么管理层要以各个特性团队的成员来配备那些临时小组？APO在他们的IPA中承诺了在发布时交付哪些特性，如果某个完整的特性团队专注于改善构建问题，相应的APO就无法完成其个人绩效计划。
此外，组建临时工作组的行为也体现出了经典项目管理的思维模式，即“让专家来解决问题”，这只能短期解决问题。相反，LeSS建议采取为长期解决问题创造相应条件的路线。
一个有趣的动态是，大多数开发人员都没有想过为解决构建问题做出贡献。其原因主要在于之前的组织体系。在此之前，各自的责任和义务有着很强的分割。团队A负责道路建模，团队B负责制动，等等，也有团队Z负责构建脚本；甚至有一个完整的部分专门负责构建相关问题。这强化了“这不是我的工作”的思维。
因此，开发人员开始接受其同事在构建领域的建议是很了不起的。这反映了公司文化的转变：接受同行提出的建议至关重要。
从LeSS的角度来看：这表明了在尚未完全转变的公司文化中承担责任的困难。引入社区用于多团队层面的自我管理已经（并且仍在）在进行中。
鉴于构建既不是产品特性，也不是产品中的技术细节，那么由谁来负责以及为什么他们没有采取行动？管理者有责任创造让团队有能力构建产品的环境，并负责移除团队能力范围外的障碍 - 因此，管理者对构建负责。
过去，许多宝马集团的经理将此责任外包，因此失去了改进构建系统的洞察和能力。一些ADD的管理人员对构建非常关心，但在安排任务上却很艰难。为什么会这样？ADD刚接触团队自管理的理念，因此在如何处理此类情况上面临困惑。挑战包括（1）谁负责检查构建系统的问题，（2）在哪里报告这些问题，（3）谁负责提出并最终确定解决方案，以及（4）如何实现解决方案。
这种艰难源于旧的组织制度、其正式架构和它所培养的公司文化。传统上，会指派管理者；在新的模式中，感兴趣的人会自己察觉并做出反应。LeSS倡导“社区”的结构元素，以支持跨团队层面的自管理。“构建和集成”社区是在转型开始后几周成立的。尽管如此，公司文化的转变仍在缓慢，这导致了其它一些后果，更多内容见第社区章节。
绿色构建的另一个关键在于实际代码、其结构和测试使用。在一个不断修改代码库的环境中，需要重点关注其结构、可读性和由此带来的易懂性，和易修改性。好不容易有了初始代码库之后，ADD在结构、可理解性、易修改性上也都没有现成的。
组件团队缺乏技能来协作和演进一个良好的总体设计，由此创建出的高耦合组件让创建真正的单元测试、真正的组件测试和真正的组件构建都变得复杂。结果导致了运行时间长且容易出错的构建和测试。已经尝试过几种技术方法来解决这种情况，但都失败了，因为它们都没有解决根本原因。
为什么更多的关注是在组件上，而不是在协作或者整体产品上？答案各不相同，但通常是（1）传统激励，以及（2）类似研究中对单个主题的专注和精通，在这里的主题就成了组件。
为什么管理层没有要求关注组件协作和产品？管理者并没有直接禁止必要的深入改变，但他们提供的环境几乎没有给深思熟虑、重新设计代码库和测试留下空间。另一个经典的“快即是慢”动态，在目标是适应性的情况下，由于管理层不了解现代构建系统或大规模软件的构建，加剧了这种情况。
如果是懂技术且能管理复杂状况的经理会阻止或解决这种情况吗？这个问题本身揭示了对系统动态的严重误解：技术（使用技术实现某个想法）只是动态的一部分；人员、组织和流程都是重要部分。因此，问这个问题已经偏离了合适的解决方案。题外话：这个问题也揭示了他们（1）缺乏现场观察，（2）缺乏现代大规模适应性开发的经验。
ADD的开发人员在大规模开发方面经验有限，而且在熟练设计大规模软件系统方面经验也有限，因此他们在单分支上开发很艰难。他们过去的工作结构促进了各自在单独的代码库（和仓库）上工作。仓促合并仓库并没有改变开发人员的基础经验，因此数百个团队继续艰难地在一个分支上工作。
无法在一个分支上有效协作导致了许多长期存在的分支。为什么？首先，旧系统促进追求在组件上个体卓越，导致了代码库的孤立。与一个单仓库内有多个孤立代码库最相似的就是长期分支。其次，大多数开发人员实际都是研究人员，而不是程序员。这导致在设计、编码、增量开发软件以及通过代码进行有效沟通与协作方面缺乏技能。
缺乏足够的经验丰富的现代化开发人员，导致在自我训练如何对大型代码库进行单分支增量开发上系统性的能力缺失。
在将这些长期分支合并到主分支时，产生了巨大而复杂的补丁（参见图26），这给已经高负荷的构建系统带来了挑战。为什么？前面讨论了缺乏组件构建和测试，导致了每次都要进行整个系统的重新构建和重新测试。由于小组先前关注的是组件而不是单元，因此许多测试都需要运行基于耗时仿真的验证测试。
运行时间长的构建也是长期分支存在的原因之一。为什么？由于从push到red/green的平均周期为4-8小时，许多团队采取了一种作弊方式，即在其长期分支上积攒了许多提交，然后每个迭代完成时将它们一起合并到主分支。这显然是一场灾难。
这些复杂的、大批量、每个迭代一次的合并后果之一是频繁出现红色构建。为什么？当几个长期分支合并到设计粗糙的软件系统中，就很难避免/解决冲突，因为组件的设计不一致都会暴露出来。每次合并冲突都需要手工修改并重新合并到主分支，这将再次触发相同的情况，只是少了一次提交。
在组件团队和管理行为的影响下，许多开发人员具有“不对产品负责”的想法，导致构建系统被迫执行大量的合规验证及可行性测试。因此，产品级大规模开发的规则（图27）和良好开发实践没有被遵循。这导致管理者快速修复系统 - 通过为每次构建引入强制性自动构建步骤来检查合规。为什么每次构建要这么做？传统的管理思想要求为失败分配责任，因此每个失败都需要具体到一个人。
宝马集团的文化是避免“失败”（在构建以及其它方面），并将失败视为一个问题，而不是一种快速失败、然后从“失败”中学习的实验文化。
管理层对构建问题的一种应对是引入一个轮换的构建警长（经理）角色。该速效方案导致了团队对问题的距离感增加并推卸责任给该角色。为什么？
构建的时长及谁对问题负责会影响团队对提交结果的关心。因此，随着构建周期的延长和构建警长的角色，团队对结果的关心以及责任感也随之降低。
降低了对构建结果的责任感导致构建的质量快速下降。这与分配一个构建警长的天真干预所预期的效果恰好相反。
责任感降低带来的影响随着团队数量的增加才变得明显。当只有大约8个团队时，团队之间还可以的社交连接防止了这样的动态。但随着团队数量的增加，更弱的社交连接和上述讨论的动态就变得明显了。
无论是经理还是开发人员都没有认识到，将警长/经理（或工具）置于责任和团队之间会降低整个产品的主人翁精神和责任。
透明性和指责之间的界限很薄，当构建显示器突显出在构建失败之前最后提交代码的那个团队时就容易过线。正式说法是“停止并修复” - 破坏构建的那个团队（基于构建监视器上的由绿到红转换）一直修复到构建再次变绿。其目的是为了提高透明度，减少每天收到的电子邮件数量。非正式下，所有关心构建的开发人员都会对一个损坏的构建没有尽快修复感到恼火，并希望能有更多的公众压力来促进修复损坏的构建。
归咎于某个团队并不能解决根本原因（缺少整体产品焦点），只是突显了系统的复杂性、来自构建系统延迟了的反馈、开发人员关注组件而不是产品、软件设计不足以及缺少有意义的组件构建和测试。
归咎于某个团队引发了另一个有趣的动态：当第一个团队“A”（无意中）触发了从绿色变到红色时，其他团队在此时增加了合并和推送的频率。为什么？首先，由于构建系统上自动合并的过程很长，有时甚至是非线性的，团队A可能不是造成导致变成红色的原因。不管怎样，通过将责任归咎于团队A，其他团队提交代码，掩盖在对团队A的责难中。他们并不害怕承担构建可能出现降级的责任，因为构建此时已经是红色的。这促进了延迟提交代码的做法，直到有第一个团队被归咎。
通过引入一种技术体系来归咎，这种动态导致了一种更加封闭的局面。有时，在忽略构建状态的开放阶段，跨团队的协作和代码方面的集成是惊人的，而有时则整个系统都是阻塞的。
很少有人听从传统管理层发出的“停止工作”直到构建恢复的天真呼吁。ADD的经理们很快意识到，停止一切工作只会使情况恶化，因为代码变更会在长期分支上累积。此外，让数百个团队停下工作的成本高得令人望而却步。丰田“停止生产线”理念的推论 - 修复根本原因 - 并没有被ADD的经理和开发人员所意识到。
所有上述实验、流程和技术支援都关注于“非红色”；但都失败了。为什么他们失败了？他们没有关注在重要的事情；相反，他们专注于避免短处。
为什么ADD没有更多地去增强员工内心的“在意”和培育员工“对产品的责任感”？
在众多原因中，有几个关键的系统性原因：（1）ADD作为宝马集团内部一个部门，董事层在设计组织时受到局限（例如，公司外包理念及其影响、公司文化“注重细节（组件）而非整体（产品）”、采购流程、供应商合作模式、人力资源政策），（2）员工组成、由此产生的态度和跟公司文化的匹配性，以及（3）各级人力资源和供应商合作政策不变。
没有改变的人力资源政策 - 以组件和专业为重点的个人奖金体系 - 与大规模、适应性产品所需的技能相矛盾。大型、复杂和自适应系统的现代产品开发的关键不再是单一焦点的执行卓越，而是针对产品目标进行快速适应的多面学习/技能。HR经理属于ADD外的独立汇报线，他们放弃了产品成功为基准的奖金制度；他们仍然度量并奖励个体经理与员工的局部优化，而不是全局优化。
没有改变的供应商合作策略带来和过去一样的无意识传递任务的执行方式。ADD不认为有可能改变采购流程，而是引入了一个新的中间人角色，来试图快速修复不熟练的合作。
董事层的严格管控造成了另一个局限。ADD被作为宝马集团内的一个部门来运营，但仍留有其它选项。例如，可以有不同的工资体系、独立的人力资源政策和更自由的流程。但是，董事层不允许在他们的组织内做这种层级的改变。
依照“过去亦是现在的一部分”，许多团队要求制定正式的跨团队决策流程。这反映出大型组织的行为变化受到组织结构变化的影响（Larman法则5)，但与组织结构变化不同的是，行为变化不会立刻体现出来。这种（暂时的）需求产生了“授权社区”和“强制社区”的概念。这两者都与自愿的理念和社区的定义相矛盾。解释：授权社区可以做出整个开发团队的决策（这与“社区不能为团队做出决策，但他们可以产出东西由团队决策采用”[3，第296页]相矛盾）；强制社区要求所有开发团队必须有代表参加（这与“社区参与是完全自愿的”[3，第295页]相矛盾）。
为什么自愿参加在社区中具有重要意义？（1）在自愿参加（或至少不是强制）环境中，分享和学习、高价值协作和贡献的开放度高于强制环境，并且（2）自愿的成员更愿意分享和解释建议，更愿意根据实际团队和使用情况调整建议。由此得出的推论是：如果管理层认为有必要回到强制的方式，那么一致性检查（如合规构建）、流程的合规委员会、新标准的明确公告等方面的投入就会增加。
授权社区示例：软件架构社区和构建和集成社区；强制社区示例：仿真社区。
为了使授权社区的投票“有意义”，引入了“核心成员”和法定人数的概念。为了使社区会议“有意义”，指派了一位主持人，并提前发送按固定时间表制定的议程。为了使社区“具有重要性和意义”，正式任命了一名经理，但他从未到场。这些“社区”的结构在很大程度上让我们看到了宝马集团旧的的经典工作组的样子，只有一个不同：没有经理在场。在最初的几年里，开发人员对决策的遵守程度很低。
为什么开发者的遵守程度很低？因为突然从自我管理转变到基于“授权社区”的权力驱动模式，与团队内部慢慢进化为自我管理相冲突。团队越是意识到自我管理团队的自由、责任和义务，对命令式的“授权社区”的不满就越大。
是什么导致许多开发人员渐渐离开社区？社区越来越被视为正式讨论和决策的场所，而不是学习和达成跨团队（职能）约定的场所。PO和APO缺乏全面产品指引也导致了这个情况。在需求领域的组建和重组过程中，团队从一个需求领域转移到另一个领域。有时，某个社区的成员大多数来自一个需求领域。这无意中把话题引向了该领域，这使得接受社区作为跨团队和跨领域学习与协作的场所变得更为复杂。授权社区的强制参加这个速效方案只解决了有人代表的问题，而没有解决许多开发人员缺乏整体产品焦点的根因。
社区及其决策的一个重要的次要方面是ISO9001。几十年前，宝马集团为整个集团采用了ISO9001过程标准。该标准的基本思想是记录重要的过程决策和相关需求。ADD的“辅导与规范部门”错误地认为“授权社区”会做出此类决策。因此，“授权社区”的存在本身就使ADD的质量和流程改进过程变得复杂。
为什么ADD的“辅导与规范部门”犯了这个错误？社区与宝马集团传统工作组的相似性及其正式决策权在其中起很大作用；从外部不了解LeSS的审计师角度来看，这些结构被重新标记为管理驱动但缺少经理加入的工作组。因此，“授权社区”的存在和定义以及宝马集团对ISO合规性的要求导致了如下流程：授权社区的一些决策与ISO过程变更相关，因此需要以不同的方式记录、跟踪和跟进。
这个错误是如何使质量和流程改进过程复杂化的？这如何让改进复杂化有很多方面：（1）添加的“纸面”流程增加了想法与效果之间的脱节（类似于延迟反馈效应），（2）改进想法与实际改进之间的距离增加，使潜在贡献者退出，以及（3）正式的流程不利于进行改进实验。尽管“辅导与规范部门”努力使其尽可能轻量级和不引人注目，但有可能要走流程以及这些流程知识让许多开发人员对提出改进建议丧失信心。
为了有一个更好的参照系：只有一小部分由授权社区制定的决策和流程与ISO相关；回顾会和整体回顾会的改进实验通常与ISO中的流程变更无关。例如，提交消息及其格式中的必填信息、物理单元的必填数据类型、测试工具、文件夹布局和文件命名约定。
ADD继承了宝马集团的许多人力资源政策，尤其是奖金和职业发展政策。其中一些政策影响了社区的数量和质量。
图28显示了产品、组织和员工价值之间不那么显而易见的冲突。
图28的一些额外背景：在宝马集团，工作组和研究组是常见的。这些都体现在公司关心和感兴趣的话题上。通常，引导者是经理（或在管理职业路径上的人）。因此，作为一名引导者对职业发展、个人奖金和工资水平都有影响。
在LeSS中，社区是学习和协调的新兴结构，创建、更改和删除社区的障碍都很小。这种不受限的流程加上没有改变的人力资源政策、考评流程、职业发展模式和个人奖金制度，开启了一个导致越来越多“社区”的动态。
为什么？由于HR没有对职业发展或奖金制度做出任何改变，一些开发人员试图将旧模式映射到新模式。他们将社区视为类似工作组的东西，而工作组是旧模式中职业发展的重要检查点。
ADD中并不包括产品的所有方面，例如硬件架构。因此，需要特别关注非传统的ADD组织结构与传统宝马集团组织结构之间的接口。
硬件相关架构方面的工作从第一个需求领域开始，来自旧架构团队的两名架构师分别加入了两个不同的普通特性团队 - 实质上的领头羊团队。计划是成立一个社区来支持跨团队和区域的学习。
这种方法（架构师作为团队成员）在早期阶段失败了，原因有几个方面：（1）在早期迭代中特性团队的条目没有涉及硬件相关架构，（2）作为特性团队成员的架构师仍然大量参与在宝马集团的架构团队工作中。
为什么在早期的迭代中，这些领头羊团队没有硬件相关的架构条目？在转型前，ADD是从车辆原型和仿真开始。一些细节尚不清楚，但已经做了重大决策，因此伪PO（真正的PO后来才加入）优先排序了非硬件架构的主题，例如软件架构相关和其它特性。
如果在他们团队没有相关条目，为什么架构师团队成员还被占用着？在宝马集团内部，架构组是一个先驱、事件和决策的网络。因此，ADD作为与整个公司关联在一起的一个部门，通过成员加入并积极贡献保持密切联系至关重要。这导致架构师团队成员在实际的ADD团队中只花费了一小部分时间。
ADD管理层很快将与硬件相关的架构责任交给了一个专门的“架构专家团队”。该团队的额外责任是与各团队建立连接进行分享和学习。澄清一下：这个团队没有义务实现特性或工作于产品待办列表，只关注“硬件相关架构”。
与软件相关架构（例如软件设计）相比：在软件这边，更多的开发人员从一开始就是自愿参与。他们成立了“软件架构社区”，但很快转变为一个授权社区。只是在几年后这个授权社区的一些核心成员才被调入新的“软件架构专家团队”。这是一个管理者意识到团队缺乏软件设计能力、以及产品待办列表排序存在不足，所采取的速效方案。
其后果之一是，大多数特性团队低估了与硬件相关的变更请求，并努力赶上审批流程的截止日期。后来产生了令人满意的学习调整，即在产品待办列表梳理时，条目需要被看过是否涉及硬件的变更，以及是否需要制定合适的计划。
另一个“专家团队”的案例是可靠性。ADD环境中的可靠性是指安全性、耐久性、可维护性和（部分）符合监管要求。
可靠性内容对产品至关重要，因此应成为“完成的定义”的一部分，也是产品待办列表梳理的一部分。由于项目思维、组件思维、管理责任制和传统管理思维的历史，在转型之前存在一个专注于可靠性的专门小组。
可靠性小组的加入较晚；差不多在SoP2018的人员加入的时候。在此之前，开发人员考虑了“常规”必需项的和“完成的定义”的（软性）部分。随着可靠性小组的加入，完成的定义被修改为一个逐渐完整的“完成”。
在转型之前，可靠性小组的任务主要是分配任务和协调供应商进行审计和研究、定义安全目标、定义底层硬件要求、与监管机构协调以及将法规整合到安全目标中。在经典的车型项目中，这些安全目标随后被传递给开发经理，由开发经理进行规划、执行和测试。
之前大多数可靠性小组的活动都是在正常团队活动“之外”，因此这“之外”的特点首先被保留下来。这样做的意图是逐步提升团队的能力和实现真正的“完成”。在实现这一点之前，可靠性小组是“完成外”活动的一部分。
在加入后，可靠性小组保留作为一个单独的小组。与“架构专家团队”一样，他们收到与APO和团队在产品待办列表梳理中密切合作的职责。由于APO对需求的认知不同，这种方法只能勉强改善团队对产品真正完成的认知。
澄清一下：“可靠性专家团队”成员偶尔会参加产品待办列表梳理，帮助理解真正的“完成”和所需的小细节。自动化测试套件经过调整，以供“可靠性专家团队”成员、其他专家和利益相关者检查。
| 缩写词 | 含义 |
|---|---|
| ACC | 主动巡航控制（Active Cruise Control） |
| AD | 自动驾驶（Autonomous Driving） |
| ADAS | 高级辅助驾驶系统（Advanced Driver-Assistance Systems），直到且包含L2级 |
| ADD | 自动驾驶部门（Automated and Autonomous Driving Department） |
| ADP | 自动驾驶平台（Autonomous Driving Platform） |
| AI | 人工智能（Artificial Intelligence） |
| ASIL | 汽车安全完整性等级（Automotive Safety Integrity Level） |
| CLP | 认证LeSS实践者（Certified LeSS Practitioner） |
| DCC | 动态巡航控制（Dynamic Cruise Control） |
| ECU | 电子控制单元（Electronic Control Unit） |
| E2E | 端到端（End-to-End） |
| GHE | GitHub企业版（GitHub Enterprise），GitHub的自托管版本 |
| IPA | 个人绩效考评（Individual Performance Appraisal） |
| ML | 机器学习（Machine Learning） |
| PO | 产品负责人（Product Owner） |
| SCM | 软件配置管理（Software Configuration Management） |
| SoP | 开始量产（Start of Production） |
| SWP | 软件合作方（Software Partner） |
| TDD | 测试驱动开发（Test Driven Development） |
| VP | 副总裁（Vice President） |
| Ref-No | Reference |
|---|---|
| [1] | C. Larman and B. Vodde, Scaling Lean & Agile Development, Addison-Wesley, 2008. For logged-in CLPs available as PDF. |
| [2] | C. Larman and B. Vodde, Practices for Scaling Lean & Agile Development, Addison-Wesley, 2010. For logged-in CLPs available as PDF. |
| [3] | C. Larman and B. Vodde, Large-Scale Scrum, Addison-Wesley, 2016. For logged-in CLPs available as PDF. |
| [4] | C. Larman and B. Vodde, Go See, 2019, https://less.works/less/management/go-see.html |
| [5] | B. Vodde, Politics!, 2019, https://less.works/attachable/materials/916 |
| [6] | How too many rules at work keep you from getting things done. TED Talk, 2015. |
| [7] | C. Larman, Applying UML and Patterns, Prentice Hall, 3rd edition, 2004. |
| [8] | C. Larman and B. Vodde, Lean Primer, Version 1.6, 2009. PDF. |
| [10] | Tuckman, Bruce (Spring 2001). Developmental Sequence in Small Groups (PDF). Group Facilitation: A Research and Applications Journal. 63 (6): 71–72. doi:10.1037/h0022100. |
| [11] | Adzic, Gojko (2009), "Bridging the Communication Gap" https://gojko.net/books/bridging-the-communication-gap/ |
| [12] | J. Richard Hackman, Leading Teams, Harvard Business Review Press, 2002. |
| [13] | Jeffrey Pfeffer, Six Dangerous Myths About Pay, 1998, https://hbr.org/1998/05/six-dangerous-myths-about-pay |
| [14] | Jay R. Galbraith, The Star ModelTM, 2016, https://www.jaygalbraith.com/services/star-model |
| [15] | Jo Freeman, The Tyranny of Structurelessness, 1970-1973, https://www.jofreeman.com/joreen/tyranny.htm |
| [16] | Frederick Herzberg, One More Time: How Do You Motivate Employees?, Harvard Business Review, 2003, https://hbr.org/2003/01/one-more-time-how-do-you-motivate-employees |
| [17] | Alfie Kohn, Punished by Rewards, Houghton Mifflin Company, Twenty-fifth anniversary edition, 2018. |
| [18] | Herbert H. Meyer et al., Split Roles in Performance Appraisal, Harvard Business Review, 1965, https://hbr.org/1965/01/split-roles-in-performance-appraisal |
| [19] | Michele & Jim McCarthy, Richard Kasperowski, The Core Protocols, https://thecoreprotocols.org/ |