德国大保险公司（化名）的巨型LeSS转型尝试

介绍

本案例研究描述了一个部门从最初采用Scrum到LeSS Huge的转变。迈向LeSS Huge的那些步骤包括但不限于：

• 部门的重新设计
• 建立需求领域
• 引入LeSS事件
• 引入描述需求的新方法
• 重组产品待办事项列表

本案例研究首先简要介绍了背景，试用阶段（2016年夏季-2016年12月，当时我不在场）以及最初采用Scrum的过程（2016年12月至2017年3月），在此期间我曾经指导了该部门。

LeSS的大规模采用始于2017年4月，并进行了更深入的描述。我一直在全职工作，直到2017年6月。此外，我还吸收了开发主管和其他成员在2018年夏季之前的反馈。

目的

本案例研究的目的是对部门中试图实施 LeSS Huge 有一个批判的视角。尽管已经取得了很多积极的成果，但案例研究还是有目的地强调了问题，并讨论了原因和结果，因为与“平滑”转型相比，这通常会使人们对组织变革的动力有更多的了解。因此，请勿将此描述视为“最佳实践”;）

背景

大多数人都有某种形式的保险。为了更好地理解这个案例的背景，我将以奥托（Otto虚拟人名）为例说明一些相关方面。奥托拥有几项保险，例如人寿保险、家庭保险和旅行保险（保险供应商Sampo提供的）。奥托想购买一辆新车，然后去他选择的汽车经销商处。他买到了梦寐以求的汽车。另外，作为销售套餐的一部分，经销商提供了各种汽车保险。这就是本案例研究中称为B2B2C（车辆保险）产品的内容。奥托购买了责任险，并高兴地回家了。他希望一目了然地查看所有保险，为此，他登录了提供此视图的保险公司网站。提供查看的数据来自于“公共数据库 common database”（本案例中我起的名字）。

*Terra*部门隶属于一家超大型的德国保险公司Alpha¹。*Terra*负责产品的开发及其运营。他们在其职责范围内创建了两种类型的产品，如下所示分别为“B2B2C”和“B2B”的车辆保险。

B2B2C产品是德国的车辆保险，而B2B产品是代理商的国际保险服务。B2B2C产品是基于现有车辆保险产品的变种，此外，B2B2C产品使用了一个公共数据库（包含企业和消费者的数据）。

现有的（此处称为“ B2C”）车辆保险产品开发以及公共数据库不在本案例研究范围之内。

*Terra*在德国和印度的两个办公地点约有250人。在这250人中大约有150人做产品开发，其他人则是支持功能和“测试工厂”。

另一个部门包括产品管理、业务分析和协调人员（我称其为*PM＆BA＆CO*）。除了市场分析、定价、定义营销活动之外，业务分析部门还负责一些高层次的需求工作，然后将其移交给“协调”部门。

据我了解，该协调部门负责按优先级排序需求，并以发布的形式构建“可销售的特性集”。这些高层次的需求移交给*Terra*。此外，该部门还负责“接受”*Terra*提供的功能、特性和修改。这些活动集中于B2B2C产品。

*PM＆BA＆CO*部门是在LeSS实施的直接范围之外。但是，如稍后的案例研究中所述，这些部门之间的工作方式也发生了一些变化。

*该公司*有很多层级，*PM&BA&CO*和*Terra*之间的共同管理层已经在几个层级之上了（译者注：即*PM&BA&CO*和*Terra*都汇报给同一个更高的管理层）。坦率地说，高层管理人员并不关心*Terra*的组织方式，因此*Terra*内部的管理人员很少得到高层管理人员的支持。

*Terra*自己对B2B产品的客户需求进行分析并确定优先级。该部门的目的是开发这两种产品。

试行阶段

该部门对两个独立的子产品进行了单团队Scrum和工程实践的试验。这些团队由一个PO，一个Scrum Master和一个开发团队组成，每个团队对Scrum进行了大约6个月的试用，并取得了积极的成果。积极的反馈以及其他因素（例如，需要更高的灵活性、对变化的响应能力、业务价值的增加、降低部署的风险、提高产品质量）引领整个部门的敏捷之旅开始了。

该部门建立了一个“敏捷指导联盟”（Agile Guiding Coalition AGC）²，其目的是通过例如定义方向，决定使用哪些框架，帮助团队及消除障碍来指导和支持该部门。AGC由*Terra*的高级管理团队，敏捷教练，架构师，Scrum Master和产品负责人组成。

最初的“Scrum”实施

组织

最初该部门分为以下职能部门：

• 设计
• 编码
• 测试

每个团队都有一个团队负责人（TL³）和一个业务负责人（BL）。最上面是项目经理（PM）。此外，还有一些支持功能，例如架构，版本管理，缺陷管理，运营和其他一些团队。

在最初采用Scrum的开始，我们移除了职能部门并建立了新的结构。

该结构由管理层设计的、十四个分布的Scrum团队（跨职能，但仅限于一个组件）。每个团队都有专门的产品负责人（PO）并且部门有一个整体的首席产品负责人（CPO）⁴。未改变其他部门（产品，架构等）的结构。

该结构的设计无需任何LeSS专家指导。这项变革是自上而下的一次性⁵引入的，没有人心甘情愿，也没有得到Terra⁶部门的高级管理层自上而下的支持。

我开始辅导时，新组建的组件团队是第一次见面。在启动会议上，项目经理解释了变革的原因并传达了方向。

在这个阶段AGC决定：

• 新组建的团队在新架构中工作的日期
• 2周的Sprint节奏
• 具有基本的Scrum仪式和（每个Sprint）（产品待办列表）梳理工作坊（PBR）的框架
• 产品级的Sprint评审，其中志愿团队向其他团队、高级管理层、产品管理人员介绍功能
• 单独的系统测试功能
• Scrum of Scrums

产品负责人创建：

• 隐含的团队列表的集合，合并到一个“产品待办列表”（PB）中

团队创建：

• 所有团队共同的完成的定义（DoD）
• 多个社区⁷ 如Java社区

Scrum Masters创建：

• Scrum Master 社区⁸

接下来发生了什么…

在最初采用假 Scrum 时，已经对即将发布的版本（6.5）的需求进行了分析和“设计”。遵循旧的工作方式，在Jira中记录了开发和测试的“剩余”工作。这些工作条目没有有意义的估算，这使得发布计划和进度跟踪实际上变得不可能。即明显缺乏透明度。即使工作条目与用户故事⁹背后的原始想法相距甚远，这些工作条目还是被称为“用户故事”（开发人员和客户之间的直接对话）。

为了弥补损失，发布管理功能创建了进行跟踪和预测的“热图”，所谓的“ PO”（实际上只是业务分析师）可以帮助了解情况。早期更新是每周发布，随着发布日期的临近（“热量增加”），发布经理每天都会进行更新。

