LeSS规模化敏捷转型案例 – 电信公司MTS

作者：Illia Pavlichenko

译者：Philip Wang

审校：徐彬

学习的旅程

当我查看成文的案例时，我发现它就是一段走向学习型组织的旅程，一段人们不断地探索如何进行变革，以及为什么要变革的旅程。因此，请将本案例当做一个故事来阅读、欣赏，看一群勇敢的人是如何展开永无止境的学习旅程的。

踏上旅程前

МТS收购LiteBox

在2017年，俄罗斯最大的电信公司MTS对LiteBox公司的股票进行了控制权收购，后者的经营业务为基于云的零售自动化：包括仓库处理系统，采购管理，分析报告等。

从此，LiteBox成为庞大的MTS公司（拥有70,000名员工）的一部分，但它在管理自己的业务方面几乎保持完全的自主权。到LeSS实施时，LiteBox已拥有200多名员工，并作为一个独立的业务部门运作。

商业机会和紧迫感

MTS管理层向我寻求帮助。2017年底，我们进行了首次协商。原因是LiteBox管理层预计从2018年7月1日开始将掀起一股巨大的客户增长潮（或者说是海啸），用户群将增加大约100倍。2017年12月，LiteBox的客户数量是6000多，而到2018年秋季预计将超过10万。LiteBox管理层希望产品开发具有适应性，并容易做到规模化扩展。在与高层管理者们进行了数次面对面会谈之后，我们同意先从一些电话访谈开始，然后进行更深入和结构化的公司审计。

原有的组织结构

组织架构跟想象的一样，基于传统的管理理念设计的。公司由各个职能部门或者说筒仓组成（财务，采购，销售，IT，市场营销，人力资源）。每个职能部门都有自己的一些经理们，这些经理们也都有自己的一些KPI。

IT部门结构

尽管最终目标是对整个公司进行变革，但我们还是先从对IT部门的人员访谈开始。他们正在开发核心产品和主要价值主张。下面是我的一些发现。

开发以组件团队进行

30多个开发人员通过“项目”团队组织起来进行产品开发。每个“项目”都是围绕着架构组件，技术或职能组织的。因此，他们有7个“项目”：旧后端，新后端，android，windows，测试，分析和API团队。

技术栈由几种编程语言和相关框架组成：Javascript, Android, Python, SQL, Java。

协调角色及层级

由于这些“项目”都无法创造可用的产品增量从而为客户创造价值，因此需要几个协调角色和职能层级结构：

• 分析部门主管
• 测试部门负责人
• 首席架构师
• 后端技术负责人
• Android开发技术负责人
• Windows开发技术负责人
• 发布工程师

他们是一个使用了一些Scrum术语的传统组织。简而言之，就是骨子里根本没变的伪敏捷组织。访谈后，我在LiteBox办公室里花了两天时间进行“Go See”。除了生搬硬套或“copy-paste Scrum”方法外，我立即注意到另外两件事：

• 每个项目都旨在最大程度地提高资源使用率，而且显然这是每个人的终极目标。
• IT开发饱受来自生产环境的大量缺陷或者事故的折磨。

我的观察和结论

LiteBox是具有层级结构的职能型组织，并拥有与此结构相关的所有众所周知的问题。

依赖关系。由于组织结构的原因，所有组件团队都无法独立向客户交付任何功能。所有组件团队都具有依赖性，从而导致不必要的计划和协调角色。

交接和瀑布式。组件（“项目”）之间存在大量交接。这导致了严重的排队现象，客户反馈也因此延迟。一个功能从开始到完成的平均周期时间为6-7周。

单职能专家。组织结构鼓励像业务分析师，测试人员或开发人员这样的单一职能角色，这使组织变得脆弱并且容易受到市场变化的影响。当前的组织结构是针对人员的忙碌程度（“资源使用率”）进行优化的，而不是针对灵活性和快速的价值交付进行优化。

狭窄的视野。团队看到的不是整个产品，而只是产品的一部分。开发人员专注于他们个人的忙碌，而不是系统效率和快速的价值交付。在一个访谈中，有成员这么说：“没有感觉到所有团队都为共同的目标而共同努力。”开发人员并没有完全理解他们开发的功能的价值和目的，因为他们只是工作在组件部分。

缺乏透明度。业务人员饱受低透明度的困扰。他们不知道开发工作的真正进展到底是什么。很多事情是在并行处理的（很大的在制品数量）。工作散落在各个团队中。每个人都工作得很辛苦，在各自的局部里尽着自己最大的努力，但是作为开发小组整体却没有成效。

差劲的需求管理。不存在单一的需求来源。团队抱怨着优先级冲突，因为如此多的利益相关者能够给他们派活儿：业务分析师，CTO，呼叫中心，市场部门，等等等等。没有确定的流程为需求排序。当前的需求管理系统在员工的眼中就是“垃圾”。

研究整个公司

经过一系列电话访谈并在LiteBox办公室工作了几天之后，我对高层管理者们介绍了自己的观察结果，然后赶往总部对整个公司进行了深入评估。我们与公司高级管理层和员工举行了为期两天的工作坊，重点讨论公司的组织结构，价值观，价值流等。我们的目标是制定下一步计划和行动方案。我们在工作坊上使用的一些工具是：

• Scott-Morton图 – 这展示了关键的公司要素之间的联系：战略，流程，人员，技术和结构。
• 加权SWOT分析 – 它是在混合组中创建的。所有相关因素都使用从1到5的标准对其重要性做了权衡。
• 价值流图 – 这项技术使我们可以获得对产品开发流（从收到客户请求到相应的价值交付）中浪费的洞察。通常，它是从客户支持收到的客户首次致电开始，结束于相应的新版本发布。

评估结果。细致的公司评估证明了我对组件团队及其功能障碍的最初论断。价值流图还显示了一个特性从开始到结束的平均周期时间为6-7周。我喜欢工作坊时管理人员的那些“啊哈！”时刻：

• 他们都同意，对于这样一个中型公司而言，层次结构太多了。
• 了解到个人的KPI和奖金在公司只是在公司的某些部门（销售和市场）做了局部优化，并将导致两个职能部门相对立。
• 会议室中的每个人都同意公司没有明确的愿景和战略计划。

建议。不足为奇，在评估之后我给出的建议是：

• 在IT产品组中举办Scrum培训。
• 针对CxO人员的Scrum培训。
• 战略规划工作坊，以明确公司愿景并制定接下来1到2年的公司战略。
• 简化组织结构，从职能型组织逐步转变为基于团队的组织。
• 启动特性团队作为试点，如果成功，导入LeSS。

旅程开始 – LeSS导入准备

为什么导入LeSS需要更改组织结构

有效的LeSS导入（有效的单团队Scrum导入也是同样）通常意味着组织结构发生变化（ 指南：三个LeSS导入原则 ）。原因是大多数组织结构的设计是针对个体产出进行优化的，当中包含了许多的局部优化。LeSS降低了原有结构带来的组织复杂性，并引入了新的更简单的结构。LeSS的优化目标如下，而这些目标通常需要更改组织结构以支持它们：

