当我查看成文的案例时，我发现它就是一段走向学习型组织的旅程，一段人们不断地探索如何进行变革，以及为什么要变革的旅程。因此，请将本案例当做一个故事来阅读、欣赏，看一群勇敢的人是如何展开永无止境的学习旅程的。
踏上旅程前
МТS收购LiteBox
在2017年，俄罗斯最大的电信公司MTS对LiteBox公司的股票进行了控制权收购，后者的经营业务为基于云的零售自动化：包括仓库处理系统，采购管理，分析报告等。
从此，LiteBox成为庞大的MTS公司（拥有70,000名员工）的一部分，但它在管理自己的业务方面几乎保持完全的自主权。到LeSS实施时，LiteBox已拥有200多名员工，并作为一个独立的业务部门运作。
商业机会和紧迫感
原有的组织结构
组织架构跟想象的一样，基于传统的管理理念设计的。公司由各个职能部门或者说筒仓组成（财务，采购，销售，IT，市场营销，人力资源）。每个职能部门都有自己的一些经理们，这些经理们也都有自己的一些KPI。
IT部门结构
尽管最终目标是对整个公司进行变革，但我们还是先从对IT部门的人员访谈开始。他们正在开发核心产品和主要价值主张。下面是我的一些发现。
开发以组件团队进行
30多个开发人员通过“项目”团队组织起来进行产品开发。每个“项目”都是围绕着架构组件，技术或职能组织的。因此，他们有7个“项目”：旧后端，新后端，android，windows，测试，分析和API团队。
协调角色及层级
由于这些“项目”都无法创造可用的产品增量从而为客户创造价值，因此需要几个协调角色和职能层级结构：
我的观察和结论
依赖关系。由于组织结构的原因，所有组件团队都无法独立向客户交付任何功能。所有组件团队都具有依赖性，从而导致不必要的计划和协调角色。
单职能专家。组织结构鼓励像业务分析师，测试人员或开发人员这样的单一职能角色，这使组织变得脆弱并且容易受到市场变化的影响。当前的组织结构是针对人员的忙碌程度（“资源使用率”）进行优化的，而不是针对灵活性和快速的价值交付进行优化。
狭窄的视野。团队看到的不是整个产品，而只是产品的一部分。开发人员专注于他们个人的忙碌，而不是系统效率和快速的价值交付。在一个访谈中，有成员这么说：“没有感觉到所有团队都为共同的目标而共同努力。”开发人员并没有完全理解他们开发的功能的价值和目的，因为他们只是工作在组件部分。
缺乏透明度。业务人员饱受低透明度的困扰。他们不知道开发工作的真正进展到底是什么。很多事情是在并行处理的（很大的在制品数量）。工作散落在各个团队中。每个人都工作得很辛苦，在各自的局部里尽着自己最大的努力，但是作为开发小组整体却没有成效。
研究整个公司
建议。不足为奇，在评估之后我给出的建议是：
为什么导入LeSS需要更改组织结构
有效的LeSS导入（有效的单团队Scrum导入也是同样）通常意味着组织结构发生变化（指南：三个LeSS导入原则）。原因是大多数组织结构的设计是针对个体产出进行优化的，当中包含了许多的局部优化。LeSS降低了原有结构带来的组织复杂性，并引入了新的更简单的结构。LeSS的优化目标如下，而这些目标通常需要更改组织结构以支持它们：
学习Scrum基础
我们邀请了高层管理者，一些开发人员以及所有职能部门的经理（市场，销售，合规等）参加为期2天的专业Scrum基础（PSF，ProfessionalScrumFoundations）培训。这个培训帮助他们了解了作为单团队Scrum基石的价值观和原则。LeSS中提供了一些指南，以帮助在组织中实施该框架（入门指南）。该指南的第一步是：教育所有人。现在，我意识到我从一开始就没有严格地遵循该指南，做到教育所有人。这很快就导致了导入时志愿和支持方面的问题。
管理层共同讲述的变革故事
培训之后，我们再次将高层管理者们召集起来，共同创造一个变革故事。这个故事是讲述给公司中每个人的，解释公司为什么要努力变革。幸运的是，我们从一开始就获得了公司负责人的支持。但这还不够。我们一直在寻求整个高层管理团队的帮助和支持。为什么？Scrum和敏捷原则的大规模导入并不局限于开发团队。它涉及产品管理，预算，发布，营销，销售和人力资源策略。由于公司是由职能筒仓组成的，因此任何一位筒仓的高层管理者都有可能对这一重大变革产生负面影响。
因此，这里我们设计了一个变革故事工作坊。工作坊有两个产出。第一个是一个矩阵，风险/机会/问题/紧急事件的信息分别归类在四个象限中。在填充矩阵的过程中，管理者们统一了他们的观点以及他们需要Scrum的原因。
第二个产出是一个变革故事。它是“精益变革管理”中的一个有用的工具。对于其他公司而言，似乎这只是一条简短而引人注目的信息，强调了以下要点：
“之前我们小且敏捷。那时我们是自治的，所有信息都是透明的。我们喜欢那时的我们。然后有一天，我们成长起来，规模变得更大，并且获得了MTS的投资。这影响了我们的思考方式并且工作量也相应的增加。这就是我们需要对结构和流程进行变革的原因。它会帮助我们变得更加有效，清除错误并提高产品质量。在实现敏捷变革的过程中，我们需要指导和教练方面的支持。”
工作坊结束后，我们确保每个员工都能收到这个变革故事的数字版本。
通过试点团队学习Scrum
根据LeSS规则，较小的LeSS实施必须“一次全部”完成。这就意味着周五每个人都还在具有传统组织结构的公司中工作，然后在周一，产品开发的组织设计就翻转为一个崭新的组织结构。尽管这个方法具有众多优点，但我还是无法“兜售”出该方案。尽管如此，他们还是同意成立一个特性团队作为试点，如果成功的话，随后将进行完全的LeSS导入。
试点团队结果
我注意到一些组件团队成员开始参加Sprint评审会议。他们对试点团队的工作很感兴趣。
我们也发现了这次试点产生的一些负面结果或者困难：
公司战略工作坊
LeSS导入是整个公司转型举措的一部分。对公司全面评估后的建议之一是进行战略会议。为期3天的MTSKassa战略会议分为两个部分。前两天用于建立组织愿景和新的业务战略。第三天则用于创建接下来几个月的路线图。
每个俄罗斯企业家都选择我们的B2B生态系统服务作为其业务的助手。
我们将人们召集在一起，围绕着明亮且鼓舞人心的愿景，制定了公司路线图。事实证明，这对于创建产品待办列表也是一个很好的输入。
LeSS导入的后续步骤
2017年夏天，我旁听了CraigLarman在米兰的LeSS课程。他的一个建议“像政治家一样思考，而不是像工程师一样”让人记忆深刻。尽管产品负责人要求我尽快实施LeSS，但Craig的建议帮助我推迟了导入。在特性团队试点取得初步成功之后，我观察到管理层的信任度有所提高。因此，到那时我们已经获得了全面的管理支持。很棒！但是另一方面，我意识到组件团队的许多开发人员仍然对LeSS持怀疑态度。我们想对他们进行教育，以便让他们成为变革的志愿者而不是囚徒（指南：三项导入原则）。
转型待办列表
产品负责人，来自产品小组的一些志愿者，试点团队的ScrumMaster，还有我组成了最初的转型小组。以下是一些转型待办事项：
学习LeSS框架
工作坊向参与者概要介绍了LeSS，大多数人的问题都能得到解答。但是，我认为这个介绍还是太简短。我希望当时我能坚持通过系统图例帮助他们更深入地了解LeSS原则，这可能会带来更多的认同以及对系统思考，排队理论和精益思想的更好理解。
尝试…精益咖啡
在变革的早期阶段，愤怒，不确定性和挫败感达到顶峰。所有变革管理模型都强调了沟通的价值，而精益咖啡是最大化沟通价值的一种好方法。它有助于提供诚实的对话并减少未知数的机会。我发送了一封邮件，并邀请所有人参加精益咖啡聚会。当时我想“如果没人来怎么办？那可就失败到家了。”幸运的是，有很多人进来，我们进行了有益的讨论。不幸运的是，对LeSS的概要介绍和培训非常简短。人们仍然有很多问题，在精益咖啡聚会上他们找到了答案。我长期使用精益咖啡这种形式，我的经验告诉我，有多少人在喝咖啡，通常就表明他们对这个话题的兴趣程度。
选择产品负责人
CTO很自然的被选为了产品负责人。他是公司的联合创始人之一，比其他人更了解市场，业务和客户。选择是如此自然，以至于我没想到会有任何副作用，但是几个月后它们就变得可见了。
产品待办列表的创建
所有需求都位于一个Redmine工具中。由于当前的组织设计是基于组件团队的，因此当时的产品待办列表主要包含了针对组件团队的大量技术任务，从用户的视角来看并没有什么价值。因此，我们围绕着公司愿景和中期业务目标，从头开始创建产品待办列表。
我们在创建过程中使用了可视化的方法。现在产品待办列表变得可见且有形，由大白纸和便签纸构成。
尝试…使用HitMap分析产品待办列表
LeSS原则之一是以“客户为中心”。这意味着要创建有助于优先交付最高客户价值的组织设计。我们不确定是否所有的特性团队都应该能够同时工作在三个不同的UI平台上来交付价值。也许根据客户细分来组建团队是有意义的。我们希望HitMap能帮我们找到答案。这是一个非常简单而可靠的工具。它能帮我们看到每个PBI使用了哪些架构组件。HitMap看起来大致是这样的：
完美目标是创建特性团队，以从产品待办列表中选择任何PBI，并在每个Sprint至少一次独立地发布到市场。假设我们在Android和iOS平台上都需要相同的产品功能。我们就可能需要创建具有iOS和Android开发能力的特性团队。
我们花了几个小时来创建HitMap。几个月前我就要求产品负责人对产品待办列表进行排序整理，以获得一个长远的视图。最终，我们在几张大白纸上贴满了便签纸。当HitMap创建完成后，对于产品负责人来说，为了拥有最大的敏捷性，他显然需要与试点团队类似的全栈特性团队。他计划开发的主要产品功能都需要通过所有三个I/O渠道（web，Android，Windows）进行。
团队自设计工作坊
HitMap被创建了之后，产品负责人确定他需要全栈特性团队。我帮助他召开了一个会议，他向所有人介绍了最终的HitMap。产品负责人非常强烈地表达他的观点，创建特性团队的想法没有遇到很明显的阻力。每个人都可以看到跨职能跨组件的特性团队可以为公司提供最大的灵活性，并从产品待办列表中交付最高价值。接着我们要求大家为组建团队设置约束条件，下列各项就是他们想到的：
团队自设计工作坊之后，我们组织了一些团队建设活动：
第二天早上，当我来到办公室时，发现开发人员都已经搬到了各自的新房间。
完美愿景
LeSS的基本原则之一是“持续改进以实现完美愿景”。使用LeSS框架，您可以持续不断地对交付价值给客户加以改进。举个例子，没有额外的角色做协调工作。如果框架将它们包含在设计中，那么如果将其嵌入在系统设计中，人们将有何动力对其进行改进呢？LeSS的目标是使单团队Scrum在多团队环境中也可以工作，而无需引入新的角色和规则（原理：“大规模Scrum是Scrum”）。
产品或组织的完美愿景是一个永远无法实现的状态。在完美愿景的驱动下，人们可以考虑任何实验来进行改进。
我的同事CesarioRamos给了我一个组织的完美愿景作为例子。我把它打印了出来分发给所有人，以作参考。我们要求团队提出自己的完美愿景。20分钟后，我们在大白纸上写下了所有想法并进行投票。
在回顾会议期间，我们在做出决策时就提到了完美愿景。例如，曾经有一个想法来创建一个专门的协调角色。这与完美愿景相冲突，团队的代表们否决了它。
完成的定义（DoD）
选择ScrumMaster
在LeSS中，ScrumMaster是一个专门的角色，可以服务于1-3个团队。我们期待在改变组织结构的那一天能从市场上聘请到经验丰富的ScrumMaster。不幸的是，它根本没有发生。因而，最终我决定成为第二位ScrumMaster，直到有人可以代替我为止。这样我们有2个全职ScrumMaster（SergeyGospodchikov和我）与4个团队合作。
团队通过投票来选择想要合作的ScrumMaster。我们还引导了为ScrumMaster建立期望列表的过程。产生的列表中有一些项挺有趣：
与社区一起学习
第一个社区在几天后启动，其余的社区则在前两个Sprint中启动了。我们确保每个社区都有ScrumMaster的支持来帮助他们定义：
开发人员定期聚在一起，愉快地参加社区活动。我还记得有一次活动是用mob编程的形式进行自动化测试开发。一位设计师之所以参加这个活动，是因为她想学习自动化。人人想学习！
最初的PBR
尝试…条目拆分工作坊
尝试…估算和类比估算网
当多个团队处理同一个产品待办列表时，需要统一估算单位。试点特性团队已经具有相对估算的经验，并且有许多已完成的条目。于是我们创建了一个类比估算网，把已完成的条目放进去以作为基准。然后，我主持了一个工作坊，期间试点特性团队成员向其他开发人员解释了可以被参考的PBI，我帮助他们对齐了故事点估算标准。
引导第一个多团队PBR。在LeSS实施之前，团队是从专门的需求分析小组那里获得需求。现在，他们自己负责澄清每个条目的细节。我们邀请了领域专家到会议室。团队组成混合小组，分布在按不同的墙壁区域划分的四个站点里。每个站点都有一位专家帮助他们澄清PBI。25分钟后，每个人都顺时针移动到另一个站点（驻扎站点的专家除外）。上一组已经在大白纸上留下了注释，图表和说明，这对新的一组人确实有帮助。因此，团队需要一个多小时来澄清三个PBI。稍作休息后，我们再次重复该过程。
导入LeSS结构
还记得产品团队的组件团队结构吗？现在，在团队自设计工作坊之后，团队结构发生了变化，开发人员组成了4个新的特性团队。每个团队都是一个跨组件跨职能的自治单元，可以工作在产品待办列表上的任何一个PBI上。团队的名字是：“Alfa”，“Vegas”，“StoreCraft”，“Hotfixies”。
LeSS导入的根本失误。我建议业务分析师加入团队。他们得到了邀请，但是他们积极抵制新流程和LeSS导入。最终我们将他们放到了团队之外，而产品负责人要求他们在多团队PBR时代表他。这是一个不成熟的想法，也是导入LeSS的根本失误。理想情况是真正的客户和用户（而不是BA）直接与真正的开发人员沟通，没有中间人，而且前BA自愿加入团队并成为常规团队成员。现在的情况与LeSS导入的关键原则和指南相反。因此，这不是一个正常/健康的导入方式。由于缺乏对LeSS使用志愿的方式，以及消除BA作为中间人之重要性的理解，该基本要素并未实现。
我未能理解志愿原则。导入LeSS的三项原则之一是使用志愿的方式（指南：三项导入原则）。我和产品小组误解了使用志愿的方式。它实际包含的含义是，没有人可以加入产品团队，除非他们完全了解LeSS规则并自愿遵守。而我们在导入过程中有“反对导入”的团队人员，这与原则刚好相反。
从那一刻起，我们有了一些不支持LeSS导入但是却在导入范围内的人，他们时时与导入抗争。这带来了很多痛苦和沮丧，因为“反对导入”的人们总试图阻挠变革。他们渴望将所有都恢复到以前的状态和组件团队的结构。
中间人造成浪费。BA停止制造需求说明并将其移交给团队，并开始与团队在产品待办条目进行合作。不幸的是，他们的重点转向了在开发人员与客户/用户之间充当中间人：
这些正是真正的开发人员在LeSS导入后要做的事情。但是中间人的角色继续存在，不断造成浪费和问题。这都是应该在LeSS导入时予以摈弃的。
在以前的组件团队结构中，发布经理是最终决定产品增量是否可以发布的人。她得到了留在任何团队的邀请，但她拒绝了邀请。这再次说明了我如何误解了导入LeSS的志愿原则。
管理。开发中的所有管理角色都立即被正式解散。协调人员和经理们现在成为团队中的开发人员。因此，不再有“团队领导”和“技术领导”的称谓。仍然有一个由他们自己的经理领导的支持和培训部门存在，但它们不在LeSS实施范围内。我认为，将来它们可能会被LeSS产品团队吸收，而DoD也将增加新的扩展：为客户创建视频和网站教程。
学习使用LeSS框架跑迭代
第一个迭代
正如俄罗斯谚语所言，“不犯错，不成事”。对于第一个Sprint来说确实如此。尽管进行了所有准备和培训，但团队仍然不得不直面局部优化的弊端。以前，公司从来没有以客户为中心的产品待办列表。现在，产品待办列表中的排序主要由对客户的重要性决定。
我们发现了一些在启动过程中没有考虑到的问题。例如，如何处理来自技术支持的紧急任务和错误。另外，我们没有考虑如何提前进行回归测试。而且不幸的是，存在巨大的技术债务，并且自动化测试的覆盖率很低。
我还注意到，人们因大量的培训和漫长的（3天）启动而感到非常疲倦。尽管如此，第一次Sprint评审会议还是成功的。团队在Sprint评审会议期间演示了PBI。参加评审的内部干系人也给予了他们积极的反馈。
在第一个Sprint期间，出现并积累了很多问题。团队中有许多问题都很类似，因此在Sprint评审会议结束时，我建议与产品团队中的每个人一起参加比以往更长的总体回顾会议。我们耐心地花了三个小时。结果是：
第一个Sprint并不容易，但是产品负责人和大多数开发人员都致力于向前推进乃至实现目标。
导入可视化管理
产品待办列表的可视化管理。我们从一开始就可视化了产品待办列表（实验：尝试…可视化管理产品待办列表或发布待办列表）。产品负责人和反对Scrum导入的两个人，因此也不应该成为该小组的成员（两位业务分析师），维护着墙上的产品待办列表，保持它一直在最新的状态。每张便签纸都代表一个PBI。待办条目沿着墙从左到右移动，进入“Ready”状态，最终成为迭代待办列表的一部分。
迭代待办列表的可视化管理。我建议团队可视化他们的迭代待办列表，并限制进行中的工作（WIP）。我们举办了一个关于限制队列大小的简短工作坊，并播放了“FeatureBan”。我认为这段简短的视频完美地说明了为什么您需要限制WIP以及如何更好地管理队列。每个团队都为迭代待办列表设置了明确的WIP限制。
可视化管理有助于协作。在LeSS中，团队之间没有依赖关系。为什么？任何特性团队都可以为其待办条目跨代码库工作。团队应用诸如持续集成、社区、多团队工作坊以及共享和交换工作之类的方式，对彼此进行管理和协调。因此，团队要做的就是合作和共享工作。
在迭代计划会议第二部分时，我们发现在需要几个团队之间协作的PBI上做上标记对即将到来的迭代会很有帮助。通常，我们就在条目上面贴一个写有对应协调技术（例如“侦察员”，“组件导师”，“只是说”等）的小便签。
尝试…可视化会议
协调
有趣的是，在引入LeSS之前，团队将协调视为最重要的问题。我在精益咖啡聚会时注意到大多数问题都与协调有关。我们很快就解决了这个问题。在一次性更改团队结构之前，我们进行了LeSS基础认证（CLB）培训，期间我们讨论了协调。从我的观察中可以看出，最常使用的协调方法是：“指南：用代码交流”、“指南：只是说”，及其更高级的版本“只是喊”。
团队还在迭代计划第二部分的时候及时选择了所需的实践。LeSS依靠基于自组织的协调行为。自组织的重要要素之一是所有团队的房间都通过一个大走廊相连。我们还有一个共享的房间，在里面可以看到所有的信息。
迭代计划会议第一部分
在迭代计划会议的第一部分开始前一个小时，产品负责人和两名业务分析师对产品待办事项进行了最终更改。然后，所有的团队代表（通常每个团队2人）参加了迭代计划会议第一部分。
会议议程。我们通常遵循下面的议程：
迭代目标。LeSS中并没有提到迭代目标，因为LeSS的原则之一是“大规模Scrum是Scrum”，所以LeSS不会拷贝粘贴Scrum指南中的元素（以避免重复）。
LeSS中迭代目标的例子。问题出现了：是为整个产品团队定义一个迭代目标，还是每个团队都应该有自己的迭代目标，还是两个都定义？没有标准答案。我认为所有选项都是可能的。这里有一些例子：
就像您看到的这样，可能有不同的组合。个人来说，我比较喜欢整个产品团队定义一个共同的迭代目标。
迭代计划会议第二部分
在我们的案例中，迭代计划的第二部分是微不足道的。因为在会议的第一部分中识别了所有的协调可能性之后，团队会决定是否应该一起讨论多个团队的计划。如果需要的话，团队决定在一个大的共享空间中进行迭代计划会议第二部分（指南：多团队迭代计划第二部分）。但大多数情况下，团队只是回到自己的房间，在ScrumMaster的帮助下创建他们的迭代待办列表。最多花30-40分钟。对于迭代待办列表的工具，我的建议与LeSS指南一致（指南：不使用软件工具管理迭代待办列表）：
“不要为迭代待办列表使用任何软件工具；只用使用可视化管理，可能只是贴在墙上的卡片（大规模Scrum：以少为多）”
学习LeSS中的待办列表梳理
在大规模Scrum中，PBR是一个强制性事件（而不是可有可无的活动）。之所以这样，是因为产品待办条目在大型产品团队中确实非常大，非常需要在整个团队层面进行广泛的协调与学习，并且根据实际需要安排一定数量的与客户和用户的会议。在LeSS中，有几种PBR方法（指南：产品待办列表梳理）：
对于应该使用哪些产品待办列表梳理的方法组合LeSS没有设定任何规则，但是LeSS建议进行多团队产品待办列表梳理。让我们来仔细看一下。
整体PBR
我们使用了相同的引导方法。产品负责人从墙上拿下一个PBI进行讨论，然后他使用5-10分钟对提出的问题进行澄清。
然后进行明确的估算。如果PBI超过13个点，我们就将其拆分（实验：尝试…细胞一样的拆分而非树状拆分）。
多团队PBR
谁会想到，为什么需要几个团队在一个房间里工作并同时优化几个PBI？每个团队进行自己的单团队PBR会“效率”更高吗？让我们弄弄清楚。
适应性。如果几个团队对几个PBI都了解，则产品负责人可以推迟决定哪些PBI该包含在接下来的迭代范围里，不用受特定团队只有某些特定知识的约束。它为产品负责人的修改优先级提供了更大的灵活性。
多团队PBR的复杂性
多团队PBR有许多好处。尽管如此，还是有一些问题。让我们看看它们。
信息过载。同一房间中参与多团队PBR的团队越多，他们需要了解的PBI就越多。因此，信息过载可能是多团队PBR的副作用。
引导。要让数十人参加这个事件并不容易。如果引导不当，则会造成浪费，从而开发人员不再希望参加多团队PBR。让我们在系统模型中探索一下：
多团队PBR引导技巧
充分的准备。准备最多可能会需要几个小时。它包括但不限于：事先与事件干系人会面，制定引导计划，在活动挂图上进行可视化（目的，议程）以及在事件之前准备好空间（移走桌子，椅子，放置活动挂图架等等）。
“中心化毁了活力；去中心化创建活力（大规模Scrum：以少为多）。”
混合组。除了前面的建议外，小组最好是由来自不同团队的成员组成。
“从由每个团队的人员组成临时的混合小组开始。例如，两个团队重组为两个混合组（大规模Scrum：以少为多）。”
这是增强不同团队之间的协作并减少信息分散的方法。每个团队的每个成员都是常识谜题的一部分。
分散-集中和轮转。除了前面的两个建议外，这是可用于大型人群引导的另外两种技术。首先是将PBI分配给每个小组，让他们在多个站点并行工作并完善到“就绪”状态，然后每个人都参加到一个集中的公开讨论中。
轮转表示小组从一个站点到另一个站点按顺时针方向移动多次，而业务专家仍然停留在对应的站点上。每个工作站点都工作在自己的PBI上。我非常喜欢这种做法，并且对它的效果有过多种体验。想象一下，第一轮大约需要20到25分钟，然后另一个小组接近了这个站。该小组尚不熟悉该站点对应的特性，但是他们拥有先前工作在该站点的小组创建的有关验收标准、界面等信息。他们所需要的就是去掌握新信息。
站着工作。如果可能的话，我会从进行多团队PBR的房间里挪走所有椅子。人们站在一起开的会议更加活跃，人们参与度更高，精力更充沛并且专注。
“就绪”的定义。当团队在工作站上梳理PBI时拥有相同的“就绪”定义时，就会蓬勃发展，因为可变性大大降低了。这是我们都同意的“就绪”的第一个版本：
反馈。在每个PBR事件结束时进行一次小型回顾。我要求每个人以1到10的比例评估事件的有效性，并附上详细的反馈。
我发现，多团队PBR能正确完成后，迭代计划的两个部分都不会超过一个半小时（最多两个小时）。多团队PBR已成为此导入中的关键事件，因为它是协调，更好地了解产品和适应性的驱动力。
迭代评审会议
早期的迭代评审是在没有最终用户的情况下进行的，产品负责人仅邀请了内部客户。团队希望在从市场上邀请嘉宾前能够练习一下。这就是为什么迭代评审会议的第一批访问者是其他部门的员工：技术支持，市场营销，销售，人力资源和合规。通常的迭代评审会议是：
聚焦整个产品。我注意到，未参与本团队站点的开发人员正积极地在其他站点间走动，并向同行提供了反馈。他们对其他人的工作变得真正感兴趣。在这儿或那儿组成了小组，对产品展开了一些有趣的讨论。
尝试…创新游戏
最终用户每两个迭代来访问一次。我们经常使用两个完美互补的创新游戏：“快艇”和“修剪产品树”。快艇可以很好地识别客户的痛苦和需要完成的工作。修剪产品树则非常适合为产品待办列表找到更好的解决方案（特性）。
团队回顾
对我而言，Scrum回顾会议始终是一个特殊事件。从组件团队结构向特性团队结构转变对人们来说是一个很大的转变。因此，我估计在早期的回顾会议中会出现无数的问题。我是对的。第一次迭代对每个团队来说都有巨大的压力，我们将总体回顾与团队回顾结合为一个大事件，因为几乎所有问题都是相同的，并且在解决问题时包括整个产品团队非常重要。每个人的参与和符合SMART原则的改进项起了很大的作用。压力显著地降低了。在接下来的迭代中，除了整体回顾之外，每个团队都各自进行了自己的团队回顾。
系统和团队层面的障碍。在全面回顾期间讨论系统问题时，我总是要求团队将系统障碍与团队障碍分开。我经常使用活动影响圈。在大白纸上画两个圆圈，一个大圆套一个小圆。里面的圆圈可以填充团队可以自行解决的主题，外面的圆圈则填充跨越团队边界的一些问题。
整体回顾
迭代的结束是在周末（星期五），这也是为什么决定在下一个迭代的星期二下午进行整体回顾的原因。产品负责人，ScrumMaster和团队代表是永久的参与者。
完美愿景和八个讨论主题。LeSS导入时，团队创造了完美愿景。理想中的组织会是怎样，这是一个永远无法达到的检查清单。检查了整体回顾期间所做的任何决定，以了解其与完美愿景的一致性。整体回顾聚焦在八个主题上，您可以到LeSS网站查看细节。我们在每次回顾会议上都会提醒团队的，以及许多已经被遗忘且没有被聚焦的问题。
我想列举在回顾会议期间讨论的一些问题：
学习与7个团队合作
当得知MTS和LiteBox在2017年同意将团队数量增加到7个时，我认为这是一个很大的惊喜。因此，在结构改变之后，很快有更多新团队加入了产品团队。
RITG团队来自外包合作伙伴。产品负责人非常有热情去组建新团队。他与同一城市的一家外包公司建立了合作关系。几周后，一个名为RITG的新团队被添加到产品团队中。有好几个迭代，我们试图将新团队融入流程中，但不幸我们失败了。在PBR期间，沟通问题给我们带来很大的困扰。此外，他们没有人参加“迭代评审会议”。于是我建议让新团队也来办公室工作。虽然最后产品负责人成功做到了，但这绝不是一件容易的事。从那时起，我们在同一办公室就有了5个团队。
ROST团队在办公室。同时，公司HR帮助我们组建了另一个名为ROST的特性团队。前试点特性团队的两名成员加入这个特性团队里工作几个迭代，以帮助这个团队舒适地过渡。
来自乌克兰的远程团队。从产品的早期开发开始，MTSKassa在乌克兰就有几个开发人员。这些人甚至参加了最初的Scrum培训。我们都同意暂不将他们纳入到产品团队中，直到他们可以在基辅组建一个同地办公的特性团队（他们远程工作并且居住在乌克兰的不同城市）为止。这终于发生了。
不幸的是更多的中间商。我之前提到过，导入该技术的主要失败点之一是启用了不支持变革但充当团队和客户之间中间人的人员。团队数量增加了，并且有职能障碍的业务分析组也增加了人员。他们聘请了一位新的业务分析师，主要从事对外的工作。这是当时结构的外观：
将重点从本地改进转移到系统改进
在最初的几个月中，我们聚焦于在新的LeSS结构中建立有用的流程，熟练地举行LeSS事件（相信我，多团队PBR和迭代Review不容易做到有效地实施）并且确实取得了很多进步。最初，大多数开发人员是LeSS的新手，我们处理的大多数问题是：
社区的发展
社区还活着。7个月后，仍然有5个社区（CI/CD，QA，ScrumMaster，UI/UX，前端）仍然存在，有2个社区（CI/CD和后端）合并为一个社区（CI/CD），其他社区则不存在了。这是正常的。出生和死亡的过程对于社区来说应该是自然发生的。
将社区建议包括PBI在内。会议的结果通常是一组技术性PBI和改进，社区建议团队和产品负责人将其包含在ProductBacklog中。
改变需求流动
产品工作坊。我为产品负责人，BA，ScrumMaster和团队代表进行了为期2天的动手工作坊，在此期间，我们有：
产品负责人现在已经有了新工具，他还看到了愿景、业务目标、客户目标和特性之间的紧密联系。从那时起，我们建议团队对整体PBR和多团队PBR使用不同的形式。
调整后的梳理流程
在产品工作坊结束后，我们邀请了团队代表（他们每个迭代轮换以避免特权或单一岗位），共同为整体PBR和多团队PBR创建了一个新流程。这就是我们即将看到的。
整体PBR：
单团队PBR：
多团队PBR：
经验教训和导致的实验
您在案例中已经阅读了一些实验（尝试…避免……），因为它们非常适合嵌在案例里。在下面，您可以看到我回顾了整个LeSS导入之后做的一些实验。您也可以把它们当做是我的经验教训。
避免…持怀疑态度的人加入
在典型的职能型组织设计中，人们充当机器的齿轮，仅执行一项职能。但是人们具有学习的元技能，并且可以在基于团队的组织设计中变得更加灵活（指南：构建基于团队的组织）。在更改团队结构之前，我注意到有些人对公司将成为基于团队的组织这一事实感到明显不满。他们真的只想成为一个狭窄领域的专家，他们不喜欢Scrum，感到非常不满，并且他们直言不讳。他们没有隐藏自己的动机，而且很直率。老实说，我当时想尽快导入LeSS，现在我知道那是一个巨大的错误。您可能无法想象如果几个人真的想破坏变革，他们可以造成多大的毁坏和伤害。Kotter博士有一段讲述了抵抗的录像带，他的建议是：
“不管他们与您的关系有多强，都不要管他们，因为如果您邀请他们进入帐篷，他们会造成很大的损害，以至于毁了整个变革。”
尝试…以后仅使用志愿者翻转
避免…团队和ScrumMaster向产品负责人报告
正如我之前解释的那样，作为产品负责人的CTO对我们来说是很自然的选择。但几个月后，我们仍然受到负面影响。正如公司管理层所预测的那样，客户群迅速增长，产品团队承受着提供更多产品的巨大压力。新的请求通常来自市场营销、销售以及新客户要求的定制解决方案等。我没有注意到产品负责人在结构变革之前聘用并解雇了开发人员，之后决定聘用和解雇的也仍然是他，所以这一点在实际上没有任何改变。团队直接向他报告。例如，想要加薪的开发人员需要与联系他并开始谈判。我想引用指南：LeSS组织结构中的：
“在这种组织结构中，重要的一点是，团队和产品负责人是同行，他们之间没有上下级关系。”
一位ScrumMaster告诉我，产品负责人开始质疑团队的预测，对他们施加压力，并长期对团队的绩效不满意。ScrumMaster们尽其所能，尽力保护自己的团队，但在整体回顾期间，他们曾经与产品负责人发生冲突，并被其警告可能被解雇。虽然我们设法解决了冲突，但是从那一刻起，很明显，产品负责人成为团队的老板是一个组织级别的障碍。它在我们的障碍列表中。我们仍在努力。
避免…在DoD不是可交付时规模化
DoD和每个迭代透明的可交付增量从来都是Scrum的核心，但在规模化环境中显得尤为重要。为什么？增加新的团队并拥有薄弱的DoD意味着您将职能障碍也扩大了。未完成的工作随着更多的团队而积累得更快。如果您的技术债务很大，请不要添加新团队，添加新团队就像用汽油扑灭大火一样。相反，应聚焦于移除undone并使产品增量完全透明。
尝试…使DoD尽可能详细
完成的定义（DoD）的初稿被创建后运行了一些迭代，直到我们注意到不是所有的团队都在平等地遵循DoD。我们开始调查此问题，发现原因是DoD的第一个版本不够详细，可以用不同的方式解释。而且并非所有术语和用词对所有团队都具有相同的含义。所以协议不是100％明确。因此，我们再次合作，对DoD作了澄清，并使其尽可能详细和具体。现在，我建议您使用以下形式定义DoD：将其放在大白纸上并划分为两列。在“活动”列中描述活动本身，在“标准”列中回答问题：我们如何衡量或清楚地知道活动真正地完成了？准备好花2-3个小时来澄清DoD，但这是值得的。
尝试…解释DoD定义适应性
我发现许多产品小组只知道DoD是一个正式的检查清单，却不知道DoD其实还定义了他们的适应性。我还发现，当您向团队和业务部门展示DoD其实定义了敏捷性时，他们就开始更加认真地看待DoD。请参照下面的系统模型图例。在这里我在LeSS导入几个月后就做了，以后我将努力在LeSS一开始导入的时候就做。
尝试…成熟又勇敢的ScrumMaster
即使对于单团队而言，导入Scrum也是一个巨大的变化。拥有勇敢的ScrumMaster似乎是LeSS导入成功的关键因素之一。勇敢的ScrumMaster是指一个可靠而经验丰富的人，能够谈论不受欢迎的事情并能够揭露丑陋的真相。我的一位客户（一家大银行）决定聘请经验不足的年轻大学毕业生，让他们担当ScrumMaster。实验惨败。年轻人能够学习如何引导。他们准备了精美的大白纸，并绘制了可爱的燃尽图。但是他们没有成为变革推动者，也无法消除任何组织障碍。他们还不够成熟，没有做好在压力下工作的准备。在MTSKassa中，很高兴与2位优秀且成熟的ScrumMaster合作。他们保护了团队，有时还要直接面对产品负责人和高级管理层。谢谢他们！
尝试…向其他LeSS导入方法学习
尝试…找到一位经验丰富的LeSS导师
在导入MTSKassa的过程中，我并不孤单。在那时，我获得了一位经验丰富的导师CesarioRamos的帮助，他是LeSS认证培训师（CLT，CertifiedLeSSTrainer）。一年中，我们通过chat进行了沟通，还共同培训了三次LeSS认证实践者课程（CLP，CertifiedLeSSPractitioner）。在共同培训期间，我从Cesario那里听到许多战争故事，并且有机会观察他是如何回答学生的棘手问题的。每次培训我都会从他那里学到新东西，他的每堂课都是独一无二的。除了共同培训外，我的导师还支持我根据需求为不同的工作坊提供他个人的材料：LeSS中的完美愿景，产品的定义，人员和奖励。拥有经验丰富的LeSS教练作为您的导师是发生在我身上并且可能会发生在您身上的最好的事情之一。您将拥有加速的个人成长！
结果
这是我参与过的最具活力的变革之一。我作为教练参与始于2018年1月，至今仍在继续。计划在今年年底之前将更多的团队添加到产品团队中。显然，还需要增加一个频道（iOS）。
当我问产品负责人（也是公司的CTO）时，他从LeSS中学到的最有价值的东西是什么，他提到了几点：
总结一下，我想从我的视角强调一些其他重要的观点：
致谢
我要感谢公司的高级经理：SergeiMuzykantov和RomanAriffulin。他们在2018年1月时相信LeSS。该案例是俄罗斯第一个官方的LeSS案例研究。Sergei和Roman的确是先驱。感谢他们的勇气和前进的愿望。
另外，我还要感谢SergeyGospodchikov。他是俄罗斯第一位LeSSScrumMaster。他对Scrum价值观的身体力行，毅力和执着的奉献精神为整体成功做出了巨大贡献。