由于团队只是组件团队，而不是Scrum中可以端到端完成所有事情的真正的开发团队，因此团队之间的依赖性非常惊人。¹⁰

由于未解决的开发缺陷在组件团队之间频繁发生，因此工作经常完全停止。很难找到可以修复该缺陷的团队，因此修复需要很长时间。

现有的构建系统确实提供了延迟的反馈，并且集成是繁琐的。回归测试是手动完成的，仅在发布结束之前才可以进行系统测试。

为了快速解决缺陷处理的问题，AGC召开了一次集中的协调会议，即“ Scrum of Scrums（SoS）”，这很有帮助。

注意：SoS会议并没有解决缺陷推脱的根本原因问题，即组件团队结构，它只是对此做出了反应。

如实验“尝试……Scrum of Scrums”中所述，该会议在短期内有助于处理缺陷。SoS使用一个物理板从所有团队中选择条目，并查看发生了什么。这是针对团队的团队的一次会议¹¹。每个团队确实派出了一个不是Scrum Master ¹²的代表。每个Sprint或每两个Sprint ¹³团队代表轮换一次。 一方面，SoS并未解决该问题的根本原因，其中包括

• 相互依赖的组件团队的组织结构。
• 缺陷管理团队的存在。¹⁴
• 缺乏合适的信息系统。

如果组织希望创建一个更好的环境，从而消除那些阻碍因素，建议避免SoS ¹⁵这样的集中会议。

由于缺乏稳定的产品维护，特性开发是通过“冻结”期¹⁶的代码冻结而结束，该时间段与新版本发布之前的用户验收测试时间段并行。

每个团队根据团队自己的待办列表工作¹⁷。所有这些列表都作为所谓的“产品待办事项列表”存储在一个工具工件中，但就工作和团队而言，该部门实际上并没有一个共同的待办事项列表。那是一种幻想。相反，他们将许多与不同团队相关的“隐性待办事项”存储在一个工具中。

由于是组件团队，所以存在大量的交接、隐藏的待办事项、大量的协调开销以及其他原因，直到开发的中间时间点，人们才意识到并非所有内容都可以及时交付。

因此，为了应对这种延迟，项目经理最终对以客户为中心的高层次需求列表进行了排序。此操作创建了一个公共PB（在一个简单的电子表格中），并将重点放在了部门上。现在，其他所谓的“PO”分析师和他们的团队也牺牲了“他们自己”（不是很关键）的工作，并帮助其他团队满足关键的需求。

在此版本的结束时，仅交付了非常基本和关键的功能。

总体而言，当使用缺陷数量作为代理度量标准时，该版本的技术债越来越多。

此外，即使有些组件团队尚未完成关键内容的实施，他们也已经开始考虑下一个版本。这偶尔引起了激烈的讨论。

此时很明显，我们将重新设计*Terra*部门的组织结构，从最初的产品待办事项列表梳理（PBR）开始，但是这些团队的Scrum Master进一步推动了组件的方案。

经验

在与项目经理进行反思AGC的当前状况时，这种组织结构是不可持续的，这很明显。实际上，许多人意识并了解到协调工作是巨大的，由于隐含式的列表的使用，工作分散了，因此大家希望拥有更多独立工作团队的结构。

此外显而易见的是，需求是以不同的方式描述的，PB需要不同的结构，及不同的工作模式来维护PB。

巨型LeSS实施

问题与背景

我相信，随着最初采用的虚假Scrum和“幼稚的规模化” Scrum的方式，项目经理对于缺乏透明度和需要跨团队协调感到非常沮丧。我认为，采用LeSS Huge的诱因是“对未知的恐惧小于对已知的恐惧”。

结果，并非如此决定实施巨型LeSS，因此忽略了关键的LeSS实施原则，且在LeSS指南入门中的第一步执行时花了太少的精力。

因此，我提出了在某些约束条件下我认为最有意义的措施。从这个意义上讲，部门迈出了更具适应性的第一步。

LeSS实施原则

LeSS实施有三个原则¹⁸，这对于组织的LeSS实施非常关键：

• 深而窄 高于 宽而浅
• 自上而下和自下而上
• 采用志愿服务

深而窄 高于 宽而浅

基本思想是将变革限制在一个需求领域内（Requirement Area RA¹⁹）或一次约50人，学习和试验一段时间，然后在进行下一个需求领域。

这还没完成。在最初使用（仿造）Scrum时，该部门的所有开发都发生了巨大变化。这一团糟，我认为该部门处于混乱状态，需要迅速采取行动。此外，由于有第二种产品（B2B），因此受到“巨型LeSS实施”影响的人数并不多。从这个角度来看这仍然是一个（产品）边界的案例，不应将其视为典型的LeSS的实施。

自上而下和自下而上

同样由于采用纯粹的自下而上，这并未遵循LeSS的原则。这是整个*Terra*部门，但是*PM＆BA＆CO*部门的存在证明了，此变革没有自上而下的支持。实际上，高层管理人员已经做出了几项决定，在此之后的几个月中，我已经离开了组织，这表明他们缺乏对这种变革的支持（请参阅结论部分）。

采用志愿服务

在“Scrum”实施之初，很少使用志愿服务。到开始采用LeSS Huge时，部门越来越多地采用志愿服务的概念，尤其是在团队自设计工作坊中。该工作坊为高级管理层建立了继续和促进志愿服务所需的信心。

LeSS指南：入门

本指南中的第0步是*对所有人进行教育*，这几乎被忽略了。激励项目经理按要求投入足够的培训是非常困难的²⁰。

……然后我们就开始……

通过最初（假）Scrum的学习，AGC决定做出一些根本性的改变。作为教练，我从AGC那里获得了很高的支持，创建了一个产品待办列表（PB），并且需要进行的澄清和结构的改变被视为实现这一目标的“必要且痛苦的操作”。因此，AGC对部门所需的结构变更的阻力很小。

（LeSS的）实施开始于一个初始的产品待办列表梳理工作坊（PBR）²¹。

该决定引发了一些关键问题需要事先进行澄清，例如：

• 产品是什么？
• 组织结构是什么？
• 高层次的客户需求的最初优先级是什么？

注意：高层次客户需求的初始列表由*PM＆BA＆CO*排序的，我们避免创建特性优先级类别。这些需求很大，有些需求可能会在多个版本中实现。除了*PM＆BA＆CO*，还有架构师²²和团队，每位都提出了他们的需求清单，来作为此次工作坊的输入。

自我设计团队工作坊的准备，产品及其领域的定义以及最初的产品待办事项列表梳理工作坊大约花了三周时间。一个内部热心的专职教练为高级管理层，部门成员和其他必要的人员之间的大多数讨论提供了引导。