• 优先交付最高的客户价值
• 便宜且容易的适应性（“轻盈优雅地转身”）
• 学习

学习Scrum基础

我们邀请了高层管理者，一些开发人员以及所有职能部门的经理（市场，销售，合规等）参加为期2天的专业Scrum基础（PSF，Professional Scrum Foundations）培训。这个培训帮助他们了解了作为单团队Scrum基石的价值观和原则。LeSS中提供了一些指南，以帮助在组织中实施该框架（ 入门指南 ）。该指南的第一步是：教育所有人。现在，我意识到我从一开始就没有严格地遵循该指南，做到教育所有人。这很快就导致了导入时志愿和支持方面的问题。

管理层共同讲述的变革故事

培训之后，我们再次将高层管理者们召集起来，共同创造一个变革故事。这个故事是讲述给公司中每个人的，解释公司为什么要努力变革。幸运的是，我们从一开始就获得了公司负责人的支持。但这还不够。我们一直在寻求整个高层管理团队的帮助和支持。为什么？Scrum和敏捷原则的大规模导入并不局限于开发团队。它涉及产品管理，预算，发布，营销，销售和人力资源策略。由于公司是由职能筒仓组成的，因此任何一位筒仓的高层管理者都有可能对这一重大变革产生负面影响。

因此，这里我们设计了一个变革故事工作坊。工作坊有两个产出。第一个是一个矩阵，风险/机会/问题/紧急事件的信息分别归类在四个象限中。在填充矩阵的过程中，管理者们统一了他们的观点以及他们需要Scrum的原因。

第二个产出是一个变革故事。它是“精益变革管理”中的一个有用的工具。对于其他公司而言，似乎这只是一条简短而引人注目的信息，强调了以下要点：

• 为什么现在需要变革
• 我们即将要做的事情

“之前我们小且敏捷。那时我们是自治的，所有信息都是透明的。我们喜欢那时的我们。然后有一天，我们成长起来，规模变得更大，并且获得了MTS的投资。这影响了我们的思考方式并且工作量也相应的增加。这就是我们需要对结构和流程进行变革的原因。它会帮助我们变得更加有效，清除错误并提高产品质量。在实现敏捷变革的过程中，我们需要指导和教练方面的支持。”

工作坊结束后，我们确保每个员工都能收到这个变革故事的数字版本。

通过试点团队学习Scrum

根据LeSS规则，较小的LeSS实施必须“一次全部”完成。这就意味着周五每个人都还在具有传统组织结构的公司中工作，然后在周一，产品开发的组织设计就翻转为一个崭新的组织结构。尽管这个方法具有众多优点，但我还是无法“兜售”出该方案。尽管如此，他们还是同意成立一个特性团队作为试点，如果成功的话，随后将进行完全的LeSS导入。

试点团队结果

• 在第一个Sprint中，试点特性团队能够发布一个启动过程中做客户访谈时发现并被添加到产品待办列表中的新功能。该功能是一个未满足的需求，被很快发现后在一周内发布。
• 用户参加Sprint评审会议，因而能够定期地提供反馈，有定性的也有定量的反馈。我们发现公司以前从未度量过客户满意度。
• 在一些Sprint中，团队动力发生了很大变化。他们开始学习，以逐渐成为多栈开发人员。例如，在一次回顾会议中，一位经验丰富的Windows开发人员表示，他将在接下来的几个月内开始编写Android代码。
• 团队成员的思想和行为发生了变化。他们开始结对工作，并且经常集中力量一起解决问题。他们掌握了这样一个想法：如果每个人都单独处理自己的事情，那么他们就不太可能互相帮助，从而从长远来看不太可能互相学习。
• 该团队能够同时工作在三个管道中，从而进行多个特性的开发。
• 开发过程对产品负责人更加透明。产品负责人说，他喜欢团队选择PBI后不需要额外的协调和控制等就能交付完整特性的，这种像黑盒子一样的工作方式。
• 团队直接与市场互动。他们不需要任何其他角色来进行协调。他们是独立的。
• 与组件团队相比，特性开发的平均周期时间减少了2-3倍。

我注意到一些组件团队成员开始参加Sprint评审会议。他们对试点团队的工作很感兴趣。

我们也发现了这次试点产生的一些负面结果或者困难：

• 产品负责人承受着巨大的压力。他必须与试点特性团队和其他组件团队同时工作。他管理了2个产品待办列表：一个为了以客户为中心的试点项目，另一个是为组件团队提供技术性工作任务。
• 特性团队在与组件团队不同的环境中运作。产品负责人有意保护试点团队在Sprint中不被干扰，比如生产环境缺陷和技术支持要求。因此，有些人说特性团队试点不能被认为是有说服力的实验。
• 特性团队和业务分析师小组之间存在紧张关系。开发人员开始直接与客户沟通。业务分析师将特性团队开发模式视为对其工作岗位的威胁。
• 特性团队无法独立向市场发布功能。产品组中的发布工程师仍然扮演着他们的角色，他们对一个包含很多特性的批量实施最后的系统测试，并做出“可以发布”的决定。因此，功能开发的周期时间虽然确实减少了很多，但再高一层的周期时间却差不多。特性即便已经完成，却仍须排长队才能发布。

公司战略工作坊

LeSS导入是整个公司转型举措的一部分。对公司全面评估后的建议之一是进行战略会议。为期3天的MTS Kassa战略会议分为两个部分。前两天用于建立组织愿景和新的业务战略。第三天则用于创建接下来几个月的路线图。

视觉故事。第二天的重点是建立公司愿景。包含两个活动：首先，使用时间表来显示公司历史中的重要事件并创建产业地图（趋势，参与者，行业，未来市场需求）；其次，将参与者划分为小组，由他们来创建各自版本的公司愿景故事。我们请各个小组想象公司在2年内能够达到的成功，“想象2年过去了，MTC Kassa的故事被刊登在商业杂志的封面上。那里会有什么样的画面/照片/引述？这篇文章是关于什么的？标题是什么？公司的主要进展是什么？”

进行封面故事的愿景练习后，我们开始编写简短的愿景声明。我们希望在所有参与者（将近30人）中达成共识。我们花了几个小时在上面，但这是值得的。因为参与者说，他们切实受到了共创的愿景的激励，这个愿景是：

每个俄罗斯企业家都选择我们的B2B生态系统服务作为其业务的助手。

结果。战略会议的最重要成果之一是高层管理者中涌现了适应性组织的概念。他们一致认为，当前的组织设计是将”让人们忙碌”作为优化目标的。这与适应性的目标不一致，因此，组织设计的一项新的关键决定就是导入LeSS。

我们将人们召集在一起，围绕着明亮且鼓舞人心的愿景，制定了公司路线图。事实证明，这对于创建产品待办列表也是一个很好的输入。

LeSS导入的后续步骤

2017年夏天，我旁听了Craig Larman在米兰的LeSS课程。他的一个建议“像政治家一样思考，而不是像工程师一样” 让人记忆深刻。尽管产品负责人要求我尽快实施LeSS，但Craig的建议帮助我推迟了导入。在特性团队试点取得初步成功之后，我观察到管理层的信任度有所提高。因此，到那时我们已经获得了全面的管理支持。很棒！但是另一方面，我意识到组件团队的许多开发人员仍然对LeSS持怀疑态度。我们想对他们进行教育，以便让他们成为变革的志愿者而不是囚徒 （ 指南：三项导入原则 ）。

