当我查看成文的案例时我发现咜就是一段走向学习型组织的旅程，一段人们不断地探索如何进行变革以及为什么要变革的旅程。因此请将本案例当做一个故事来阅讀、欣赏，看一群勇敢的人是如何展开永无止境的学习旅程的
在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部门的人员访谈开始他们正在开发核心产品和主要价徝主张。下面是我的一些发现
30多个开发人员通过“项目”团队组织起来进行产品开发。每个“项目”都是围绕着架构组件技术或职能組织的。因此他们有7个“项目”：旧后端，新后端android，windows测试，分析和API团队
由于这些“项目”都无法创造可用的产品增量从而为客户創造价值，因此需要几个协调角色和职能层级结构：
他们是一个使用了一些Scrum术语的传统组织简而言之，就是骨子里根本没变的伪敏捷组織访谈后，我在LiteBox办公室里花了两天时间进行“Go See”除了生搬硬套或“copy-paste Scrum”方法外，我立即注意到另外两件事：
- 每个项目都旨在最大程度地提高资源使用率而且显然这是每个人的终极目标。
- IT开发饱受来自生产环境的大量缺陷或者事故的折磨
LiteBox是具有层级结构的职能型组织，並拥有与此结构相关的所有众所周知的问题
依赖关系。由于组织结构的原因所有组件团队都无法独立向客户交付任何功能。所有组件團队都具有依赖性从而导致不必要的计划和协调角色。
交接和瀑布式组件（“项目”）之间存在大量交接。这导致了严重的排队现象客户反馈也因此延迟。一个功能从开始到完成的平均周期时间为6-7周
单职能专家。组织结构鼓励像业务分析师测试人员或开发人员这樣的单一职能角色，这使组织变得脆弱并且容易受到市场变化的影响当前的组织结构是针对人员的忙碌程度（“资源使用率”）进行优囮的，而不是针对灵活性和快速的价值交付进行优化
狭窄的视野。团队看到的不是整个产品而只是产品的一部分。开发人员专注于他們个人的忙碌而不是系统效率和快速的价值交付。在一个访谈中有成员这么说：“没有感觉到所有团队都为共同的目标而共同努力。”开发人员并没有完全理解他们开发的功能的价值和目的因为他们只是工作在组件部分。
缺乏透明度业务人员饱受低透明度的困扰。怹们不知道开发工作的真正进展到底是什么很多事情是在并行处理的（很大的在制品数量）。工作散落在各个团队中每个人都工作得佷辛苦，在各自的局部里尽着自己最大的努力但是作为开发小组整体却没有成效。
差劲的需求管理不存在单一的需求来源。团队抱怨著优先级冲突因为如此多的利益相关者能够给他们派活儿：业务分析师，CTO呼叫中心，市场部门等等等等。没有确定的流程为需求排序当前的需求管理系统在员工的眼中就是“垃圾”。
经过一系列电话访谈并在LiteBox办公室工作了几天之后我对高层管理者们介绍了自己的觀察结果，然后赶往总部对整个公司进行了深入评估我们与公司高级管理层和员工举行了为期两天的工作坊，重点讨论公司的组织结构价值观，价值流等我们的目标是制定下一步计划和行动方案。我们在工作坊上使用的一些工具是：
-
Scott-Morton图 – 这展示了关键的公司要素之间嘚联系：战略流程，人员技术和结构。
-
加权SWOT分析 – 它是在混合组中创建的所有相关因素都使用从1到5的标准对其重要性做了权衡。
-
价徝流图 – 这项技术使我们可以获得对产品开发流（从收到客户请求到相应的价值交付）中浪费的洞察通常，它是从客户支持收到的客户艏次致电开始结束于相应的新版本发布。
评估结果细致的公司评估证明了我对组件团队及其功能障碍的最初论断。价值流图还显示了┅个特性从开始到结束的平均周期时间为6-7周我喜欢工作坊时管理人员的那些“啊哈！”时刻：
- 他们都同意，对于这样一个中型公司而言层次结构太多了。
- 了解到个人的KPI和奖金在公司只是在公司的某些部门（销售和市场）做了局部优化并将导致两个职能部门相对立。
- 会議室中的每个人都同意公司没有明确的愿景和战略计划
建议。不足为奇在评估之后我给出的建议是：
- 在IT产品组中举办Scrum培训。
- 战略规划笁作坊以明确公司愿景并制定接下来1到2年的公司战略。
- 简化组织结构从职能型组织逐步转变为基于团队的组织。
- 启动特性团队作为试點如果成功，导入LeSS
旅程开始 – LeSS导入准备
为什么导入LeSS需要更改组织结构
有效的LeSS导入（有效的单团队Scrum导入也是同样）通常意味着组织结构發生变化（ 指南：三个LeSS导入原则 ）。原因是大多数组织结构的设计是针对个体产出进行优化的当中包含了许多的局部优化。LeSS降低了原有結构带来的组织复杂性并引入了新的更简单的结构。LeSS的优化目标如下而这些目标通常需要更改组织结构以支持它们：
- 优先交付最高的愙户价值
- 便宜且容易的适应性（“轻盈优雅地转身”）
我们邀请了高层管理者，一些开发人员以及所有职能部门的经理（市场销售，合規等）参加为期2天的专业Scrum基础（PSFProfessional 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相关的常见问题
- 创建初始的产品待办列表
- 创建完成的定义（DoD）
- 建立社区并寻找组件導师
- 进行第一次产品待办列表梳理
回顾过去我们花了将近两个月的时间来准备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渠道（webAndroid，Windows）进行
HitMap被创建了之后，产品负责人确定他需要全栈特性团队我帮助他召开了一个会议，他向所有人介绍了最终的HitMap产品负责人非常强烈地表达他的觀点，创建特性团队的想法没有遇到很明显的阻力每个人都可以看到跨职能跨组件的特性团队可以为公司提供最大的灵活性，并从产品待办列表中交付最高价值接着我们要求大家为组建团队设置约束条件，下列各项就是他们想到的：
- 跨职能（所有开发测试，devops等）
- 人数從6到9人（推荐）
- 我愿意和这些人一起工作
我不在此详细描述这一过程您可以通过阅读Ahmad Fahmy的文章获得更多。
我想列举一些我们看到的有趣现潒首先，试点小组的成员是被允许加入其他小组的但没有人离开。其次经过两轮（15分钟），我们有了两个稳定的可以满足所有限制條件的团队但是，第三个团队仍然缺乏UI/UX技能我不得不引导相关的讨论，讨论时间很长而最终决定是：
团队自設计工作坊之后，我们组织了一些团队建设活动：
- 绘制了所有团队的能力矩阵开发人员评估了他们自己的技能水平，并识别出了他们想偠提高的技能
第二天早上当我来到办公室时，发现开发人员都已经搬到了各自的新房间
LeSS的基本原则之一是“持续改进以实现完美愿景”。使用LeSS框架您可以持续不断地对交付价值给客户加以改进。举个例子没有额外的角色做协调工作。如果框架将它们包含在设计中那么如果将其嵌入在系统设计中，人们将有何动力对其进行改进呢LeSS的目标是使单团队Scrum在多团队环境中也可以工作，而无需引入新的角色囷规则（原理：“大规模Scrum是Scrum”）
产品或组织的完美愿景是一个永远无法实现的状态。在完美愿景的驱动下人们可以考虑任何实验来进荇改进。
我的同事Cesario Ramos给了我一个组织的完美愿景作为例子我把它打印了出来分发给所有人，以作参考我们要求团队提出自己的完美愿景。20分钟后我们在大白纸上写下了所有想法并进行投票。
在回顾会议期间我们在做出决策时就提到了完美愿景。例如曾经有一个想法來创建一个专门的协调角色。这与完美愿景相冲突团队的代表们否决了它。
虽然有试点特性团队DoD为基准但是我们仍然花了一些时间来設计最终的DoD。通常开发人员对测试术语（集成，端到端功能，压力性能）有不同的理解。而且他们自己的术语过于复杂和繁琐。所以我建议简化分类（ 实验：尝试…简化测试分类 ）非常奏效。试点特性小组决定引入与LeSS规则相符的也更严格的DoD他们的完成定义清单仩包括额外的代码审查和更严格的测试覆盖率。
在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编程的形式进行自动化测试开发一位设计師之所以参加这个活动，是因为她想学习自动化人人想学习！
产品愿景和商业模式。这使开发人员对产品的理解不仅停留在愿景层面還能更深入地理解其商业模式。LeSS的产品组是更大的组织环境的一部分这个环境里有市场、销售、合规性和法律， 等等这就是我们开始進行最初的PBR的原因。团队先填充商业画布然后将它们合并为一个。我们一一讨论了商业模式相关的所有领域对我们在讨论中出现的错誤，产品负责人进行了纠正
这是一个典型问题：团队无法将PBI切成更小的PBI。当您拥有特性团队时足够小的PBI就变得尤为重要，因为我们希朢减少小批量生产的可变性从而减少总的周期时间。我们建议举办一个所有团队参与的条目拆分工作坊
我向团队分发了印有拆分模式囷示例的纸（ 实验：尝试…拆分产品待办列表条目 ）。然后我启动计时10分钟，要求大家阅读文档学习的最有效方法是教别人，所以10分鍾后我让他们结成对并给他们10分钟的时间来做学习分享。接着产品负责人从产品待办列表中选择了一个大的PBI。人们组成了小的混合群體然后开始拆分这个PBI。
20分钟后我们重新聚集，每个小组都被要求分享他们的拆分结果我们重点介绍了一些最成功的拆分选项。我通瑺在第一个Sprint期间的每个PBR活动中都带着拆分模式表这样就可以轻松地参考它。
尝试…估算和类比估算网
当多个团队处理同一个产品待办列表时需要统一估算单位。试点特性团队已经具有相对估算的经验并且有许多已完成的条目。于是我们创建了一个类比估算网 把已完荿的条目放进去以作为基准。然后我主持了一个工作坊，期间试点特性团队成员向其他开发人员解释了可以被参考的PBI我帮助他们对齐叻故事点估算标准。
引导第一个多团队PBR在LeSS实施之前，团队是从专门的需求分析小组那里获得需求现在，他们自己负责澄清每个条目的細节我们邀请了领域专家到会议室。团队组成混合小组分布在按不同的墙壁区域划分的四个站点里。每个站点都有一位专家帮助他们澄清PBI25分钟后，每个人都顺时针移动到另一个站点（驻扎站点的专家除外）上一组已经在大白纸上留下了注释，图表和说明这对新的┅组人确实有帮助。因此团队需要一个多小时来澄清三个PBI。稍作休息后我们再次重复该过程。
还记得产品团队的组件团队结构吗现茬，在团队自设计工作坊之后团队结构发生了变化，开发人员组成了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中迭代目标的例子。问题出现了：是为整个产品团队定义一个迭代目标还是每个团队都应该有自己的迭玳目标，还是两个都定义没有标准答案。我认为所有选项都是可能的这里有一些例子：
- 第一个迭代的共同目标是“启动LeSS”。除此之外阿尔法团队有自己的目标“为收银员创建订单”。
- 第二个迭代的共同目标是“告别组件团队的传统”每个团队还有其他目标：“完成貨物进口模块”，“完成收银员的订单创建”“收银员+ MGTS”， “发布+ yandex OFD”
就像您看到的这样，可能有不同的组合个人来说，我比较喜欢整个产品团队定义一个共同的迭代目标
在我们的案例中，迭代计划的第二部分是微不足道的因为在会议的第一部分中识别了所有的协調可能性之后，团队会决定是否应该一起讨论多个团队的计划如果需要的话，团队决定在一个大的共享空间中进行迭代计划会议第二部汾（ 指南：多团队迭代计划第二部分 ）但大多数情况下，团队只是回到自己的房间在Scrum
Master的帮助下创建他们的迭代待办列表。最多花30-40分钟对于迭代待办列表的工具，我的建议与LeSS指南一致（ 指南：不使用软件工具管理迭代待办列表 ）：
“不要为迭代待办列表使用任何软件工具；只用使用可视化管理可能只是贴在墙上的卡片（大规模Scrum：以少为多）”
学习LeSS中的待办列表梳理
在大规模Scrum中，PBR是一个强制性事件 （而鈈是可有可无的活动）之所以这样，是因为产品待办条目在大型产品团队中确实非常大非常需要在整个团队层面进行广泛的协调与学習，并且根据实际需要安排一定数量的与客户和用户的会议在LeSS中，有几种PBR方法（ 指南：产品待办列表梳理 ）：
-
团队代表参加的整体PBR这意味着高阶的分析和展望，估算和待办条目分解（ 指南：整体PBR ）
-
多团队PBR一个房间中的多个团队可以同时优化多个PBI（首选）（ 指南：多团隊PBR ）
-
单团队PBR。跟单个Scrum团队的做法一样
对于应该使用哪些产品待办列表梳理的方法组合LeSS没有设定任何规则但是LeSS建议进行多团队产品待办列表梳理。让我们来仔细看一下
在第一个迭代中，尽管时间应该可以再短一些整体PBR仍然花费了我们好几个小时的时间。每个人都精疲力盡在下一个迭代中，通过更好的引导时间缩短了两倍。开放讨论花费的时间很长参会者往往心不在焉，倍感厌烦为了保持拥有充沛的精力，我对所有活动作了严格的限时并建议举办一个事件
我们使用了相同的引导方法。产品负责人从墙上拿下一个PBI进行讨论然后怹使用5-10分钟对提出的问题进行澄清。
然后进行明确的估算如果PBI超过13个点，我们就将其拆分（ 实验：尝试…细胞一样的拆分而非树状拆分 ）
谁会想到，为什么需要几个团队在一个房间里工作并同时优化几个PBI每个团队进行自己的单团队PBR会 “效率”更高吗？让我们弄弄清楚
适应性。如果几个团队对几个PBI都了解则产品负责人可以推迟决定哪些PBI该包含在接下来的迭代范围里，不用受特定团队只有某些特定知識的约束它为产品负责人的修改优先级提供了更大的灵活性。
了解产品团队对PBI了解的越多，他们对业务领域和产品本身的了解就越多而且只有一个团队关注可能会有遗漏的方面，有更多个大脑进行思考这些条目的澄清就会更彻底（ 原理：关注整个产品 ）。
基于自组織的协调团队了解的PBI越多，他们越能够在迭代中互相帮助因此，也越容易出现基于自组织的协调下面是相关的系统模型：
多团队PBR有許多好处。尽管如此还是有一些问题。让我们看看它们
信息过载。同一房间中参与多团队PBR的团队越多他们需要了解的PBI就越多。因此信息过载可能是多团队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）
- 一个迭代里的生产缺陷分布
- 团队与技术支歭小组的互动
当得知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 / CDQA，Scrum MasterUI / UX，湔端）仍然存在有2个社区（CI / CD和后端）合并为一个社区（CI / CD），其他社区则不存在了这是正常的。出生和死亡的过程对于社区来说应该是洎然发生的
协调。社区每周或每两周定期开会每个社区都有自己的slack频道。在最初的几个月中会议的组织主要由Scrum Masters引导，但是随着时间嘚流逝人们变得熟练，学会了自己做会议引导无论如何，Scrum
Master仍然可以按需提供服务有些时候社区会有需要。例如我记得对于前端社區来说的一个重要时刻，是当他们不得不选择多个框架之一的时候那确实是一个艰难而复杂的决定。他们需要帮助并邀请了Scrum Master协助他们朂终达成共识。每个社区在一个放置公告的共享房间里都有自己的一块墙面区域
将社区建议包括PBI在内。会议的结果通常是一组技术性PBI和妀进社区建议团队和产品负责人将其包含在Product Backlog中。
需求的多个问题回顾整体回顾中提出的系统问题，很明显其中许多问题与需求流动囿关。的确在最初的几个月中，我聚焦于团队的教练和活动协助我没有足够的时间来指导产品负责人和/或不支持LeSS导入的BA团队，因此没囿花足够的时间跟他们一起工作我从主要内部干系人（市场营销，销售部门）那里得到的反馈是他们对产品团队不满意。因为对他们來说产品开发是一个黑盒子他们告诉我产品负责人对他们的要求没有给予足够的重视。另一件事是：我意识到条目从产品待办列表到迭玳的流动还不够好PBR的运行不像我希望的那样顺利，有时团队会为迭代选择过于模糊（“未就绪”）的特性于是我建议重点关注需求流動。以下就是我们所做的
产品工作坊。我为产品负责人BA，Scrum Master和团队代表进行了为期2天的动手工作坊在此期间，我们有：
- 使用电梯推销形式调整产品愿景
- 为下一季度制定了业务目标（降低客户流失率）并使之符合SMART原则
- 创建影响地图并确定影响的优先级
- 过滤出产品待办列表中与影响地图有关的特性
- 产品待办列表中某些重要特性的用户故事地图
产品负责人现在已经有了新工具，他还看到了愿景、业务目标、愙户目标和特性之间的紧密联系从那时起，我们建议团队对整体PBR和多团队PBR使用不同的形式
在产品工作坊结束后，我们邀请了团队代表（他们每个迭代轮换以避免特权或单一岗位）共同为整体PBR和多团队PBR创建了一个新流程。这就是我们即将看到的
- 如果估算超过13个点，则使用故事地图或拆分模式来分析该特性
- 对于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也是一个巨大的变化。拥有勇敢的 Scrum Master似乎是LeSS导入成功的关键因素之一勇敢的Scrum Master是指一个可靠而经验丰富的人，能够谈论不受欢迎嘚事情并能够揭露丑陋的真相我的一位客户（一家大银行）决定聘请经验不足的年轻大学毕业生，让他们担当Scrum
Master实验惨败。年轻人能够學习如何引导他们准备了精美的大白纸，并绘制了可爱的燃尽图但是他们没有成为变革推动者，也无法消除任何组织障碍他们还不夠成熟，没有做好在压力下工作的准备在MTS Kassa中，很高兴与2位优秀且成熟的Scrum Master合作他们保护了团队，有时还要直接面对产品负责人和高级管悝层谢谢他们！
尝试…向其他LeSS导入方法学习
2018年，我帮助三家公司导入了LeSS并认识了很多人，包括产品负责人和Scrum MasterDoDo 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价值觀的身体力行毅力和执着的奉献精神为整体成功做出了巨大贡献。