该部门的各个成员都非常怀疑能否在几天内完成此更改。因此，我想强调一下，实际事件彼此之间迅速发生，而在这之间没有间歇：

• 周一下午：自我设计团队工作坊
• 周二和周三上午：新架构中的初始产品待办事项梳理工作坊
• 周三下午：与新的APO进行PBR结果分享会议
• 周四：按照常规的Sprint节奏进行新架构中的Sprint计划1和Sprint计划2。

产品定义与需求领域方面的问题

产品定义工作坊发现该部门实际有两个（以客户为中心）产品：

• B2B2C产品是仅为德国市场的车辆提供保险
• B2B产品是面向代理商的国际车辆保险服务

B2B2C产品占据了部门的主要工作量和重点，而B2B产品处于起步阶段，在国际市场上具有增长的潜力。

从B2B产品开始，成立了一个特性团队，拥有一个真正负责人和一个Scrum Master。新成立的开发团队位于印度同地协作，而PO则位于德国。因此，B2B产品通常被排除在以下讨论之外。

注意：所有产品均基于相同的代码库，并且从概念上讲，它们基于相同的车辆保险产品²³。换句话说，B2B2C产品和B2B产品都可以视为该基础产品的变体，该基础产品是在不同部门开发的。但是，由于组织边界限制了产品定义，因此定义了这两个产品。

B2B2C产品由10个团队组成²⁴，“保险公司业务模型”²⁵大致分为三个需求领域RA：

• 合同承保（5个团队）
• 合同修改（3个团队）
• 索赔（2个团队）

对所选设置的反思

为了优化适应性并在全球范围内更可能发挥最大价值，LeSS Huge框架规则之一是每个需求领域的团队数量都在 “4-8” 之间，因此这就减少了与团队数量相关的产品待办事项列表的份数。*Terra*部门的结构违反了此规则，因为有两个需求领域少于4个团队（一个需求领域有3个团队，另外一个需求领域有2个团队）。

合同修改RA和索赔RA中的那些团队完全不了解承保RA中的条目。如果产品负责人想要调整，以便更多的团队专注于*承保、修改和索赔*RA团队无法做到的事情（如果不先了解它们），他们将无法适应并且将被困在原始RA中的、从全局角度来看可能较低了需求条目的价值。项目经理已理解该问题，但出于以下所述的原因，决定从此结构开始。

原因之一是该选择支持了分为三个区域的现有*PM＆BA＆CO*部门结构，并且此更改确保了在外部接口方面的更平稳过渡。这使APO可以在其区域内自主工作。换句话说，由很大一部分于产品组仍以传统方式进行结构化（因为这只是部分的LeSS实施），因此考虑到政治力量，选择较小的RA是折衷方案，以帮助与传统组织保持一致。

另一方面，项目经理认为，将来还有理由将这两个领域合并起来（从APO的角度来看），开始他相信，如果APO可以在其新角色上更加坚定，一个人就可以处理这两个领域，其次，一个APO表示了继续前进的长期愿望，因此无需再次填补这一职位，而是将未来的两个领域结合起来。

另一个问题：放开每个团队一个PO的原则是APO候选人的又一大步。因此，寻找APO的讨论耗时好几周²⁶。最终，产品负责人找到了三个合适的APO，他们感觉比较舒服（对于认知负荷、愿意尝试和学习新结构的方面）对于拥有一个领域并在每个领域和多个团队工作。

自设计团队工作坊的问题

这是*Alpha*公司历史上的首次允许团队自组织，*Terra*部门挑战现状并获得了成功。这项活动给部门中的许多人带来了动力，几个月后效果仍然很明显。

*Terra*的所有开发人员包括印度的开发人员都参加了此活动。印度的开发者同时在本地也进行了自组织。

根据先前解释的前提条件或约束条件，项目经理支持开发团队以自组织的方式进行重新组织。

工作坊的准备

为了准备自设计团队工作坊，一小组代表和教练（不仅是经理）创建了提供客户价值所需的所有技能的清单（请参阅下一段），并准备了一组边界条件，这些条件将帮助实现工作坊的目标。

边界

图示的团队布局模板用于提供边界，以支持组建以客户为中心的特性团队

除了团队布局模板之外，我们还提供了以下边界：

• 团队必须在同一地点
• 团队必须是跨职能的（即业务，技术，测试）
• 团队必须是跨组件的（技能，例如门户，富客户端，文档或Orga工作流）
• 团队人数为5人到9人
• 团队中有敏捷爱好者和敏捷怀疑论者

注意：在理想情况下，团队成员将能够独自完成准备工作，他们将设定自己的边界，自己的计划，并且不需要预定义的团队布局模板。

但是，考虑到当时所有的限制因素和团队的不成熟，教练们建议提供这样的界限。这些边界和工作坊的准备必须获得AGC的批准。

工作坊的执行

工作坊的日程安排如下：

每个人都有一个预先打印的名牌（名字，颜色表示的核心技能 - 业务、技术、测试）和不同颜色代表能力的级别。主持人确保缺席的同事由队友代表。然后要求人员将其名牌固定在团队布局模板上，以说明新团队的设置。

回顾回合中，每个人都可以审查和挑战其他团队的设置。

工作坊结束时几乎实现了所有目标。尤其值得注意的是，所有团队实际上都是跨职能、跨组件的且位于同一地点²⁷。与以前的组织设计相比有很大的不同！

德国团队的自我设计的同时，印度的开发人员也成立了特性团队。组建了一个团队来创建（很小的）B2B产品，另一个团队加入了新成立的“承保”RA。

这里观察到几个主要问题。

• 理念是将运营工作分成一个独立的团队（在RA之外），该团队不用遵循Scrum周期（例如，每月关闭财务系统、回答客户和用户问题的这些任务）。但是，在工作坊召开时没有发现团队负责人，而项目经理正担任这一职务。由于团队负责人是故意不出席自我设计工作坊的，因此该团队的人员配备未达到可以运作的水平。结果，人们决定将运营的任务保留在开发团队中（就像以前一样）²⁸。
• 对于任何愿意举办这样工作坊的人来说，重要的是要了解还有另一个挑战几乎导致工作坊失败。很少有人能按照指南来创建团队。人们被困在自己的观点和立场上，这导致了死循环。即使经过几轮让人们试图自己解决冲突的努力后，也没有解决方案。在Scrum中转型自组织团队的敏捷性原则时，这是很常见的事情，人们没有如何独自解决矛盾情况的教育或经验，教练和Scrum Master也都没有想到。在之前的传统管理模式中，由不同的管理者来做这样的决定，使得普通的人感觉没有权力或能力来做自己的决定，并在冲突中工作。只有通过APO和教练的密切合作，才能最终找到解决方案。