转型待办列表

产品负责人，来自产品小组的一些志愿者，试点团队的Scrum Master，还有我组成了最初的转型小组。以下是一些转型待办事项：

• 进行LeSS基础认证（CLB）培训
• 举办多个精益咖啡工作坊，回答LeSS相关的常见问题
• 创建初始的产品待办列表
• 创建HitMap 
• 引导团队自设计工作坊
• 创建完美目标
• 团队选择Scrum Master
• 创建完成的定义（DoD）
• 建立社区并寻找组件导师
• 进行第一次产品待办列表梳理

回顾过去，我们花了将近两个月的时间来准备LeSS结构的导入。

学习LeSS框架

因为每个人都已经参加了Scrum基础培训，所以我认为为期一天的“LeSS基础认证（CLB）培训”，然后再通过几次精益咖啡聚会，就足以使人们接受LeSS。但是，我错了。现在，我认为在引入新的组织结构之前最好花几天时间学习LeSS。人们确实很需要了解LeSS背后的那些原则。您至少需要几天的时间，才能证明精益思想，排队理论和系统思考是LeSS规则的基础（ 指南：三种导入原则 ）。

旧习惯和针对个体的局部优化在第一个Sprint很快就出现。我投入一些时间与开发人员一起进行系统建模，绘制因果关系图（CLD）。人们在使用他人制定的流程和自己拥有的流程之间存在着巨大的差异。在为期3天的培训中，也可以更全面地介绍一些相关主题。

协调似乎是最热门的话题。因为领域狭窄的专家文化和协调角色在公司里存在很长时间了，人们不相信遵循这些简单的指南（ 指南：Just Talk，指南：用代码交流，指南：社区，指南：开放空间 ）能够来管理协调。在培训开始时，跟协调相关的问题，开发人员写满了三张大白纸。于是，我请他们创建一张简单的表格，该表格只有两列：“要协调的内容”和“协调技术”。在介绍了所有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。产品负责人非常强烈地表达他的观点，创建特性团队的想法没有遇到很明显的阻力。每个人都可以看到跨职能跨组件的特性团队可以为公司提供最大的灵活性，并从产品待办列表中交付最高价值。接着我们要求大家为组建团队设置约束条件，下列各项就是他们想到的：

• 跨职能（所有开发，测试，devops等）
• 跨组件（所有平台：Windows，Android，Web）
• UI/UX技能
• 人数从6到9人（推荐）
• 坐在同一房间工作
• 我愿意和这些人一起工作

我不在此详细描述这一过程，您可以通过阅读Ahmad Fahmy的文章获得更多。

我想列举一些我们看到的有趣现象。首先，试点小组的成员是被允许加入其他小组的，但没有人离开。其次，经过两轮（15分钟），我们有了两个稳定的可以满足所有限制条件的团队。但是，第三个团队仍然缺乏UI/UX技能。我不得不引导相关的讨论，讨论时间很长，而最终决定是：

• 团队中的某些人将学习UI/UX
• 使用Traveler这一协调技术（ 指南：Traveler ）

团队自设计工作坊之后，我们组织了一些团队建设活动：

• 团队拥有了自己的名字（“Alfa”，“Vegas”，“StoreCraft”，“Hotfixies”）
• 玩了“技能市场”游戏
• 绘制了所有团队的能力矩阵。开发人员评估了他们自己的技能水平，并识别出了他们想要提高的技能

第二天早上，当我来到办公室时，发现开发人员都已经搬到了各自的新房间。

完美愿景

LeSS的基本原则之一是“持续改进以实现完美愿景”。使用LeSS框架，您可以持续不断地对交付价值给客户加以改进。举个例子，没有额外的角色做协调工作。如果框架将它们包含在设计中，那么如果将其嵌入在系统设计中，人们将有何动力对其进行改进呢？LeSS的目标是使单团队Scrum在多团队环境中也可以工作，而无需引入新的角色和规则（原理：“大规模Scrum是Scrum”）。

产品或组织的完美愿景是一个永远无法实现的状态。在完美愿景的驱动下，人们可以考虑任何实验来进行改进。

我的同事Cesario Ramos给了我一个组织的完美愿景作为例子。我把它打印了出来分发给所有人，以作参考。我们要求团队提出自己的完美愿景。20分钟后，我们在大白纸上写下了所有想法并进行投票。

在回顾会议期间，我们在做出决策时就提到了完美愿景。例如，曾经有一个想法来创建一个专门的协调角色。这与完美愿景相冲突，团队的代表们否决了它。

完成的定义（DoD）

虽然有试点特性团队DoD为基准，但是我们仍然花了一些时间来设计最终的DoD。通常，开发人员对测试术语（集成，端到端，功能，压力，性能）有不同的理解。而且，他们自己的术语过于复杂和繁琐。所以我建议简化分类（ 实验：尝试…简化测试分类 ）。非常奏效。试点特性小组决定引入与LeSS规则相符的也更严格的DoD。他们的完成定义清单上包括额外的代码审查和更严格的测试覆盖率。

选择Scrum Master

在LeSS中，Scrum Master是一个专门的角色，可以服务于1-3个团队。我们期待在改变组织结构的那一天能从市场上聘请到经验丰富的Scrum Master。不幸的是，它根本没有发生。因而，最终我决定成为第二位Scrum Master，直到有人可以代替我为止。这样我们有2个全职Scrum Master（Sergey Gospodchikov和我）与4个团队合作。

团队通过投票来选择想要合作的Scrum Master。我们还引导了为Scrum Master建立期望列表的过程。产生的列表中有一些项挺有趣：

• Scrum Master可能从团队处得到一个臭鸡蛋
• 当您被团队开除时，请不要生气

与社区一起学习

在第一个Sprint之前，我们为团队提供了开始建立社区的机会。这是以开放空间(Open Space)的形式进行的。每个想要建立社区的人都会走到房间的中央，大声宣布社区的成立，然后在便签上写下它的名字，再贴在一张大白纸上。这就是在不到半小时的时间内创建14个社区的方式。

第一个社区在几天后启动，其余的社区则在前两个Sprint中启动了。我们确保每个社区都有Scrum Master的支持来帮助他们定义：

• 社区宗旨
• 工作协议

我启动并支持了Scrum Master社区（ 指南：社区 ）。我们每周聚在一起大约一个小时，分享新实践及Scrum Master技术。例如，有很多次都在讨论关于引导和团队教练的话题。

开发人员定期聚在一起，愉快地参加社区活动。我还记得有一次活动是用mob编程的形式进行自动化测试开发。一位设计师之所以参加这个活动，是因为她想学习自动化。人人想学习！

最初的PBR

产品愿景和商业模式。这使开发人员对产品的理解不仅停留在愿景层面，还能更深入地理解其商业模式。LeSS的产品组是更大的组织环境的一部分，这个环境里有市场、销售、合规性和法律， 等等。这就是我们开始进行最初的PBR的原因。团队先填充商业画布，然后将它们合并为一个。我们一一讨论了商业模式相关的所有领域。对我们在讨论中出现的错误，产品负责人进行了纠正。