产品待办列表的问题

本节包含两个主要部分：产品待办列表及其工具。

产品待办列表

在LeSS Huge中，只有一个产品待办事项列表，其中每个条目都恰好属于一个需求领域（RA）。因此，每个需求领域只有一个领域待办事项列表。²⁹

由于存在三个RA，因此PB包括这三个需求领域Backlog，每个Backlog由一个需求领域产品负责人 Area Product Owner（APO）负责。

对于*Terra*部门来说，创建一个以客户为中心的PB是一个巨大的挑战，而该PB注重结果而不是产出。

即将发布的版本和下一个新版本的主要重点是为新车制造商（我们称为保时捷）提供保险解决方案。这项巨大的需求被立即分解为三个RA，而*承保*则需要先进行，而*修改*和*索赔*均在此基础上进行。³⁰

此外，与“保时捷”讨论的是，整个解决方案将有两个主要步骤。第一步将集中在两个系统（保时捷和保险公司）的复杂技术集成上，只完成最小集合的特性。这些不会进行商业的发布。第二步将包括商业发布所需的所有特性。很快就可以看出，将迈出第三步，因为商业发布并不需要某些特性和功能，然而稍后必须包含这些特性。³¹

这就形成了以下的框架，代表了PB中的高层次的需求：

PBI	版本	承保	修改	索赔
保时捷：集成	6.5	保时捷：集成	保时捷：集成	保时捷：集成
保时捷：发布	6.6	保时捷：发布	保时捷：发布	保时捷：发布
保时捷：其他	7.x	保时捷：其他	保时捷：其他	N/A

{: .grid_table_with_header}

每个较高层级的条目（如6.5）都非常大，为了达到每个团队每个Sprint可以完成四个条目的要求，有必要引入一个中间级别。

重要的是要注意，例如“保时捷：集成”主要是一个粗粒度巨大的类别或是“一桶”条目，而不是一组固定的要求，即这不是需要全部完成的 “大批量”。相反，如果各方在分拆过程中意识到现在不需要某些功能，会在后面将其转移到了以后的版本（桶）中，例如保时捷：发布。³²

因此，PBI被分为三个级别（有关内容的详细说明，请参见*需求处理*部分）。

• 第1级：大的、粗粒度的需求或需求桶（想法：通常可以在版本内完成，如果开始需要多个版本，则有人创建需求桶）
• 第2级：中等要求（想法：可以在版本内完成）
• 第3级：小的（细粒度）要求（想法：可以在Sprint中完成）

产品待办列表工具

LeSS指南中*对于大型产品待办事项的工具*是“*仅使用电子表格spreadsheet和Wiki即可*。”因此，没有“跟踪工具”（例如Jira）或所谓的“敏捷管理工具”（例如Rally）。为什么？

• 这些工具包含并推广*报告*功能，从而加强了传统的管理报告和控制的行为。
• 这些工具支持并加强了传统的大批量到小批量工作分解结构和流程，其中一个独立的业务小组来决定（大尺寸和大批量）的主要条目，然后将其推给开发团队，以较小的规模进行工作。分批这只是传统管理而非精益管理，通常使用新的术语，例如“史诗”和“故事”。
• 当没有任何有意义的改变时，工具只是传达了改进或敏捷转型的表面。“敏捷行话”工具与*成为*敏捷没有关系。
• 他们经常给团队强加不灵活的术语和工作流，从而剥夺了流程所有权并限制了改进。
• 这些工具可以使工作复杂化而不是简化。
• 他们通常需要进行大量的自定义、集成和持续更新的任务，从而导致创建另一个开销很大的浪费角色，例如“Jira秘书”或一个假的“Scrum Master”或“产品负责人”。

*Terra*部门未遵循该指南，而是决定

• 第1级条目使用电子表格（spreadsheet）
• 第2级第3级条目使用Jira

该电子表格还用于与*PM＆BA＆CO*部门的沟通（还用于重新计划和报告），因为他们仍在使用传统的模型。随着时间的流逝，*Terra*与*PM＆BA＆CO*部门之间的合作得到了改善，从而使这种想法成为现实，对话也发生了转变，以统一的看法并理解“大局”。

最大的问题之一是*PM＆BA＆CO*的一位高级经理并不了解（需求）桶的概念（以及工作方式）。这也导致了频繁的争论和无用的讨论，即使会议室中的所有各方都同意并知道这些条目的情况。

另一个自我产生的问题是电子表格和Jira保持同步，并使Jira中的数据可维护和保持一致性。这需要大量的手工工作，并且从根本上证明了整个发布管理支持功能的存在性（请参阅发布管理一章）。

使用Jira的原因是模糊的，我只能猜测。首先，一个原因是，Jira已经从传统的管理方法中就位了，它已用于缺陷管理以及其他各种事情。其次，Jira允许传统管理思想³³驱动的“控制”类型，这意味着项目经理可能没有足够信任人们，并希望拥有控制权的选择。

由于Jira是不可协商的（对于检视与适应而言更是如此），因此教练的目标是最大程度地减少该工具造成的损害。结果，产品负责人团队、教练和支持人员参与了一个新的Jira项目的引入，在昂贵的Jira工具专家的广泛帮助下，包含新结构的该项目的工作流程大大简化了。

Jira列表（不能称为真正的LeSS产品待办事项列表）仅包含中小规模的PBI、估算值、上层条目信息、设计信息的链接和注释等。

Jira为每个RA创建的发布烧起图仅提供了一般性的报告。

此外，发布管理功能从工具收集数据而不是从APO收集数据存在风险。最初，这会引起了一些额外的摩擦，尤其是当发布管理充当APO状态报告的“控制者”时。但是，经过几次Sprint，风险得以消除，并且发布管理功能就放弃了这种“控制”的活动。

尽管项目经理坚持使用Jira，但Jira显然是虚假的PB工具，也是功能不足的“PB”工具。如果部门只是从电子表格开始，就可以避免大量的工作。

除此之外，Jira在产品待办事项列表细化（PBR）和Sprint计划期间毫无用处。至少一个APO打印出相关的条目或将其写在固定在板上的卡片（请参阅Sprint规划一章）。

初始产品待办事项列表梳理的问题

初始PB的创建对于部门来说是一个巨大的挑战，因为每个人都需要学习如何以新的方式拆分需求³⁴。令人怀疑的是，初始PBR工作坊能否在很少或没有前期设计的情况下产生任何有意义的东西。

*PM＆BA＆CO*的架构师和代表参加了此次工作坊，以支持团队进行细化、定义验收标准并立即澄清问题。教练和大多数Scrum Master共同协助了这次活动。