尝试…条目拆分工作坊

这是一个典型问题：团队无法将PBI切成更小的PBI。当您拥有特性团队时，足够小的PBI就变得尤为重要，因为我们希望减少小批量生产的可变性，从而减少总的周期时间。我们建议举办一个所有团队参与的条目拆分工作坊。

我向团队分发了印有拆分模式和示例的纸（ 实验：尝试…拆分产品待办列表条目 ）。然后，我启动计时10分钟，要求大家阅读文档。学习的最有效方法是教别人，所以10分钟后我让他们结成对，并给他们10分钟的时间来做学习分享。接着，产品负责人从产品待办列表中选择了一个大的PBI。人们组成了小的混合群体，然后开始拆分这个PBI。

20分钟后，我们重新聚集，每个小组都被要求分享他们的拆分结果。我们重点介绍了一些最成功的拆分选项。我通常在第一个Sprint期间的每个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导入时予以摈弃的。

发布经理。仍然保留了一段时间的另一个协调角色是发布经理。在进行结构更改时，自动化测试包很小，因此产品团队不得不手动执行大量的端到端测试。那本是这位发布经理的最擅长的工作。这些测试很快成为了完成的定义（DoD）的一部分。团队开始自己做，同时扩展了自动化测试包以减少手动测试。

在以前的组件团队结构中，发布经理是最终决定产品增量是否可以发布的人。她得到了留在任何团队的邀请，但她拒绝了邀请。这再次说明了我如何误解了导入LeSS的志愿原则。

好的一点是，发布经理没有抵制LeSS相关的流程，而是积极参与了一些LeSS活动（多团队产品待办列表梳理，总体回顾会议），并领导了一个社区（系统测试）。在两个月内，团队提高了技能，每个团队都可以自己将产品增量交付到市场。在那个时候，发布经理加入了其中一个团队，取代我成为了第二位全职Scrum Master。那是我的建议。因为我注意到她有正确的心态，渴望学习并且想通过使用引导而不是命令和控制的方式帮助别人。

管理。开发中的所有管理角色都立即被正式解散。协调人员和经理们现在成为团队中的开发人员。因此，不再有“团队领导”和“技术领导”的称谓。仍然有一个由他们自己的经理领导的支持和培训部门存在，但它们不在LeSS实施范围内。我认为，将来它们可能会被LeSS产品团队吸收，而DoD也将增加新的扩展：为客户创建视频和网站教程。

学习使用LeSS框架跑迭代

第一个迭代

正如俄罗斯谚语所言，“不犯错，不成事”。对于第一个Sprint来说确实如此。尽管进行了所有准备和培训，但团队仍然不得不直面局部优化的弊端。以前，公司从来没有以客户为中心的产品待办列表。现在，产品待办列表中的排序主要由对客户的重要性决定。

当Android开发人员和设计师查看产品待办列表时，他们可能会发现他们在第一个Sprint的工作量不足。他们不得不在Sprint中花费大量时间来学习和帮助他人。这是Scrum导入中的一种常见情况：团队因骤然背负上这些始终存在但隐藏在筒仓中的“知识债务”而变得痛苦不堪。在筒仓（和知识债务）很大的大规模导入中尤其如此。这种全新的“学习的组织转移”（organizational transfer of learning，这是1986年HBR Scrum论文中的原文。译者注：这篇Scrum论文是“The New New Product Development Game”）对于团队成员来说是非常陌生的，以至于有些人对教与学感到不舒服，因为他们认为还不如“做一些产出更多的事情”。

我们发现了一些在启动过程中没有考虑到的问题。例如，如何处理来自技术支持的紧急任务和错误。另外，我们没有考虑如何提前进行回归测试。而且不幸的是，存在巨大的技术债务，并且自动化测试的覆盖率很低。

我还注意到，人们因大量的培训和漫长的（3天）启动而感到非常疲倦。尽管如此，第一次Sprint评审会议还是成功的。团队在Sprint评审会议期间演示了PBI。参加评审的内部干系人也给予了他们积极的反馈。

在第一个Sprint期间，出现并积累了很多问题。团队中有许多问题都很类似，因此在Sprint评审会议结束时，我建议与产品团队中的每个人一起参加比以往更长的总体回顾会议。我们耐心地花了三个小时。结果是：

• 针对那些在Sprint期间没有足够工作是匹配其主要技能的开发人员：帮助团队中的某个人（通过结对），继续学习新技能，帮助其他团队。
• 如何进行回归测试并实际发布产品增量。我们澄清了先前创建的完成的定义（DoD），并对其进行了扩展。
• 在Sprint期间如何处理紧急任务和缺陷：它们都通过一个单独的slack频道进行沟通的，任何有闲置带宽的团队都可以工作在其上。

第一个Sprint并不容易，但是产品负责人和大多数开发人员都致力于向前推进乃至实现目标。

导入可视化管理

产品待办列表的可视化管理。我们从一开始就可视化了产品待办列表（ 实验：尝试…可视化管理产品待办列表或发布待办列表 ）。产品负责人和反对Scrum导入的两个人，因此也不应该成为该小组的成员（两位业务分析师），维护着墙上的产品待办列表，保持它一直在最新的状态。每张便签纸都代表一个PBI。待办条目沿着墙从左到右移动，进入“Ready”状态，最终成为迭代待办列表的一部分。

迭代待办列表的可视化管理。我建议团队可视化他们的迭代待办列表，并限制进行中的工作（WIP）。我们举办了一个关于限制队列大小的简短工作坊，并播放了“FeatureBan”。我认为这段简短的视频完美地说明了为什么您需要限制WIP以及如何更好地管理队列。每个团队都为迭代待办列表设置了明确的WIP限制。

可视化管理有助于协作。在LeSS中，团队之间没有依赖关系。为什么？任何特性团队都可以为其待办条目跨代码库工作。团队应用诸如持续集成、社区、多团队工作坊以及共享和交换工作之类的方式，对彼此进行管理和协调。因此，团队要做的就是合作和共享工作。

在迭代计划会议第二部分时，我们发现在需要几个团队之间协作的PBI上做上标记对即将到来的迭代会很有帮助。通常，我们就在条目上面贴一个写有对应协调技术（例如“侦察员”，“组件导师”，“只是说”等）的小便签。

可视化管理工作协议。所有主要的工作协议（DoD，“Ready”等）和回顾会议的产出项与产品待办事项都保存在同一房间。我们将LeSS的活动时间做成一个可以看到的时间表，并将其挂在走廊的墙上。它旁边还有一个社区活动时间表。

尝试…可视化会议

我是David Sibbet和可视化会议的粉丝。我喜欢在会议中可视化所有内容。我将视觉会议称为“活的”会议，是因为它可以激发高水平的参与度，呈现正在发生的事情的全面情况，并支持群组记忆。以下是“活的”会议与“死的”会议的区别：

• 与会者们站着进行积极的讨论
• 以小组形式（最多5人）进行工作
• 没有电子设备，只有黏胶，马克笔，剪刀，大白纸和打印纸
• 可视化正在讨论的所有内容（每个人的声音都被听到)
• 周期性的分散和合并有助于团队从小组讨论和自主讨论中受益，并在整个会议期间与他人保持同步（合并）

协调

有趣的是，在引入LeSS之前，团队将协调视为最重要的问题。我在精益咖啡聚会时注意到大多数问题都与协调有关。我们很快就解决了这个问题。在一次性更改团队结构之前，我们进行了LeSS基础认证（CLB）培训，期间我们讨论了协调。从我的观察中可以看出，最常使用的协调方法是：“指南：用代码交流”、“指南：只是说”，及其更高级的版本“只是喊”。

团队还在迭代计划第二部分的时候及时选择了所需的实践。LeSS依靠基于自组织的协调行为。自组织的重要要素之一是所有团队的房间都通过一个大走廊相连。我们还有一个共享的房间，在里面可以看到所有的信息。

迭代计划会议第一部分

在迭代计划会议的第一部分开始前一个小时，产品负责人和两名业务分析师对产品待办事项进行了最终更改。然后，所有的团队代表（通常每个团队2人）参加了迭代计划会议第一部分。

会议议程。我们通常遵循下面的议程：

• 产品待办事项更新（未完成的工作返回到产品待办事项，并重新估算剩余的工作）
• 产品负责人简要介绍处于产品待办列表顶部的待办条目，并根据请求情况对这些条目的部分细节做最后的澄清
• 再次查看“完成的定义”（DoD）
• 团队代表从“就绪”区域顶部开始实际选择PBI，并将它们放入团队的泳道中
• 找到团队之间需要进行合作的待办条目，在公告板上对它们进行标识
• 决定团队是否需要多团队迭代计划会议第二部分
• 为整个产品团队定义一个共同的迭代目标 并且/或者 为各个团队定义各自的迭代目标

迭代目标。LeSS中并没有提到迭代目标，因为LeSS的原则之一是“大规模Scrum是Scrum”，所以LeSS不会拷贝粘贴Scrum指南中的元素（ 以避免重复 ）。

LeSS中迭代目标的例子。问题出现了：是为整个产品团队定义一个迭代目标，还是每个团队都应该有自己的迭代目标，还是两个都定义？没有标准答案。我认为所有选项都是可能的。这里有一些例子：

1. 第一个迭代的共同目标是“启动LeSS”。除此之外，阿尔法团队有自己的目标“为收银员创建订单”。
2. 第二个迭代的共同目标是“告别组件团队的传统”，每个团队还有其他目标：“完成货物进口模块”，“完成收银员的订单创建”，“收银员+ MGTS”， “发布+ yandex OFD”。

就像您看到的这样，可能有不同的组合。个人来说，我比较喜欢整个产品团队定义一个共同的迭代目标。

迭代计划会议第二部分

在我们的案例中，迭代计划的第二部分是微不足道的。因为在会议的第一部分中识别了所有的协调可能性之后，团队会决定是否应该一起讨论多个团队的计划。如果需要的话，团队决定在一个大的共享空间中进行迭代计划会议第二部分（ 指南：多团队迭代计划第二部分 ）。但大多数情况下，团队只是回到自己的房间，在Scrum Master的帮助下创建他们的迭代待办列表。最多花30-40分钟。对于迭代待办列表的工具，我的建议与LeSS指南一致（ 指南：不使用软件工具管理迭代待办列表 ）：

“不要为迭代待办列表使用任何软件工具；只用使用可视化管理，可能只是贴在墙上的卡片（大规模Scrum：以少为多）”

学习LeSS中的待办列表梳理

在大规模Scrum中，PBR是一个强制性事件 （而不是可有可无的活动）。之所以这样，是因为产品待办条目在大型产品团队中确实非常大，非常需要在整个团队层面进行广泛的协调与学习，并且根据实际需要安排一定数量的与客户和用户的会议。在LeSS中，有几种PBR方法（ 指南：产品待办列表梳理 ）：

• 团队代表参加的整体PBR，这意味着高阶的分析和展望，估算和待办条目分解（ 指南：整体PBR ）
• 多团队PBR。一个房间中的多个团队可以同时优化多个PBI（首选）（ 指南：多团队PBR ）
• 单团队PBR。跟单个Scrum团队的做法一样

对于应该使用哪些产品待办列表梳理的方法组合LeSS没有设定任何规则，但是LeSS建议进行多团队产品待办列表梳理。让我们来仔细看一下。

整体PBR

在第一个迭代中，尽管时间应该可以再短一些，整体PBR仍然花费了我们好几个小时的时间。每个人都精疲力尽。在下一个迭代中，通过更好的引导，时间缩短了两倍。开放讨论花费的时间很长，参会者往往心不在焉，倍感厌烦。为了保持拥有充沛的精力，我对所有活动作了严格的限时并建议举办一个事件。

我们使用了相同的引导方法。产品负责人从墙上拿下一个PBI进行讨论，然后他使用5-10分钟对提出的问题进行澄清。

然后进行明确的估算。如果PBI超过13个点，我们就将其拆分（ 实验：尝试…细胞一样的拆分而非树状拆分 ）。

多团队PBR

谁会想到，为什么需要几个团队在一个房间里工作并同时优化几个PBI？每个团队进行自己的单团队PBR会 “效率”更高吗？让我们弄弄清楚。

适应性。如果几个团队对几个PBI都了解，则产品负责人可以推迟决定哪些PBI该包含在接下来的迭代范围里，不用受特定团队只有某些特定知识的约束。它为产品负责人的修改优先级提供了更大的灵活性。

了解产品。团队对PBI了解的越多，他们对业务领域和产品本身的了解就越多。而且只有一个团队关注可能会有遗漏的方面，有更多个大脑进行思考，这些条目的澄清就会更彻底（ 原理：关注整个产品 ）。

基于自组织的协调。团队了解的PBI越多，他们越能够在迭代中互相帮助。因此，也越容易出现基于自组织的协调。下面是相关的系统模型：

多团队PBR的复杂性

多团队PBR有许多好处。尽管如此，还是有一些问题。让我们看看它们。

信息过载。同一房间中参与多团队PBR的团队越多，他们需要了解的PBI就越多。因此，信息过载可能是多团队PBR的副作用。

引导。要让数十人参加这个事件并不容易。如果引导不当，则会造成浪费，从而开发人员不再希望参加多团队PBR。让我们在系统模型中探索一下：

多团队PBR引导技巧

我想分享一些使多团队PBR更有效的技巧。

充分的准备。准备最多可能会需要几个小时。它包括但不限于：事先与事件干系人会面，制定引导计划，在活动挂图上进行可视化（目的，议程）以及在事件之前准备好空间（移走桌子，椅子，放置活动挂图架等等）。

• 热身。我认为通过小型游戏或破冰活动开始任何LeSS事件以提高参与度很重要。您可以在《Moving Beyond Icebreakers》一书中找到很多类似的活动。
• 小组。您可以使用小组和其他分散技术有效地引导有很多人参加的会议。《Facilitator’s Guide To Participatory Decision Making》一书中有许多以小组进行工作的形式。