在理想的情况下，客户、用户和团队一起澄清PBI。在此初始PBR中，客户、用户不存在，而是由PM＆BA＆CO³⁵的成员代表。这些是站在团队与实际客户、用户之间的“中间人分析师”。

但是与早期版本相比，人们传递规范，且每个人与之交谈的普通会议都是朝着更好的方向迈出的第一步。

但是，这种设置的功能失调是交接传递的浪费（和信息的丢失相关），增加了库存，并加剧了功能失调的角色和部门的存在。

在初始PBR中，团队主要与RA中的其他团队一起对条目进行了细化。1天半后，在墙上用活动挂图和便利贴创建了初始PB。有些条目具有接受标准。有足够的（几乎都是端到端的）PBI可以为每个团队至少填满一个Sprint。进度很棒！

在初始PBR的结尾，团队使用“魔术估算” ³⁶方法以及相对的故事点³⁷来估算条目。

PBR结果分享会议的问题

初始PBR工作坊结束后，墙上可视化了排序的条目（便利贴）列表。在分享会中APO解释了列表，目的是让产品负责人团队、*PM＆BA＆CO*团队，测试经理，测试工具负责人，开发经理、发布经理及首席架构师获得共同理解³⁸。

目标是获得以下方面的透明度：

• 哪些具有较高确定性的条目可以交付
• 哪些条目可能会产生
• 哪些条目明确不在范围内

请注意，在LeSS中通常不存在这样的“分享”事件，因为在初始PBR之后与之共享信息的人员应该已经积极地参与了初始PBR。必须进行单独共享的事实表明，没有进行有效的自上而下的变更去消除传统的团队和角色。

另一方面，LeSSHuge描述了产品负责人团队（POT）在Sprint计划之前进行同步的可能性，我认为这种同步在这里发生了很多，因此这很有用，但也包含了传统团队的无用的活动。

这次共享会议确实在POT内部，部门内部以及*PM＆BA＆CO*之间建立了信任和信心。此外，还播种了以定期进行重新规划和重新排序的种子。进步！

新组织结构的问题

拉曼组织行为定律

1. 组织会含蓄的优化会以避免改变中层经理、一线经理及“专家”的职位和权力结构的现状。
2. 作为（1）的推论，任何变更倡议都将简化为重新定义新术语，以与现状保持基本相同。
3. 作为（1）的推论，任何变革倡议都会被嘲笑为“纯粹的”，“理论的”，“革命的”，“宗教的”和“需要针对当地情况的务实的个性化”，这偏离了解决弱点和经理、专家的地位的现状。
4. 作为（1）的推论，如果在变更之后某些经理和专家仍然被取代，他们将成为变革的“教练或培训者”，并常常加强了（2）和（3）。

在这种情况下，所有这些定律都必须遵守。以下段落更深入的描述了组织结构及各个小组和职能的功能失调。

产品管理、业务分析及协调（PM&BA&CO）

*PM＆BA＆CO*确实是*Alpha*公司的一个单独部门，这一事实使他们很难参与到LeSS实施中。在自上而下和自下而上的支持的变革中，两个部门*PM＆BA＆CO*和*Terra*将合并为一个部门。

因此，这种功能失调设置的存在，造成了尤其是在早期对于如何完成事情理解的不一致性，例如：

• 他们不断提供较大的需求定义。
• 发布内容的预期承诺（请参阅合同游戏）

通过指导，教育和举办共同的工作坊，随着时间的推移合作得到改善。但是由于缺少高层管理人员的支持，从长远来看，其他做法（例如预算，激励机制，目标设定）可能会比这些改进更有价值。

开发主管与产品负责人

LeSS的基本规则是只有一个产品负责人。考虑了几个选项来回答这个问题，谁将承担这位产品负责人的职责。很明显，她不能来自现有的PM＆BA＆CO³⁹部门，因为他们仅涉及B2B2C产品，而完全不涉及B2B产品。

开始巨型LeSS实施时，很明显项目经理既是真正的产品负责人⁴⁰，同时又是“开发负责人”，即领导整个组织（一个人担任两个不同的角色）。

产品负责人团队

产品负责人团队（POT）由PO和三个APO组成。

POT经常开会，以重新规划PB的短期和长期优先级。很难掌握产品负责人的职责，因此产品负责人团队建立15分钟的每日站会时间，以便能够根据需要与PO同步日常问题。

后来，POT意识到需要定期重新确定PB的优先级。这是与*PM＆BA＆CO*的代表一起完成的。参与者花了好几轮的时间才能够集中讨论短期（1-2个Sprint）和中期条目（接下来的2-3个月）。

对话没有继续进行合同游戏，而是逐渐朝着更具协作性的方向发展，并专注于信息交换和寻找方法，以使下一次发布尽可能有价值。

特性团队

LeSS的规则还定义了每个团队都是自组织，跨职能，在同一地点且长期存在的。

在命令和控制环境中工作了多年之后，特性团队开始学习自组织。开发人员迅速重新调整自己，以便特性团队的所有成员坐在一起。“合同承保”RA有5个团队，其中4个与APO在同一地点，而另一个团队在印度。

在自设计团队工作坊之后，所有特性团队都是跨职能和跨组件的，能够完成以客户为中心的特性，即*结果而不是输出*。

从某种意义上说团队是稳定的，因为团队成员没有被抽调到其他小组中。由于大多数团队成员来自合作伙伴，因此每1.5至3年会进行一次成员交换。

许多团队成员（和经理）是合作伙伴（或分包商），有时甚至是竞争对手。这个事实大大限制了团队的自组织能力。

成员经常在这里进行改变的事实是另一个功能失调，这阻止了组织和团队的整体学习。个人确实学习了，然后就带着所有的知识去了另一家公司。

Scrum Master

尤其是Scrum Master都没有大规模Scrum和LeSS的经验。所有人都对如何支持1-2个团队的Scrum转型有很好的想法，但没有足够的知识和理解来支持更大规模的实施。他们在指导PO、管理层和组织方面，或者换句话说，“为人们创造成功的环境”方面，都没有Scrum Master角色的丰富经验。⁴¹

不幸的是，关于Scrum Master的LeSS规则仅得到了部分实现。

最大的差距是缺乏对LeSS的知识，以及他们无法专注于组织、开发实践和整个组织的系统。随着LeSS Huge的实施，所有Scrum Master都致力于担任这一角色，并在一个RA中为1-2个团队提供服务。

在我辅导的时间里，Scrum Master 开始学习LeSS规则、原理、指南和实验。特别是，他们学会了支持LeSS事件，APO和整个组织作为一个复杂的系统。Scrum Master尚未将重点放在开发实践上。

Scrum Masters在所有RA中形成了一个社区，这对他们的技能，思维方式以及他们可以互相支持的地方有很大帮助⁴²。此外，他们还学会了引导大型团体活动⁴³。

一名Scrum Masters具有SAFe背景，他拒绝了我们计划的所有结构的改变。项目经理已经清楚了这种情况需要解决。因此，这个Scrum Master的合同（他和其他人一样都是外包人员）提前终止了。

未完成部门

通常未完成的部门是功能失调的。首先应避免使用未完成部门，随着时间的流逝且团队越来越多地完成“未完成的工作”，这肯定会消除它们。

在*Terra*部门中，“未完成的部门”包括：

• 系统测试和验收测试
• 测试工具

系统测试和验收测试

新功能的系统测试由团队完成，但是系统级的回归测试主要由印度⁴⁴的“测试工厂”进行，而测试工厂是由测试经理“监督”的。大多数测试是手动执行的。

这种功能失调会导致较长的反馈周期、交接、用工具进行沟通、我们与他们、学习不足、责任从行动中分离出来，以及对产品增量准备交付的方式的不清楚。

此外，“测试工厂”来自战略合作伙伴，该合作伙伴与另一合作伙伴互换，后者承诺在自动化回归测试中也将提供更快的速度。这个改变延迟了大多数所需实验的开始。简而言之，这是非常麻烦与混乱的，对于LeSS实施而言这并不是最佳选择，但这是朝着可能改善情况的第一步。

总的来说，目标是从长远来看使回归测试和系统测试自动化，并完全消除该功能或至少显著降低其功能。但是，我认为这个目标实际上与合作伙伴的目标和利益相抵触，因为通过提供手动进行测试的“主体”可以使合作伙伴获得很好的收益。从整体上看这是另一个功能失调，从而被管理层忽略了。

测试工具

测试工具团队负责构建和开发验收测试框架的一部分，维护服务器并运行测试框架，在计划发布产品时执行验收测试。测试工具团队与特性团队一起参加冲刺事件。

这种功能失调的设置禁止（或至少阻碍了）团队学习有关验收测试驱动开发和所需工具的知识。此外，这种情况造成了交接、更长的反馈周期、依赖性以及协调的需要。

该团队的存在是由于历史原因，即测试工具始终由X部门来完成。此外，该工具的体系结构是X部门的主管建立的，据我所知，没有足够的文档证明团队可以自行继续开发工具。管理层允许这种情况，我认为延迟开发的风险被认为是这种设置的影响。据我所知，这个小组没有任何消除它的计划。

客户文档

随着巨型LeSS的实施，本地⁴⁵CuDo团队被解散并整合到团队中。

支持功能

支持功能包括：生产管理，发布管理，架构师和资源经理。

通常，支持功能是LeSS实施中的功能失调。首先应该避免，并且随着时间的流逝一定会消除支持功能，因为这些浪费的工作要么被消除，团队进行有用的工作，而且在团队中建立这些能力。

通常，这些职能阻碍了团队进行自组织，进行交接并延迟信息的流动。

生产管理

生产管理包括两个团队：缺陷管理和配置管理。

缺陷管理

B2B2C产品具有大量累积的缺陷。原因是*Terra*部门的结构，印度有“测试工厂”的事实以及测试工厂与开发团队之间的沟通是通过缺陷工具完成的事实。因此，当印度的测试人员发现系统测试或回归测试中的缺陷时，他们在系统中开一个ticket，他们将工作视为“完成”。然后，开发团队来找出解决方法。

*Terra*部门有自己的团队来协调来自测试工厂、最终客户、生产系统和产品其他用户的缺陷。该团队提供了一级支持，并为团队之间的一级支持之外的问题提供了协调。

协调效果不佳，因为这试图通过像“APO的影子”一样向特性团队注入工作。与APO和团队沟通不畅是一个持续的摩擦点。

当该团队的一个关键人员离开公司时，我们讨论了将缺陷管理的职责移交给团队的可能。但是，这些想法被生产主管否决了，不幸的是这些想法永远消失了。几个月后，生产主管离开了部门。

最大的功能失调首先是问题的根本原因，即系统测试和验收测试小组的存在，以及通过工具进行的沟通，以及试图从侧面将工作注入团队（译者注：工作不是由APO或者PO确认的）。

配置团队

配置团队负责构建系统，并将最终软件投入生产⁴⁶。他们还负责部分运营，因此需要与测试工具团队和特性团队密切合作。我不了解有关合作和分工的详细信息。无论如何，这增加了工作的复杂性，并增加了特性团队的工作量。

这个团队的存在造成了交接，限制了团队学习构建系统他们所需的真正的知识，创建了较长的反馈周期，并将责任转移到了团队外部，从而使预测变得更加不可预测。这个责任应该在团队中。

版本管理

版本管理团队的作用是帮助PO，APO，非常规团队⁴⁷，并维护Jira中麻烦的PB的团队，他们负责检查数据一致性和支持团队，APO向Jira中输入数据，创建和维护电子表格和Jira之间的链接，向高层管理人员报告，帮助APO创建燃尽图以及PB排序所需的其他信息。

就LeSS实施而言，此团队的工作显然是浪费的，并且存在该功能的最大原因是因为使用了Jira（当然，没有人会计算出增加的价值或增加的成本）。使用更合适的PB工具，此功能可以很快消除。

实际上，由于随着LeSS Huge的实施开始，对“发布管理”的需求（即协调）大大降低，因此该功能的规模减小了，团队的负责人离开了并且没有换人。

资源经理

资源经理负责支持项目经理，以创建和维护该部门工作人员的概况，建立能力矩阵，确定战略性的未来需求和潜在的问题领域。

原来的生产线管理结构被彻底淘汰，项目经理没有自由的认知能力来处理生产线人员的所有方面（例如在LeSS框架中，开发负责人将担任这一职位），并且作为快速解决方案，引入了资源经理。

架构师

在实际LeSS实施的过程中，架构师加入到团队中，没有形成自己独立的部门。

由4名架构师⁴⁸组成的职能部门，帮助APO拆分较高层级的需求（分到不同的RA），从而拿走了本该属于团队的职责。这种功能失调的设置会导致例如前期设计决策，从而给团队带来不必要的约束和负担，并且可能导致实施中的解决方案不理想。交接、延误和等待只是一些典型类型的浪费。

另外，我想强调的是，这样一个（架构师）团队的存在支持了X理论模型，在该模型中，“一些人思考，其他人只能动手”，即架构师思考，团队“只能动手执行”，这是许多组织中的主要问题。

然而，架构师在团队⁴⁹中的行为大多像导师，参加了梳理工作坊⁵⁰，并主持了架构师社区⁵¹。这些团队已经具有足够的基础架构能力，他们可以自己梳理大多数的需求。然而在实施之初，团队常常需要架构师的支持。

据我了解，架构师团队存在的原因如下：