“中心化毁了活力；去中心化创建活力（大规模Scrum：以少为多）。”

混合组。除了前面的建议外，小组最好是由来自不同团队的成员组成。

“从由每个团队的人员组成临时的混合小组开始。例如，两个团队重组为两个混合组（大规模Scrum：以少为多）。”

这是增强不同团队之间的协作并减少信息分散的方法。每个团队的每个成员都是常识谜题的一部分。

分散-集中和轮转。除了前面的两个建议外，这是可用于大型人群引导的另外两种技术。首先是将PBI分配给每个小组，让他们在多个站点并行工作并完善到“就绪”状态，然后每个人都参加到一个集中的公开讨论中。

“各个小组花一些时间在房间的不同区域分别工作，以完善不同（或相同）的项目，然后花时间在一起共享各自的见解，提出问题并寻求其他协调机会（大规模Scrum：以少为多）。”

轮转表示小组从一个站点到另一个站点按顺时针方向移动多次，而业务专家仍然停留在对应的站点上。每个工作站点都工作在自己的PBI上。我非常喜欢这种做法，并且对它的效果有过多种体验。想象一下，第一轮大约需要20到25分钟，然后另一个小组接近了这个站。该小组尚不熟悉该站点对应的特性，但是他们拥有先前工作在该站点的小组创建的有关验收标准、界面等信息。他们所需要的就是去掌握新信息。

可视化管理。通常，当人们在会议期间使用电子设备时，这些会议就死定了。忙活于键盘的某些人成为了瓶颈，其他无聊的人则盯着他们的电话。另一方面，剪刀，纸，便签纸和大白纸会激发协作。

站着工作。如果可能的话，我会从进行多团队PBR的房间里挪走所有椅子。人们站在一起开的会议更加活跃，人们参与度更高，精力更充沛并且专注。

“就绪”的定义。当团队在工作站上梳理PBI时拥有相同的“就绪”定义时，就会蓬勃发展，因为可变性大大降低了。这是我们都同意的“就绪”的第一个版本：

• 每个PBI都有一个大小估计（以点数为单位）
• 产品负责人提供了商业价值估算
• PBI小于13点，否则就要被拆分
• 对特性的理解至少为10分的7分，其中10代表对PBI的完全理解，无需其他说明
• 如果需要图形界面，则需要有高仿真视觉稿
• 验收标准已经定义

严格的计时。不要让会议“垮掉”。对世界咖啡的所有活动和轮数使用严格的时间盒（轮转），并设定到时提醒信号。时间到了的时候，别害怕叫停小组，并且问他们需要多少时间。

反馈。在每个PBR事件结束时进行一次小型回顾。我要求每个人以1到10的比例评估事件的有效性，并附上详细的反馈。

我们尝试过不同形式的多团队PBR。经过一段时间，形式逐渐稳定，此后我们没有做太多更改：

• 团队，产品负责人（可选）和专家参加多团队PBR
• 使用混合小组的组织形式
• 混合小组选择要讨论的产品待办列表条目并将其带到工作站
• 在工作站工作，估算、完善和编写直至“就绪”状态的验收标准。如有必要，可以添加视觉稿，图表，示例和其他图形说明
• 专家留在车站，而其他参与者则轮转（世界咖啡），探索由其他小组改进的PBI

我发现，多团队PBR能正确完成后，迭代计划的两个部分都不会超过一个半小时（最多两个小时）。多团队PBR已成为此导入中的关键事件，因为它是协调，更好地了解产品和适应性的驱动力。

迭代评审会议

早期的迭代评审是在没有最终用户的情况下进行的，产品负责人仅邀请了内部客户。团队希望在从市场上邀请嘉宾前能够练习一下。这就是为什么迭代评审会议的第一批访问者是其他部门的员工：技术支持，市场营销，销售，人力资源和合规。通常的迭代评审会议是：

• 产品负责人启动会议，大声宣读产品团队为之努力的迭代目标。产品负责人宣布哪些条目完成了。
• 团队很快地分享一下迭代期间的主要障碍以及他们是如何应对（或不应对）的。
• 邀请来宾以集市的形式或以更结构化的展会形式参观一个或多个站点。在每个站点中，我们至少有两个开发人员，其中一个演示产品增量，然后请求一个开放式的反馈，另一个则默默地做记录。
• 演示之后，我们回到了公开讨论的形式。产品负责人分享市场动态，修改优先级（如果需要的话）并回答问题。
• 当来宾离开后，团队和产品负责人将多个站点的反馈进行合并，并更新其中的一些工件：影响地图，价值主张画布，用户故事地图，当然还有产品待办列表。

聚焦整个产品。我注意到，未参与本团队站点的开发人员正积极地在其他站点间走动，并向同行提供了反馈。他们对其他人的工作变得真正感兴趣。在这儿或那儿组成了小组，对产品展开了一些有趣的讨论。

尝试…创新游戏

最终用户每两个迭代来访问一次。我们经常使用两个完美互补的创新游戏：“快艇”和“修剪产品树”。快艇可以很好地识别客户的痛苦和需要完成的工作。修剪产品树则非常适合为产品待办列表找到更好的解决方案（特性）。

团队回顾

对我而言，Scrum回顾会议始终是一个特殊事件。从组件团队结构向特性团队结构转变对人们来说是一个很大的转变。因此，我估计在早期的回顾会议中会出现无数的问题。我是对的。第一次迭代对每个团队来说都有巨大的压力，我们将总体回顾与团队回顾结合为一个大事件，因为几乎所有问题都是相同的，并且在解决问题时包括整个产品团队非常重要。每个人的参与和符合SMART原则的改进项起了很大的作用。压力显著地降低了。在接下来的迭代中，除了整体回顾之外，每个团队都各自进行了自己的团队回顾。

系统和团队层面的障碍。在全面回顾期间讨论系统问题时，我总是要求团队将系统障碍与团队障碍分开。我经常使用活动影响圈。在大白纸上画两个圆圈，一个大圆套一个小圆。里面的圆圈可以填充团队可以自行解决的主题，外面的圆圈则填充跨越团队边界的一些问题。

整体回顾

迭代的结束是在周末（星期五），这也是为什么决定在下一个迭代的星期二下午进行整体回顾的原因。产品负责人，Scrum Master和团队代表是永久的参与者。

完美愿景和八个讨论主题。LeSS导入时，团队创造了完美愿景。理想中的组织会是怎样，这是一个永远无法达到的检查清单。检查了整体回顾期间所做的任何决定，以了解其与完美愿景的一致性。整体回顾聚焦在八个主题上，您可以到LeSS网站查看细节。我们在每次回顾会议上都会提醒团队的，以及许多已经被遗忘且没有被聚焦的问题。

我想列举在回顾会议期间讨论的一些问题：

• 所有团队均已完成所有DoD
• 增强完成的定义（DoD）
• 一个迭代里的生产缺陷分布
• 团队与技术支持小组的互动
• 更改发布周期

学习与7个团队合作

当得知MTS和LiteBox在2017年同意将团队数量增加到7个时，我认为这是一个很大的惊喜。因此，在结构改变之后，很快有更多新团队加入了产品团队。

RITG团队来自外包合作伙伴。产品负责人非常有热情去组建新团队。他与同一城市的一家外包公司建立了合作关系。几周后，一个名为RITG的新团队被添加到产品团队中。有好几个迭代，我们试图将新团队融入流程中，但不幸我们失败了。在PBR期间，沟通问题给我们带来很大的困扰。此外，他们没有人参加“ 迭代评审会议”。于是我建议让新团队也来办公室工作。虽然最后产品负责人成功做到了，但这绝不是一件容易的事。从那时起，我们在同一办公室就有了5个团队。

ROST团队在办公室。同时，公司HR帮助我们组建了另一个名为ROST的特性团队。前试点特性团队的两名成员加入这个特性团队里工作几个迭代，以帮助这个团队舒适地过渡。

来自乌克兰的远程团队。从产品的早期开发开始，MTS Kassa在乌克兰就有几个开发人员。这些人甚至参加了最初的Scrum培训。我们都同意暂不将他们纳入到产品团队中，直到他们可以在基辅组建一个同地办公的特性团队（他们远程工作并且居住在乌克兰的不同城市）为止。这终于发生了。

不幸的是更多的中间商。我之前提到过，导入该技术的主要失败点之一是启用了不支持变革但充当团队和客户之间中间人的人员。团队数量增加了，并且有职能障碍的业务分析组也增加了人员。他们聘请了一位新的业务分析师，主要从事对外的工作。这是当时结构的外观：

将重点从本地改进转移到系统改进

在最初的几个月中，我们聚焦于在新的LeSS结构中建立有用的流程，熟练地举行LeSS事件（相信我，多团队PBR和迭代 Review不容易做到有效地实施）并且确实取得了很多进步。最初，大多数开发人员是LeSS的新手，我们处理的大多数问题是：

• 学习和发展一专多能人员
• 在迭代期间互相帮助
• 集中力量协同工作在PBI上
• 加工迭代待办列表
• 在迭代待办列表中限制WIP

从一开始，特性团队与社区之间就非常契合。无论如何，经过一段时间后，很显然我们应该关注的大多数问题都在系统级别上。几乎所有系统问题都与3个主题相关：技术债务，CI / CD和从想法或者干系人请求到交付的需求流动。

社区的发展

社区还活着。7个月后，仍然有5个社区（CI / CD，QA，Scrum Master，UI / UX，前端）仍然存在，有2个社区（CI / CD和后端）合并为一个社区（CI / CD），其他社区则不存在了。这是正常的。出生和死亡的过程对于社区来说应该是自然发生的。

协调。社区每周或每两周定期开会。每个社区都有自己的slack频道。在最初的几个月中，会议的组织主要由Scrum Masters引导，但是随着时间的流逝，人们变得熟练，学会了自己做会议引导。无论如何，Scrum Master仍然可以按需提供服务。有些时候社区会有需要。例如，我记得对于前端社区来说的一个重要时刻，是当他们不得不选择多个框架之一的时候。那确实是一个艰难而复杂的决定。他们需要帮助，并邀请了Scrum Master协助他们最终达成共识。每个社区在一个放置公告的共享房间里都有自己的一块墙面区域。

将社区建议包括PBI在内。会议的结果通常是一组技术性PBI和改进，社区建议团队和产品负责人将其包含在Product Backlog中。

改变需求流动

需求的多个问题。回顾整体回顾中提出的系统问题，很明显，其中许多问题与需求流动有关。的确，在最初的几个月中，我聚焦于团队的教练和活动协助。我没有足够的时间来指导产品负责人和/或不支持LeSS导入的BA团队，因此没有花足够的时间跟他们一起工作。我从主要内部干系人（市场营销，销售部门）那里得到的反馈是，他们对产品团队不满意。因为对他们来说产品开发是一个黑盒子，他们告诉我产品负责人对他们的要求没有给予足够的重视。另一件事是：我意识到条目从产品待办列表到迭代的流动还不够好。PBR的运行不像我希望的那样顺利，有时团队会为迭代选择过于模糊（“未就绪”）的特性。于是我建议重点关注需求流动。以下就是我们所做的。

产品工作坊。我为产品负责人，BA，Scrum Master和团队代表进行了为期2天的动手工作坊，在此期间，我们有：

• 使用电梯推销形式调整产品愿景
• 使用Job / Pains / Gains模板彻底分析和讨论了8个客户描述档案
• 为下一季度制定了业务目标（降低客户流失率），并使之符合SMART原则
• 创建影响地图并确定影响的优先级
• 过滤出产品待办列表中与影响地图有关的特性
• 产品待办列表中某些重要特性的用户故事地图

产品负责人现在已经有了新工具，他还看到了愿景、业务目标、客户目标和特性之间的紧密联系。从那时起，我们建议团队对整体PBR和多团队PBR使用不同的形式。

调整后的梳理流程

在产品工作坊结束后，我们邀请了团队代表（他们每个迭代轮换以避免特权或单一岗位），共同为整体PBR和多团队PBR创建了一个新流程。这就是我们即将看到的。

整体PBR：

• 简短讨论和快速估算
• 如果估算超过13个点，则使用故事地图或拆分模式来分析该特性

单团队PBR：

• 仅适用于乌克兰团队

多团队PBR：

• 对于3组不同的团队，每个迭代内进行2次
• 详细讨论
• 验收标准已创建
• 如有必要，可改变估算值

需求相关的新流程比老流程要好得多。首先，该流程更加严格。我们明确定义了每个步骤的输入和输出。另一个要点是，现在每个特性都清楚地表达了与客户和业务目标的关系，这对于内在动机很重要。每个团队都再次参加了拆分工作坊并学习了用户故事地图技术。确实，在一些迭代中，新流程对团队来说非常令人愉快（至少他们这么告诉我们），而且需求的流动得到了改善。现在，我们在迭代期间的“惊喜”减少了，产品负责人有了更多的空闲时间（他只用参加整体PBR），并且周期时间减少了。

经验教训和导致的实验

您在案例中已经阅读了一些实验（ 尝试…避免…… ），因为它们非常适合嵌在案例里。在下面，您可以看到我回顾了整个LeSS导入之后做的一些实验。您也可以把它们当做是我的经验教训。

避免…持怀疑态度的人加入

在典型的职能型组织设计中，人们充当机器的齿轮，仅执行一项职能。但是人们具有学习的元技能，并且可以在基于团队的组织设计中变得更加灵活（  指南：构建基于团队的组织 ）。在更改团队结构之前，我注意到有些人对公司将成为基于团队的组织这一事实感到明显不满。他们真的只想成为一个狭窄领域的专家，他们不喜欢Scrum，感到非常不满，并且他们直言不讳。他们没有隐藏自己的动机，而且很直率。老实说，我当时想尽快导入LeSS，现在我知道那是一个巨大的错误。您可能无法想象如果几个人真的想破坏变革，他们可以造成多大的毁坏和伤害。Kotter博士有一段讲述了抵抗的录像带，他的建议是：

“不管他们与您的关系有多强，都不要管他们，因为如果您邀请他们进入帐篷，他们会造成很大的损害，以至于毁了整个变革。”