• 项目经理认为，将架构师整合到团队中的风险太大
• 该产品是较大系统52的一部分，该系统具有与其他系统的关键接口，并且项目经理不想更改此设置中的任何内容以向外部过渡
• 架构师认为他们不需要改变

我的工作结束时，首席架构师来到我身边，询问开始第一步的时候，是否将架构师团队解散并加入需求领域的团队会更有意义呢。所以隧道里有了灯光（译者注：意味着LeSS实施引发了新思考，后续有新的可能）。

运营任务的问题

*Terra*部门还负责运行软件，并承担各种运营任务。这些任务主要包括，回答客户如何使用该软件的问题，前期分析由*PM＆BA＆CO*提出的相关问题、监视数据（和正常运行时间）以及支持向*Alpha*公司其他部门提供产品相关的报告（不是状态）。

分析工作坊的目的是确定并细化那些运营任务，使其透明化，并识别是否还有其他方法来处理（例如，将一些澄清工作移入梳理工作坊，就像通过消除多余流程的“少即是多”原则）。

当时基本上确定了两个选项：

A. 开发该软件的团队也负责运营问题。 B. 一个专门的团队负责运营任务

LeSS建议的另一种解决方案是轮换角色，这就是说其中一个团队（在LeSS Huge中，每个RA可能需要一个轮换团队）是“快速响应团队”，因此，剩下的队伍减少了。例如，每1-2个Sprint轮换一次该角色。

那些任务每个本身并不大，而是有大量的小任务[^53]。将它们单独放入PB会使PB模糊并数量大增。解决此问题的另一种方法是（事后检查）检查这些任务将花费多少时间，然后PO和团队将保留一定比例的时间用于这些活动（请参阅指南：处理特殊条目）。

解决方案（A）在LeSS实施之前⁵²和实施中就已到位。这造成团队的工作范围出现一些令人不愉快且令人不安的变化，并影响了Sprint的预测。

该解决方案的优点如下：

• 团队可以感受到他们的产品实际运行的现实情况
• 减少交接和排队的数量
• 为团队提供了机会，学习和改善当前客户面对的挑战
• 使问题透明化，以便团队可以解决这些问题

注1：如果这些任务是浪费的和不必要的，则解决方案（A）可能与“少即是多”原则相矛盾，因为这增加了复杂性，支持现有过程而不是问我们为什么需要这样做。但是，将这些特殊的工作条目交给专家团队会使协作更加复杂。因此，当时的解决方案（A）显得更有意义。

注2：事后看来，达到Sprint预测非常重要，即“需要可预测性”。这支持“合同游戏”⁵³的概念。这个概念在最初（仿造）Scrum的实施之初肯定存在，但是在我担任教练的过程中减弱了。

*Terra*部门在自我设计团队工作坊期间尝试建立解决方案（B）但失败了，因此解决方案（A）得以继续。

冲刺事件的问题

巨型LeSS的一项规则是，每个需求领域只有一个产品级别的Sprint，而不是不同的Sprint。Sprint结束时有一个集成的完整的产品。LeSS规则还暗示着一个产品级别的Sprint，而不是每个团队有一个不同的Sprint。每个团队同时开始和结束Sprint。每个Sprint产生一个集成的完整的产品。

整个部门遵循相同的两周节奏⁵⁴。

在进行Sprint计划的第一部分之前，POT举行了一次简短会议以分享他们的情况并讨论协调一致的机会⁵⁵。

在每个RA中，Sprint计划分为第一部分和第二部分⁵⁶。通常，每个团队都会派两名代表参加到Sprint计划的第一部分，并从PB中选择几个条目。

通常情况下，每个条目都经过较好的梳理，在这次活动中没有任何惊喜。团队代表回到他们的团队进行Sprint计划的第二部分⁵⁷。作为Sprint计划第二部分结果的PBI是对APO做出了预测。

在sprint计划会期间有可能的共同工作时，团队自己进行协调。

APO开始在卡上写好PBI，以加快Sprint计划。这种方法演进并包括了一个跟踪系统，因此APO直到数据录入Jira工具才知道哪个团队选择了哪个条目。

然后将物理板安装好，这提供该RA中正在进行和即将进行的工作的可视化。APO进行了两次“记账工作”，将主要内容保留在物理板上，然后数据输入到Jira中。

每个RA的所有团队一起进行Sprint评审⁵⁸。每次Sprint之后，都会与*PM＆BA＆CO*和其他干系人组织一次产品演示。

在团队层面⁵⁹举行Sprint回顾会。较小的改进通常是立即完成的，而无需等待回顾会。每个RA都有一个总体回顾会⁶⁰，而该部门每月有一次全部门的回顾会，跨所有的RA包含所有职能都会参加的回顾会⁶¹。几个月后，每个RA都建立了整体回顾会。

在部门范围的回顾中，与管理层、POT、Scrum Master、团队代表以及其他职能部门的参与者一起识别障碍和改进的主题。有些障碍已转发给AGC进行处理，其他障碍可由参与者解决。通常，在许多方面都进行了改进，例如每日站会（跨团队学习），PO与APO的合作，如何处理缺陷，以及建立了多个社区。

PBR会议通常是多团队梳理⁶²，PM＆BA＆CO⁶³常常需要参加。对于涵盖多个RA的需求，需要组织多个RA一起参加梳理会。

仅在极少数情况下，才会按照LeSS规则邀请最终客户，即在团队、客户、用户和干系人之间尽可能多地进行澄清。

跨团队协调是通过团队非正式地请求其他团队支持⁶⁴或通过常见的Scrum of Scrums会话来进行的。集中的会议似乎是使问题引起团队注意的快速方法。

此外，APO与架构师每天同步，和其他人（例如教练、部门主管）进行讨论，以解决有关公共产品的问题。

Sprint待办列表清单

每个团队都有自己的Sprint待办事项列表⁶⁵。至少每个团队有一个物理板，团队还可以在Jira中使用。板子就在团队附近。

完成的定义

在最初（仿造）Scrum实施期间，团队与APO就所需功能的代表的共同的完成定义（DoD）⁶⁶达成了一致。这是在两个共同的工作坊上完成的⁶⁷。只要我在场，共同的完成的定义便保持不变。不过部门意识到，增强DoD是一种改进⁶⁸的可能。有些团队确实增强了其团队级别的DoD⁶⁹。

在LeSS实施开始的时候，客户文档已集成到团队中，团队的DoD已经包含了这项工作。

单元测试和系统测试被认为是至关重要的，因为当前的设置产生了较长的反馈周期，并且通过Jira进行了尴尬的通信。在创建环境方面正在进行重大变化，因此可以改进测试领域的DoD。

工程实践