尝试…以后仅使用志愿者翻转

相反，结构上要做好准备，并尽可能使用100％的志愿者。这将节省您的时间，而且此时的LeSS导入对每一方都是愉悦的。

避免…团队和Scrum Master向产品负责人报告

正如我之前解释的那样，作为产品负责人的CTO对我们来说是很自然的选择。但几个月后，我们仍然受到负面影响。正如公司管理层所预测的那样，客户群迅速增长，产品团队承受着提供更多产品的巨大压力。新的请求通常来自市场营销、销售以及新客户要求的定制解决方案等。我没有注意到产品负责人在结构变革之前聘用并解雇了开发人员，之后决定聘用和解雇的也仍然是他，所以这一点在实际上没有任何改变。团队直接向他报告。例如，想要加薪的开发人员需要与联系他并开始谈判。我想引用 指南：LeSS组织结构 中的：

“在这种组织结构中，重要的一点是，团队和产品负责人是同行，他们之间没有上下级关系。”

一位Scrum Master告诉我，产品负责人开始质疑团队的预测，对他们施加压力，并长期对团队的绩效不满意。Scrum Master们尽其所能，尽力保护自己的团队，但在整体回顾期间，他们曾经与产品负责人发生冲突，并被其警告可能被解雇。虽然我们设法解决了冲突，但是从那一刻起，很明显，产品负责人成为团队的老板是一个组织级别的障碍。它在我们的障碍列表中。我们仍在努力。

避免…在DoD不是可交付时规模化

DoD和每个迭代透明的可交付增量从来都是Scrum的核心，但在规模化环境中显得尤为重要。为什么？增加新的团队并拥有薄弱的DoD意味着您将职能障碍也扩大了。未完成的工作随着更多的团队而积累得更快。如果您的技术债务很大，请不要添加新团队，添加新团队就像用汽油扑灭大火一样。相反，应聚焦于移除undone并使产品增量完全透明。

尝试…使DoD尽可能详细

完成的定义（DoD）的初稿被创建后运行了一些迭代，直到我们注意到不是所有的团队都在平等地遵循DoD。我们开始调查此问题，发现原因是DoD的第一个版本不够详细，可以用不同的方式解释。而且并非所有术语和用词对所有团队都具有相同的含义。所以协议不是100％明确。因此，我们再次合作，对DoD作了澄清，并使其尽可能详细和具体。现在，我建议您使用以下形式定义DoD：将其放在大白纸上并划分为两列。在“活动”列中描述活动本身，在“标准”列中回答问题：我们如何衡量或清楚地知道活动真正地完成了？准备好花2-3个小时来澄清DoD，但这是值得的。

尝试…解释DoD定义适应性

我发现许多产品小组只知道DoD是一个正式的检查清单，却不知道DoD其实还定义了他们的适应性。我还发现，当您向团队和业务部门展示DoD其实定义了敏捷性时，他们就开始更加认真地看待DoD。请参照下面的系统模型图例。在这里我在LeSS导入几个月后就做了，以后我将努力在LeSS一开始导入的时候就做。

尝试…成熟又勇敢的Scrum Master

即使对于单团队而言，导入Scrum也是一个巨大的变化。拥有勇敢的 Scrum Master似乎是LeSS导入成功的关键因素之一。勇敢的Scrum Master是指一个可靠而经验丰富的人，能够谈论不受欢迎的事情并能够揭露丑陋的真相。我的一位客户（一家大银行）决定聘请经验不足的年轻大学毕业生，让他们担当Scrum Master。实验惨败。年轻人能够学习如何引导。他们准备了精美的大白纸，并绘制了可爱的燃尽图。但是他们没有成为变革推动者，也无法消除任何组织障碍。他们还不够成熟，没有做好在压力下工作的准备。在MTS Kassa中，很高兴与2位优秀且成熟的Scrum Master合作。他们保护了团队，有时还要直接面对产品负责人和高级管理层。谢谢他们！

尝试…向其他LeSS导入方法学习

2018年，我帮助三家公司导入了LeSS，并认识了很多人，包括产品负责人和Scrum Master。DoDo Pizza是2018年在俄罗斯导入LeSS的公司之一。他们在工程实践方面尤其强大。产品负责人询问他是否可以拜访并了解一下LeSS在该公司中是如何实施的。我帮助他实现了。他带回来了很多洞察。我认为非常有帮助，因为许多技术相关的PBI随后就在Product Backlog中出现。在之前却从来没有发生过。

尝试…找到一位经验丰富的LeSS导师

在导入MTS Kassa的过程中，我并不孤单。在那时，我获得了一位经验丰富的导师Cesario Ramos的帮助，他是LeSS认证培训师（CLT，Certified LeSS Trainer）。一年中，我们通过chat进行了沟通，还共同培训了三次LeSS认证实践者课程（CLP，Certified LeSS Practitioner）。在共同培训期间，我从Cesario那里听到许多战争故事，并且有机会观察他是如何回答学生的棘手问题的。每次培训我都会从他那里学到新东西，他的每堂课都是独一无二的。除了共同培训外，我的导师还支持我根据需求为不同的工作坊提供他个人的材料：LeSS中的完美愿景，产品的定义，人员和奖励。拥有经验丰富的LeSS教练作为您的导师是发生在我身上并且可能会发生在您身上的最好的事情之一。您将拥有加速的个人成长！

结果

这是我参与过的最具活力的变革之一。我作为教练参与始于2018年1月，至今仍在继续。计划在今年年底之前将更多的团队添加到产品团队中。显然，还需要增加一个频道（iOS）。

当我问产品负责人（也是公司的CTO）时，他从LeSS中学到的最有价值的东西是什么，他提到了几点：

• 通过添加独立的特性团队，可以轻松进行扩展的能力。
• 优先级保持透明（通过产品待办列表），并清晰地概述了正在进行的工作和进度。
• 快速交付价值。回到2018年1月进行的第一次评估时，特性的平均周期时间为5周。现在，特性通常能在两周的迭代中完成。

总结一下，我想从我的视角强调一些其他重要的观点：

• 一月份，我开始与一个人们没有学习动力的典型职能型组织合作。在半年的时间里，这已经是另一个组织，UI/UX设计师开始想学习编程，五个社区蓬勃发展，人们不断发展新技能。
• 人们在一对一的对话中指出，他们对工作的感觉更好。一月份，他们都是狭窄领域的专家，他们希望尽可能地“利用”自己。项目团队的开发人员不想合作和互相帮助。通过实施LeSS，人们终于意识到了他们内部需要改进，学习并变得更好。神奇吗？

致谢

我要感谢公司的高级经理：Sergei Muzykantov 和 Roman Ariffulin。他们在2018年1月时相信LeSS。该案例是俄罗斯第一个官方的LeSS案例研究。Sergei和Roman的确是先驱。感谢他们的勇气和前进的愿望。

另外，我还要感谢Sergey Gospodchikov。他是俄罗斯第一位LeSS Scrum Master。他对Scrum价值观的身体力行，毅力和执着的奉献精神为整体成功做出了巨大贡献。