所有团队都集成到一个产品中。最初采用“Scrum”时，该部门已经有一个自动构建系统。单元测试覆盖率很低，并且在系统测试阶段发现了许多缺陷。系统测试和回归测试通常是手动完成的。随着越来越多的测试自动化，随着时间的推移情况得到改善。

这是该部门通过增加单元测试覆盖以及显著增加自动化测试量来改善总体测试状况的主要工作之一。我提供了指导，以在所有团队（和所有团队成员）中传播测试驱动开发（TDD）和验收测试驱动开发（ATDD）⁷⁰的能力。部门采取了具体步骤（我没有完全详细了解）以将缺少的能力带入团队。

但是，特别是对于使用“旧”语言进行编程的开发人员来说，这是一个真正的挑战，我在（辅导）的期间团队并没有掌握。

结对编程和编程(mob programming)被推广为一种获得学习能力的方法。举行共同编码活动以总体上提高编码质量。

需求处理

LeSS的实施使需求梳理的方式从根本上发生了改变，从组件视图到以客户为中心的⁷¹拆分。

如果没有以这种方式划分需求的技能，就不可能在基于RA的结构中独立工作。

APO，架构师，Scrum Master以及当然还有团队成员都需要接受培训，这是一条陡峭的学习曲线，存在许多障碍。能够通过了解产品的性质和需求领域来留在客户问题空间中是至关重要的，并且对如何制定和拆分需求的理解对于初始PBR工作坊的成功也是至关重要的。

在新客户（例如保时捷）想要提供车辆保险的情况下，所有三个需求领域都涉及到。通常，承保是开始工作的第一个领域，其他RA在逻辑上是建立在此之上的。

在PB工具中（记住Jira！）需求总是有父级，该工具对于获得关于产品整体功能就绪性的某种信息是必不可少的。

有时PB（电子表格中的第1级）中还包含中等粒度的条目，这是由于拆分较大的条目而产生的，例如，当您创建新客户（例如“保时捷”）时，您不需要一开始就完成承保的所有细节。

签订合同一年后可能才需要某些功能。然后，通过拆分父级的需求，将这些特性拆分并在PB中排序，然后再进行基于单元的拆分。

这时，拆分主要遵循树状拆分，而不是推荐的细胞状分裂[^75]，这是因为开始使用这种方法（对于*Terra*部门而言）已经是激进的新思维方式。这是一种在LeSS实施开始阶段足够好的方法，且相关人员可以一起合作。

此外，在极少数情况下，较小的PBI确实会出现在电子表格PB中，从而提供了像单元格一样的拆分。这些条目为*PM＆BA＆CO*部门提供了证明，“敏捷”似乎在创造适应性方面发挥了作用。这创造了积极的势头，并在部门之间建立了信任。

管理文化的问题

最初“Scrum”实施之前

对于开发人员，产品负责人，架构师和管理人员而言，典型方案如下：一个人在以下方面最多有三个上级：职业，职能和项目。大多数人来自外包公司，只有一小部分直接由*Alpha*公司雇用。来自*Alpha*的员工很少属于*Terra*，而是按（长期）“借用”的基础分配给*Terra*。

这是我所见证的责任的描述：

• 职业：这位上级负责薪水、休假的正式签核以及长期发展。
• 职能：此人负责功能能力的所有问题，例如业务分析、编程语言、领域和测试
• 项目：此人向人们提供了应执行的实际任务。

有时，一个人同时担任职能经理和项目经理。

最初“Scrum”实施

功能和项目维度已删除。取而代之的是，这些任务的一部分是通过自组织的团队和“假PO”来完成的，“PO”主要是技术输出负责人（现在仍然是某类子项目经理）。职业维度仍然存在。

巨型LeSS实施

情况发生了巨大变化。由于巨型LeSS的结构，APO通过减少他们在团队工作中的参与而从其早期的虚假“分析师”和“指导者”PO角色成长而来。这些团队提高了自组织的程度。对于大多数人来说，职业上司仍然没有受到影响。来自战略合作伙伴的所有人员在其母公司中均有职业上司。

很明显，在这种情况下，“文化遵循结构”这一说法得到了确认。新文化显然是值得注意的。

几个Sprint之后

重组后的两个月，由于几个人离开了部门，三个RA中的两个RA需要再次进行重组。这是通过以自我设计团队工作坊的形式自愿提供的，工作坊的主持人（Scrum Master）和受影响的APO对此问题进行了解释。在短短的两轮中就解决了问题，并成立了新的特性团队。继续进展！

LeSS实施的第一阶段以6.6版本上线结束。这次活动仍然具有与旧风格类似的风格，即星期六人们在办公室发布，管理层提供食物并查看该软件顺利投入生产的旧风格。

然而，在编写第一版本报告“发布活动日”之后的一个星期，没有出现预期的缺陷风暴。可以提高质量吗？进展！

辅导方法

可能需要注意的是，该部门尚未决定正式转向巨型LeSS。然而，该部门从仿造Scrum的实施中学到了经验，并开始在很大程度上遵循LeSS框架和结构，基本上没有做出有意识的选择。但是，持续改进和学习还有很长的路要走。

从一开始，我⁷²就与一位“内部”教练^{73 74}结对。

“有人可能会受到伤害” ⁷⁵：经过总共6个月的训练，我的教练期突然结束了。显然，我的方法又太过急，或者部门还没有做好真正改变的准备，而我的看法也太不舒服了。有几个初级教练在我之后来了（又走了）。为了持续改进，需要更合适的高级教练。

结语

在2017年12月，我与项目经理以及部门其他成员进行了讨论。项目经理说…

“尽管对新功能的吞吐量还不满意，但他承认其产品质量已得到显著地改善，并且对于连续三个版本来说，以前预期的新版本出现的常见缺陷风暴并没有发生。该部门搬到了另一栋大楼，那里的房间不像以前那样支持团队合作。该公司在2017年夏季也面临了一些裁员，更多的开发工作转移到了印度。保留了RA的基本结构，但是失去了一些重点。工程实践、特别是测试（代码覆盖率和回归测试的自动化）得到了改善。”

在这段时间之后，我基本上与团队失去了联系。因此，从长远来看，LeSS Huge的实施是失败还是成功的任何陈述都是推测。

从最初的“Scrum”实施到巨型LeSS的实施，这非常令人着迷。突然，“事情”开始发生并对人们有意义。人们更快乐，他们喜欢承担挑战和承担责任。结果产生并且质量提高。见证工作场所的这种转变是一次压倒性的积极经历。进展！

致谢

我要感谢Ran Nyman，他提出了将此案例用作案例研究的想法，感谢他对本案例的支持和最初的评论。我还要感谢ME允许发布此案例。此外，我还要感谢Ran Nyman，Elad Sofer，Bas Vodde和Craig Larman的宝贵意见和评论。

原文链接