前言 业务敏捷可以定义为一个组织重塑自我并快速适应环境变化的能力。克劳斯.利奥波德在他的书《Rethinking Agile》中提出，人们需要优化交付客户价值的流来实现业务敏捷。通过优化流，你迟早会注意到需要组织结构做什么样的调整来加以支持。 首先，关键是理解敏捷的真正含义，就像敏捷宣言中构想的那样，它并不是组织交付客户价值的速度，而是组织以低成本快速响应变更的适应性。（参阅《Scaling Lean & Agile Development》中 _Be Agile一章）。利奥波德对于组织变革还有这样一个观点：在持续地关注系统优化目标时，人们会注意到那些阻碍改进的因素。然而通过系统思考，长时间在实地的观察和实践，对现存系统动态的反思，人们也可以预见到那些阻碍快速适应能力的相对明显的现存组织障碍。在这个故事中，一个组织学习并最终看到影响大规模适应性的组织障碍，它经历了漫长而痛苦的过程。更糟糕的是，很多管理层试图保持传统管理现状而仅仅将事物标记为”敏捷”，而不是去预见 - 或者愿意去预见 - 相对明显的障碍并在一开始就进行必要的变革。简而言之，这个过程恰恰反证了LeSS中的关键导入原则（“对于产品团队，要在一开始就建立LeSS的组织架构，这对导入LeSS非常关键”_）以及由此带来的后果。 所以，接下来的案例说明了，如果组织没有在一开始进行合适的组织设计，会发生什么情况。从开始的传统组织架构和管理方式入手，可能混有一点伪Scrum元素，LeSS要求的组织设计_也许_会浮现。但这将会是一个更长、更危险的旅程，因为它可能不会带来导入LeSS所预想的好处。为什么？因为一旦没有立即采用新的组织架构，那股保持组织现状的强大力量极有可能会获胜（参阅拉曼组织行为定律）。 本案例的关键”反事实”洞察：如果你想开始业务敏捷的旅程，期望减少过程中的许多痛苦，并快速获得LeSS所预期带来的适应性上的提升，一定要在导入LeSS的开始阶段就建立合适的组织结构，就象LeSS规则所倡导的那样。 开始之前的评注 LeSS就是（多团队的）Scrum，Scrum就是单一团队的LeSS。（参阅原则：大规模Scrum也是Scrum）。为了让本案例中的描述更加准确，我还是会澄清哪些是Scrum指南中的规则，哪些是LeSS指导方略中的规则。在参与这个案例的过程中，我受到less.works网站的积极影响，参加了Bas Vodde和Craig Larman的LeSS实践者课程，并花费了大量时间阅读最初出版的两本LeSS书籍。可惜的是那时第三本书还没有出版。在这个案例中，我阐述了我们尝试过的LeSS实验，并且也会关联我们遵循的LeSS原则、规则和指南，尽管那时并不知晓。 简介 下面的案例涵盖了我从2015年2月到2016年9月在一家公司Sys的IT组织做外部教练的时光。Sys是一家来自德国的从事软件行业的跨国公司。因为我已签署保密协议，所以不能在此公布公司的真名和其他相关的公司信息。时间回到2014年底，Sys着手用一个平台来变革公司软件销售方式，取代现有各种外部合作伙伴平台。这个平台的诞生标志着Sys迈入电子商务新途径的里程碑，不仅重新思考了如何直接地向客户销售软件，还重新定义了卖什么（例如，除软件以外的数据）和怎么收费。 这背后的想法是创建一个网上商城，客户可以通过最小的交互，从Sys或是其他第三方软件发现、尝试和购买软件、内容和数据。目标是通过电子商务产品”SAP Hybris Commerce”来提供像亚马逊一样的简单流程，同时涵盖多样的产品部署（就地部署和云解决方案），支持不同的支付方式（信用卡和PayPal）。 2011年，我曾在负责所有内外部平台的Sys IT部门工作过，这些平台跟Sys商店很像，那时我们整个部门开始将瀑布模式替换成Scrum。在用（单团队）Scrum的方式搭建了两个平台之后，我离开了这家公司，去支援其他客户的敏捷之旅；在2015年的早期，我又重新加入Sys来支持这次重要的旅程。 变革之前 系统架构 在我加入的时候，有四个团队并行工作，研发新功能或者增强现有平台，并用固定的时间表合并代码，然后进行好几周的集成测试和验收测试。系统格局是一个复杂的三层结构，包含基于Spring框架的主要J2EE应用程序平台SAP Hybris Commerce，用于存储数据的SAP Hana 数据库，基于SAP PI服务器与SAP ERP和SAP CRM的同步，还有额外的第三方服务用作分析、处理信用卡支付或用户生成内容的集成。 变革之前的组织结构 图3是组织结构。有三个开发团队，两个在欧洲一个在美国，并行工作在系统的不同部分。还有一个架构团队，负责新特性的软件整体设计，以及一个测试团队，在不同团队的代码合并之后进行集成测试。此外，另有一些后台开发（SAP ERP/CRM）专家、DevOps专员和UI专家，他们没有加入任何研发团队，而是建立了自己的团队。欧洲的团队成员（随机地）分布在德国、波兰、西班牙、爱尔兰和保加利亚。这是因为Sys只有六名公司正式员工，其他所有团队成员均来自于专门从事SAP Hybris研发的第三方供应商。 除了技术团队，还有一个超大的业务组织来支持软件的研发和运营。在第一层，经理们带领一个小团队来进行特性的优先级排序、编写蓝图、执行用户验收测试并启用功能。在第二层，又有一个团队专门负责整个产品组合、需求排序以及业务方用户验收。在第三层，是由三个项目集经理组成的项目集管理，一个来自业务（Sys Digital），一个来自Sys IT，还有一个来自Sys Education的项目总负责人。另外，还有一个支持项目集管理的项目和质量管理办公室。为了跟踪研发和业务的进度，每周还有工作流周会，干系人状态周报，以及从项目办公室汇集到管理团队的书面项目集更新。 痛苦的最后期限和变革的必要 当我在2015年2月底加入时，平台基本上已经可以使用，只差正式宣布。各团队还在冲刺最终官方发布日期：2015年5月5日。到时候公司会在美国举行有史以来最大的会议，首席数字官会当场向公众演示这个平台。所有正在研发的功能都是官方需要发布的功能，所以，项目办公室制定了一个看起来能在5月2号发布所有功能的严格的项目计划。该计划包含了研发阶段、系统集成阶段，用户验收测试以及回归测试，就像我们通常说的瀑布模式。 在三月的最后两周和整个四月项目进入一个动荡期。时间表正渐渐延期。当并行工作在不同功能的团队将他们的代码合并到主代码仓库后，很多之前已经测试通过的功能不再能使用或者表现异常。不停修复这些问题又带来新的问题，并且还经常突然接到必须立刻实现的新需求。在此之上，之前从未考虑过的安全问题和负载测试现在也必须解决。管理层变得十分焦虑，每个人不得不工作更长的时间来尽量满足计划。在四月的最后两周，还建立了一个”作战室”，所有的经理、团队负责人和架构师都在这个房间从早到晚不停的清理障碍以保证发布的所有准备工作都做好。最后，开完数不清的升级会议和成百上千小时的加班之后，团队终于能够在大会的第一天发布平台的新版本。 经过了如此痛苦的发布，对管理层来说，毫无疑问现有的研发方式已经不能支撑公司的雄伟目标，那就是销售指数级增长，能快速尝试新的商业模式和推出完全不同的产品。Scrum作为一个敏捷研发框架，专注于首先交付最高业务价值，持续关注透明性、检视和调整，这些都建立在基于经验过程控制的理论之上，它成了一个自然而然的选择。然而要导入Scrum或者LeSS都被认为极其困难，不仅仅是因为组织层级设置和对分散在不同地方的各种技术专家的依赖，还受到巨大营销渠道的影响，即每年有两次不可更改的作为大里程碑的重要峰会。 引入变革 作为一个偏好大规模Scrum的经验丰富的敏捷和Scrum教练，我被要求建议”研发部门”应该如何改变工作方式以应对当前的挑战。 我的挑战因此是（1）让所有人都意识到为了应对挑战_不只是研发部门而是整个组织要改变_；（2）帮助参与者_通过理解为什么_来拥有变革背后的想法，而不只是跟随我的想法遵循我的建议而已。 在一次上层管理者（包含Sys首席数字官）的会议中，我展示了从和业务和研发代表的对话中收集到的关于挑战的总结。它包括： 业务挑战（摘录） 单个特性和产品能力的优先级不明确 _明确标注_已完成的工作在后期出现问题 技术挑战（摘录） 可用性和基础设施问题（性能，端口关闭等）妨碍了日常运行 整个部署流程耗时太长。常常缺少某些部分（模版，后处理等） “架构师”们忙于做构建流程、合并代码、以及基础设施的建立/配置这样的手动任务 使用各种分支而不是基于主干的开发，导致代码合并的工作量巨大；并且质量很低，有许多缺陷/问题 测试数据的的创建是一个非常耗时的过程并深受知识缺口的影响 在准备这个会议的过程中，我还收集了管理层的整体改革目标。基于与管理团队成员一对一谈话和访问，我总结了如下几点：

边境安检系统：LeSS与离岸开发 背景 背景与客户 SITA创建的产品可帮助全球各地政府确保边境安全。我们正在创建的产品是用于自动化边境的解决方案，以在不影响安全性的前提下优化前往各个国家旅行者的流程。该产品是这样构建的，获取前往相应国家的所有旅行者数据，根据可用的监视列表对每个旅行者进行筛选，并针对被政府机构（例如，警察、移民等等）用系统标记的旅行者采取并记录必要的行动。 原文链接 开始 2010年SITA赢得了一项为期18个月的大合同，以创建和实施边境安全系统。该系统包括高度安全的数据中心和部署在该国所有口岸的软件解决方案。 Frank West（产品交付总监）聘请我为内部顾问，来帮助他们采用敏捷的工作方式。 双方之间的合同是构建整个系统（产品和数据中心），并在18个月后以一次性的方式进行部署。但是软件开发总监对这种方法感到不安，因为过去他多次在一次性交付中吃过亏。这次的情况尤其如此，因为该系统非常复杂并且由许多未知数组成。因此，他想（再次）探索敏捷的工作方式，并雇用我来帮助他以迭代、增量和自适应的方式交付该系统。 我加入时，SITA的组织结构非常等级化，划分成独立的职能部门。看起来像这样： 业务团队存在类似的结构，主要由项目经理、销售顾问和业务解决方案架构师（主题专家SME）组成。 向Scrum过渡（但不是LeSS） 我们从为期三天的研讨会开始，了解敏捷宣言、敏捷原则及Scrum。从正确的教育入手至关重要。我们想确保建立一个长期的学习型组织，因此我们将重点放在激发与提供适当的教育方面，以实现更多的协作、迭代和增量式的工作方式。我提供了Scrum概述的培训，然后我们讨论了如何组建开发团队。在与开发团队和管理层进行了大量讨论之后，我们提出了如下的团队结构： 对我们而言，从一开始就建立适当的结构非常重要，以确保我们创建真正的团队，同时牢记“文化遵循结构”，这是“拉曼的组织行为法则”的第五条的一部分，因此我们首先创建了两个跨职能的Scrum团队。这些团队由SME、BA、开发人员、测试人员和架构师组成。尽管我们的确是由一组专家组成的团队，但每个团队成员只有一个头衔即“开发人员”。对团队的承诺和期望是他们将不再担任专家，整个团队将朝着Sprint目标努力，并选择实现Sprint目标所需的下一个任务。 我们的主题专家（SME）人才是边境控制流程和航空业的高技能领域专家。 我与弗兰克（Frank）讨论过，我们不需要项目经理，但他还是坚持要求保留两个人（项目经理和解决方案架构师）来管理公司报告和一些售前活动。他们俩都对要出售给客户的产品有很好的领域知识。 弗兰克（Frank）明白，将来我们不再需要这两个“角色”，但是他建议保留这两个人的角色，在目前将有助于我们跟销售团队就一直在开发的产品保持同步，以便让他们不要将其作为单独的“项目”出售。弗兰克要求他们两个都与销售团队工作，并且他们也定期与产品负责人工作，以了解我们产品的进度，以便他们可以相应地为我们的潜在客户提供建议。 我们继承了组件团队 从总体上讲，整个解决方案是从航空公司收集每位乘客的数据，并根据观察列表对每位乘客进行筛选，以了解是否有不受欢迎的人试图访问该国。该解决方案主要分为两大部分：数据获取系统（DAS）和风险评估系统（RAS）。所以团队也是按这一结构来创建。Black团队（每个团队用颜色来命名）负责获取数据，Green、Blue和Purple团队负责风险评估（译者注：与作者确认最开始只有Green团队）。因此我们从组件团队开始，当时看起来很“合乎逻辑”。 从组件团队到特性团队 最终，我们意识到组件团队在团队之间引入了许多不必要的依赖与移交，这导致了迟来且昂贵的反馈，在整体回顾中我们也讨论了这些反馈。使用这些反馈，我们开启了以避免不必要的依赖的从组件团队转向特性团队的对话。在对话期间我们还意识到，如果我们不尽快转向特性团队（跨团队管理依赖关系将是一场噩梦），将来很难有效地添加更多团队，因此我们开始讨论创建特性团队的方法。 在对话期间，团队还提出了组建特性团队的如下问题： 并非每个团队都有实现下一个优先级条目所需的技能和知识 跨不同架构组件的特性实现的设计可能会变得混乱 特性团队可能会卡在设计决策上 所有这些都是重要点，因此我们决定从一个特性团队开始（“*指南：过渡到特性团队*”），而不是大张旗鼓。我们创建了一个特性团队，并要求他们端到端地交付特性。我们遵循XP（极限编程）的建议，为每个组件引入了“组件牧羊人（Component Shepherd）”作为导师，以避免最初出现任何技术故障。 “组件牧羊人”的主要作用是指导特性团队改动相应的组件，并在团队进行改动时提供利弊对比。所有牧羊人都更像旅行者（“*指南：旅行者*”）那样工作，因此他们大部分时间都可以自由地辅导和指导多个团队。团队逐渐地（9-12个月）积累了多个组件的知识，从而很少再需要“组件牧羊人”的指导。 过渡到LeSS Scrum的实施对我们最初的两个团队工作良好。我们提供的最初产品收到了客户的良好反馈，从而引起了其他潜在客户的极大兴趣。我们的潜在客户喜欢我们交付的特性，但他们也希望产品中有许多新功能。一旦有更多的客户注册了我们的产品，我们就决定增加更多的团队。 我们没有多团队合作的经验，因此开始探索可用于帮助我们的资源。我们发现了两本书，分别是Craig Larman和Bas Vodde撰写的《*精益和敏捷开发大型应用指南*》和《*精益和敏捷开发大型应用实战*》。对于我们的案例，它们看起来像是完美的指南，尤其是关于大规模Scrum框架2（现为巨型LeSS）的概念，因为我们预计将来会增长到大约20至30个团队。 这些书籍在提供有关规模化（以及由此对组织提出的挑战）的准则方面如此丰富（现在仍然如此），以至于它成为我们在整个过程中进行规模化的指导力量。我们开始定期探索这些书中的想法，并进行了一本书中的许多“*尝试和避免……*”的实验。 多地点的离岸开发 尽管我们强烈推荐在同一地点办公，但我们在当前办公室的物理空间仍然受到一些组织上的严格限制，并且需要与位于不同时区的客户进行互动。当我们要求管理层（执行委员会）提供额外预算（主要是更多的团队）时，他们要求我们与位于印度和基辅的现有离岸合作伙伴进行合作，以确保我们在多个时区都有团队存在（主要是中东和澳大利亚）来吸引和支持我们的新客户。 我们接受了挑战，但有一个条件，即一旦选择供应商，我们将像在英国一样进行面试和组建团队，而不是接受下一个可用人员或团队的典型离岸模式（“*避免……外包商说，交给我们吧，我们为您做到敏捷*”）。我们还决定在每个地点都有一些位于同一地点的团队（“*指南：在LeSS中组织多地点办公*”），以确保团队之间能够相互学习，这只有在同一地点的团队中才有可能。我们还将把离岸团队带到英国至少进行4次Sprint（“*尝试……离岸之前先在一起进行几次迭代*”）。 我们以为在管理方面会遇到困难（基于过去的类似经验），但是令我们惊讶的是，在开始离岸供应商选择流程之前，我们的管理层和离岸合作伙伴都毫不费力地达成了一致。我认为他们了解过去离岸团队的加入一直很痛苦。但是当他们意识到我们一直在以新的工作方式交付成果时，他们允许我们尝试与离岸团队合作的方式。 我们办公室内的多地办公体验 我们与团队讨论了多地办公的试验，并确保不会对他们的工作产生任何影响。因为他们也知道我们需要更多的团队，并且对物理地点有很大的限制。尽管大多数人都有多地办公的经验，但这不是我们最近的（检视和调整）工作方式。在对话中，一名团队成员问，在敏捷环境中与多地的团队合作感觉如何？由于我们都没有与多地敏捷团队合作的想法，因此团队中的一位成员给了我们一个想法，即我们在其它地点加入新团队之前，先要经历多地环境的挑战。她建议“为什么不将现有的一个团队搬到另一楼层，而仅使用电话或Skype与另一团队进行沟通，即 没有面对面的交流，看看这带来了什么挑战。我们非常喜欢这个想法，它与书中的一项实验一致（“*尝试……即使位置靠近也按多地思考*”） 一个团队在下一个Sprint搬到的另一楼层（幸运的是，我们在那层上有一个可以容纳团队的空间，但只能用2周）。很快，我们可以看到，即使他们位于同一栋大楼且只有一层之隔，团队也意识到了多地办公向他们施加的挑战。尽管他们已经合作了很长时间，但是无法看到他们，只能通过电话、电子邮件和Skype进行交流，他们还是因此失去了紧密的物理协作（例如白板会议）。 这是一个很好的实验，可以为即将到来的“离岸团队”建立“现场”团队的同理心（这就是他们一开始的看法）。 离岸合作伙伴的选择 我们访问了三个地点（印度两个，基辅一个），并受到了所有人的热烈欢迎。 这些人都从大量的Powerpoint演示开始，介绍了他们的“敏捷”能力和已交付的“敏捷项目”的经验。 很快就很明显，他们对敏捷工作方式的大多数理解都是“错误的”。一次又一次的演讲，很明显这些团体要么是在大肆宣传，要么是对他们所说的“敏捷”一无所知。我们认为他们在“创建Powerpoint幻灯片”方面要熟练得多，但通过交付迭代和增量的软件来交付持续的价值呢？不见得行。 我们想知道为什么他们对敏捷的工作方式没有这么了解。毕竟，这些公司可以访问所有内容（培训、书籍、聘请顾问和教练等以帮助他们）。我真诚地问了他们的一位经理，以便从他们的角度来理解这个问题。他的回答非常有趣且提供了有用的信息，帮助我们了解了离岸IT公司的工作方式。总而言之，离岸公司不向客户提供咨询服务。他们的商业模式通常围绕以低廉的成本提供人员，并与客户期望他们工作的方式保持一致。因此，他们不会真正地投资任何新事物，直到成为主流，并且客户希望他们对新事物有所了解。 在拜访了所有离岸候选人之后，我们意识到这将是一个漫长、痛苦而又令人兴奋的旅程。因此基于跟他们的经历，我们建议仅从印度班加罗尔的那个团队开始。按照《精益和敏捷开发大型应用实战》（“*尝试……更少的地点*”）一书中的实验，我们不想从多个离岸合作伙伴的多个地点开始，以创建不必要的复杂性。 “商业部门”推动我们同时使用这三个地点。但是，当我们向他们解释了多个地点及多个合作伙伴的负面影响（沟通、协调失灵、语言和文化差异、与其中一个地点的签证问题等）之后，尤其是在敏捷开发环境中，我们被允许先选其中一家，但他们还是期望将来可以用所有的三个地点。 除了上述提到的多个离岸地点的负面影响之外，我们还希望保持组织的简单性，并继续我们*成为敏捷(be agile)*而不是*做敏捷(do agile)*的旅程。我们已经在Scrum和Extreme Programming工程实践方面有了一个良好的开端，我们希望增加更多的团队，但不增加任何不必要的协调、离岸管理等开销，以保持以客户为中心。基本上，我们希望通过消除客户和团队之间任何不必要的复杂性来简化组织，从而扩展产品的开发规模。在成功试验两个地点（英国和另一个地点）之前，我们致力于避免不必要的、人为的管理多个地点的复杂性。我们深知与离岸IT公司合作会带来不必要的开销，例如与项目经理、现场协调员、离岸项目经理、多个时区等打交道。 当我们自己试图简化组织设计保持以客户为中心时，我们理解了为什么“商业部门”会迫使我们选择这三个地点。高层迫使他们将新工作移至离岸地点以降低成本。他们表现得像一个会计师（还是一个很好的会计师），却不了解其行为的整体系统含义。简而言之，这是经典的*局部优化*。 我们部门的业绩在整个组织中引起了积极的反响。我们的成功故事（高质量的产品、满意的客户、提早交付和持续交付、更多的业务等等）也触及到产品开发外部的各种人员（例如HR、商务等），他们对我们不同的做法感到好奇。我们邀请商务部门的人员与我们的团队会面，以便向他们解释我们的工作方式。这与LeSS的采用规则有关：“*对于产品组以外的大型组织，请使用现场现地（Gemba）来采用LeSS演进，创建以实验和改进为准则的组织。*”。访问我们的时候，他们惊讶地看到我们在部门内创建的可视化效果。他们可以轻松地查看我们的产品待办事项列表（墙上的故事地图），每个团队的Sprint待办事项列表（白板上），构建的统计信息（构建状态，缺陷数量等），监视器等，以及在地板上合作（主要是人们一起工作的噪音）（译者注：在地板上合作指的是大家走来走去，面对面的沟通）尽管来自非技术部门，但他们的反应是您为什么不采用这种方式工作，这是如此明显。他们还真心想帮我们跟离岸供应商协商一个更低的价格，如果我们愿意直接与10多个团队工作的话。我们礼貌地拒绝了，并意识到我们还有很长的路要走，以使我们的组织精益化和系统化思考。他们显然看不到增加10多个团队相比于1个团队来说的系统影响。他们只是从自身降低成本这一局部优化目标来看，而没有意识到这样做可能是增加了总体成本。 我们与离岸合作伙伴约定的条件之一（在我们决定与他们合作之前）是我们寻找“长期合作伙伴关系”，而不是临时的项目方式（“尝试……将离岸组织视为内部合作伙伴 ”）。实际上，这意味着： 我们将采用相同的工作方式（如Scrum和XP中的工程实践）和 相同的团队组成（跨职能和自我管理）。 我们还提供了帮助，以Scrum、XP和精益思想为基础，让离岸管理人员理解和适应工作方式，这样做我们实质上是忽略了组织边界。我们说过，我们将在最初的3-6个月内提供一名教练，以帮助他们建立和完善对精益思维和敏捷工作方式的理解。这位敏捷教练的费用不需要他们承担，因为我们将这视为与他们建立长期可持续伙伴关系的投资。

巴伐利亚汽车制造商的LeSS转型 背景 Valtech德国公司是选中的供应商，以帮助其应用敏捷开发来创建宝马集团的新*BMW i*汽车的直销流程。这需要新的IT支持系统，所有这些系统都已嵌入到现有的IT环境中，其中80多个系统会受到影响。有一个跨越许多项目的大型项目集来创建新的支持系统。 其中一个项目是新的统一销售平台（USP）系统。USP从头开始实现，集成了30多个外部系统接口。*BMW i*推出的其他合作伙伴项目，仍沿用非敏捷过程模型。因此，跨项目的共同里程碑、报告和协作成为一个挑战。 经过2年多的开发，USP按时发布，并具有很高的质量和客户（比利时-荷兰-卢森堡市场）满意度。 阶段1：在多个特性团队之前 2012年2月，USP在充满挑战的环境中开始开发： 时间压力大，因为上线日期已经确定 直销业务流程仍在讨论中，尚未定义 因此，USP产品的范围还不清楚 大多数参与者不熟悉宝马集团的业务、销售流程及敏捷方法 USP项目嵌入在传统的项目集（*BMW i*项目集）管理系统中 由于上述情况，USP项目决定使用Scrum和敏捷工程实践，来尽早和持续地获取有关产品进度和组织进度的反馈。敏捷开发从一个Scrum团队开始。这个团队建立了合适的敏捷开发流程，搭建了合理的开发基础架构，找到了与业务部门的协作模式，并为敏捷开发奠定了坚实的基础。 这个最初的团队评估了所需的工具，搭建了开发环境和持续集成系统，尝试了不同的Sprint长度，并实现了第一个业务功能，验证了新组织是否可以正常工作。 从第一个Sprint开始，USP团队在每个Sprint结束都演示了可运行的和经过测试的软件。 后来，团队增加了一些人，这些人以传统的职能和组件团队的结构进行了组织，这代表了更广泛的*BMW i*项目集中使用的标准模型。 在USP 1.0版本之前团队一直在使用这种结构。 阶段2：转变到多个特性团队与LeSS 当前的组织结构对发布1.0版本来说已经够用了。不过，作为教练我们预见到，对于下一个更大的版本，这种组织结构的扩展性不好。团队需要更灵活（敏捷），因为优先级和需求经常变化。团队需要能够从产品待办列表中选择不同的条目，并交付完整的端到端特性。此外，还需要减少特性的周期时间以缩短“上市时间(time to market)”。 在先前的组织中，团队只能做一种类型的功能或特定的组件工作。这限制了更改产品待办事项的优先级和团队灵活地“转到新工作”的能力。而且，专家小组间的交接和延误，延长了平均周期时间。此外，还增加了协调和集成的工作量和问题。 因此，根据我们的建议，团队同意重组为多个特性团队并同时采用LeSS。 我们的目标是创建五个新的跨组件和跨职能的特性团队。 由于现有的商业合同和项目集的政策，USP项目组无法完全重组为特性团队。例如，有一个UI设计治理小组负责整个程序的UI一致性。还有一个测试管理团队，负责协调项目集范围内的跨项目测试活动，并为整个项目集提供报告。这个团队不做测试工作；测试工作仍由实现团队自己完成。不过，测试管理团队对（实现团队）“未完成（undone）”的部分做出了贡献，例如组织外部公司做渗透（安全漏洞）测试。此外，按照项目集政策，这里还需要一个项目管理团队，汇报给上层的（传统）项目集管理团队并负责人员、设施和设备管理。 图 1: 阶段2的USP项目的组织结构 自设计特性团队工作坊 我们还达成一个共识，即通过*自设计团队工作坊*（LeSS实验之一），重组为特性团队。 团队花了3轮的时间（每轮20分钟）形成了符合愿景的组织：所有特性团队应能够独立处理所有利益相关者/请求者的产品待办事项。 在组建新团队后，他们创建了新的团队名称，找到了自己的团队空间，选举了Scrum Master和“首席”开发人员（由于政策原因，这仍然是必需的角色）。 整个团队的自设计工作坊大约持续了三个半小时。 有关自设计团队工作坊的详细信息，请点击此处 团队建设工作坊 自设计团队工作坊是一个很好的开始。但是在自设计团队工作坊结束时，有一些新成立的团队，他们必须应对新的动态。根据LeSS的说法，向特性团队的转变是对旧系统的重大更改。该项目组面临着两方面的扩展。一方面是跨团队协作，按照一个产品待办列表的优先级与所有团队合作。在LeSS环境中，Sprint仪式和同步会议覆盖了这一方面。第二方面与团队内的可用知识有关。所有团队都让团队成员了解不同的组件。这体现了团队中的一个瓶颈，因此这种情况是扩展的障碍。为了在系统层面上进行改进，需要改善团队内部的知识共享。另外，项目管理团队的目标是尽快使这些新团队重新发挥作用（尽快开始工作）。因此，项目管理为每个团队提供了进行额外的团队建设工作坊的机会。本次工作坊的目的是降低社交障碍，启动知识共享措施，寻找工作协议并在团队挑战中反思团队动力。 工作坊日程： 时长 主题 00:05 介绍、日程 00:10 破冰练习 00:30 团队知识模型 (agile world 2013) 00:45 一致同意的措施 00:30 团队愿景和团队章程 00:50 团队挑战 (室外) “有毒废料Toxic waste” 00:10 结束和反馈 03:00 社交：午饭或晚饭 {: .

作者：(Bas Vodde and Craig Larman) 译者：Bob Jiang 审校：本洋 少即是多： 组织简化的7个设计原则 为什么采用敏捷或LeSS？许多组织的目的是提高个人生产率或团队生产率，提高活动、产出、速度或资源利用率，不幸的是，却没有意识到这通常会导致整体价值交付的*降低*、客户功能周期时间变长以及适应性降低。LeSS并不专注于局部优化（例如提高个人生产力），而是*优化组织*以最大程度地提高客户价值交付和组织敏捷性（适应性），即组织成员可以轻松、快速地根据学习*改变*方向。 如何实现敏捷、灵活、适应性强的组织？通过创建*更简单*的组织！ 具有许多角色、流程、部门和工件的复杂组织适应变化的速度很慢。简单的组织具有快速适应的潜力。在LeSS社区中，我们称此为简化(descaling)组织的复杂性。这是LeSS原则的精髓之一，即*少即是多*原则。 我们如何设计更简单、更敏捷的组织呢？使用以下组织设计原则来简化成为LeSS组织： 从*专业角色*到团队 从*资源思维*到人才思维 从*围绕技术进行组织*到围绕客户价值进行组织 从*独立团队*到持续的跨团队合作 从*协调集成*到通过集成进行协作 从*项目*到产品 从*许多小型产品*到少数几种广泛的产品 1. 从*专业角色*到团队 传统组织具有一些单一的专业角色，并详细定义了这些角色之间交互的流程。每个人负责他们自己的专业。他们因此被公司雇佣，并可能其一生都从事此专业领域。当所有个人都履行其确定的角色时，组织绩效将得到最大化。理论上是这样，但适应性很可能较低。 LeSS组织的团队负有共同责任，即实现以客户为中心的目标-通过自我管理，他们自己决定如何工作以及由谁来完成。团队成员不会陷入通才或*单一*专家的错误二分法（译者注：Alternative 二分法即非此即彼的方法）中。人们天生有喜好，但他们不会局限于一个专业。随着这些职责成为团队职责，许多专业角色（例如测试人员、交互设计师或业务分析师）将不复存在。广泛的责任感和自我管理提高了适应能力。 2. 从*资源思维*到人才思维 传统组织假定个人的技能是相对固定的，因此将人作为资源来管理。传统组织结构的目的是最大程度地利用这些资源，以提高个人生产率。这需要大量的管理工作来解决这些复杂的资源分配。 LeSS组织把人作为人来管理，并认为个人的最强大技能是*获得技能和发展技能*。LeSS组织结构的目的是故意让现有技能和知识与所需的技能和知识不匹配，以增强适应性。这就需要人们学习，这样既带来欢乐又带来不舒适。但是所有复杂的资源管理都消失了。 3. 从*围绕技术进行组织*到围绕客户价值进行组织 传统组织围绕其技术构建组织。许多人以自己的技术专长来凸显自己，围绕技术进行组织似乎可以最大化他们的个人生产力。交付客户价值通常需要不止一种技术，这会造成额外的协调工作并降低了适应性。 LeSS组织围绕客户价值构建其组织。深入了解客户是至关重要的，这样才能用技术解决“他们的”问题。通过围绕客户价值构建组织可以让团队离客户更近，从而加深对客户的理解，这样会让适应性更强和客户价值更高。 4. 从*独立团队*到持续的跨团队合作 传统组织倾向于独立团队，团队专注于产品中自己的部分。这些团队避免工作不停被打断的方式是定义清楚的接口，其他团队必须遵循。更改，审查和批准流程避免了对这些接口的频繁更改。通常，通过隐藏、延迟真正的依赖关系才能实现独立性。团队之间的这种割裂降低了组织的灵活性。 LeSS组织倾向于多个团队拥有共同的工作。这些团队不断合作，为一个始终如一的产品做出贡献。尽管每个团队都有自己的目标和身份，他们还是像一个大团队一样运作。更改，审查和批准可以大大被简化甚至消失。 5. 从*协调集成*到通过集成进行协作 传统组织进行协调以整合（集成）许多团队的输出。由于团队“异步”交付其输出，因此协调的责任在团队外部，从而导致协调角色（例如项目经理或发布经理）和协调事件。协调冲突很常见，会导致重新评估优先级和调整优先级。 LeSS组织的团队不断整合（集成）他们自己的工作。通过不断的集成，团队发现了跨团队协作的机会 – 一个令人惊讶且强大的想法。由于跨团队集成具有同步性，因此团队现在可以同时共享工作，还可以将协调责任融入到团队中。团队外部的协调角色消失了。 6. 从*项目*到产品 传统组织将开发工作作为项目或*项目集*（大型项目）进行管理。项目的开始日期和结束日期明确，范围明确。人员被按照预定的时间分配给项目。预算由预定范围的期望值决定。这样几乎没有余地来响应变化。多种多样的项目导致了复杂的项目组合管理，以同步对项目进行资源重新分配。 LeSS组织将开发工作以产品进行管理。产品用途明确，但没有固定的结束日期或固定的范围。人员被分配到产品中，但没有预定好的时间长度。预算由潜在价值决定，而不直接与具体范围关联。这为响应变化留出了很大的空间。产品是持续进行开发的，因此按规律节奏把人员分配到产品就足够了。复杂的项目组合管理消失了。 7. 从*许多小型产品*到少数几种广泛的产品 传统组织倾向于管理基于技术的小型产品，例如服务、组件、应用程序或平台。但是，没有一个小型产品是孤岛，它们需要交互并集成在一起才能带来客户价值。这导致了复杂的跨产品管理结构，以用于协调、排优先级和制定预算。 LeSS组织倾向于管理以客户为中心的广泛产品。服务、组件、应用程序和平台属于同一产品，其中只有一份产品待办事项列表和一个产品负责人。团队创建以客户为中心的功能，并跨组件工作。复杂的项目组合管理消失了，复杂的跨产品管理结构消失了、或者变得非常简单。 每个组织设计的选择都需要组织思维的巨大转变，并且这对人员、团队、组织结构和管理都有很大的影响。这些变化并不总是那么容易，但是它们可以带来更简单、更具适应性、更有目的性和更有趣的组织，这样的组织能交付更高的价值。

德国大保险公司（化名）的巨型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*部门隶属于一家超大型的德国保险公司Alpha1。*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产品的客户需求进行分析并确定优先级。该部门的目的是开发这两种产品。 Terra和相关部门的简化示意图 试行阶段 该部门对两个独立的子产品进行了单团队Scrum和工程实践的试验。这些团队由一个PO，一个Scrum Master和一个开发团队组成，每个团队对Scrum进行了大约6个月的试用，并取得了积极的成果。积极的反馈以及其他因素（例如，需要更高的灵活性、对变化的响应能力、业务价值的增加、降低部署的风险、提高产品质量）引领整个部门的敏捷之旅开始了。 该部门建立了一个“敏捷指导联盟”（Agile Guiding Coalition AGC）2，其目的是通过例如定义方向，决定使用哪些框架，帮助团队及消除障碍来指导和支持该部门。AGC由*Terra*的高级管理团队，敏捷教练，架构师，Scrum Master和产品负责人组成。 最初的“Scrum”实施 组织 最初该部门分为以下职能部门： 设计 编码 测试 每个团队都有一个团队负责人（TL3）和一个业务负责人（BL）。最上面是项目经理（PM）。此外，还有一些支持功能，例如架构，版本管理，缺陷管理，运营和其他一些团队。 在最初采用Scrum的开始，我们移除了职能部门并建立了新的结构。 该结构由管理层设计的、十四个分布的Scrum团队（跨职能，但仅限于一个组件）。每个团队都有专门的产品负责人（PO）并且部门有一个整体的首席产品负责人（CPO）4。未改变其他部门（产品，架构等）的结构。 该结构的设计无需任何LeSS专家指导。这项变革是自上而下的一次性5引入的，没有人心甘情愿，也没有得到Terra6部门的高级管理层自上而下的支持。 我开始辅导时，新组建的组件团队是第一次见面。在启动会议上，项目经理解释了变革的原因并传达了方向。 从职能部门到组件团队的结构转变。 在这个阶段AGC决定： 新组建的团队在新架构中工作的日期 2周的Sprint节奏 具有基本的Scrum仪式和（每个Sprint）（产品待办列表）梳理工作坊（PBR）的框架 产品级的Sprint评审，其中志愿团队向其他团队、高级管理层、产品管理人员介绍功能 单独的系统测试功能 Scrum of Scrums 产品负责人创建：

Index | Scrum Master | Product Owner | Dev Team | Scrum SAFe请不要篡改Scrum！ 我们爱Scrum。 我们反对 SAFe（大规模敏捷框架）创建和推广的对于 Scrum 的误解。 当前的SAFe描述明确承诺可以在SAFe中使用Scrum。许多类似的陈述如下： 大多数敏捷团队都将Scrum用作基于团队的主要项目管理框架。 规模化敏捷框架-ScrumXP 此外，当前的SAFe描述使用称为Scrum Master的角色，从而再次直接引用了 Scrum： Scrum定义了敏捷团队中由具有特定职责的两个角色： 产品负责人（PO）和 Scrum Master 。SAFe文章中用该名称进一步描述了每个角色。 规模化敏捷框架-敏捷团队 当前的SAFe描述包含有关Scrum的误导性信息： 1. 如这里所描述的，SAFe中描述的 Scrum Master 角色与其在Scrum中的实际含义存在严重偏差。 2. 如这里所描述的，SAFe中描述的产品负责人角色，与其在Scrum中的实际含义存在严重偏差。 3. 如这里所描述的，SAFe中描述的开发团队角色，与其在Scrum中的实际含义存在严重偏差。 4. 如这里所描述的，根据SAFe当前描述，在SAFe的实施当中不可能采用真正的Scrum。 许多组织相应地实施SAFe，并具有各自的角色和过程。由于当前SAFe描述中的声明，他们可以合理地期望能够在此结构内采用 Scrum。相反，它们受SAFe角色和过程的约束而使用大量 Scrum 反模式并造成严重的功能障碍。 但是，这些组织假定这正是 Scrum 框架，并且他们基于此学习了 Scrum。SAFe引入了对Scrum的完全错误的理解，并剥夺了组织实现其目标的机会。 此外，对于决定在SAFe中发展Scrum Master技能的人来说，这会带来严重的职业伤害。他们学习了错误的理论并采取了功能障碍的行为。之后，他们很难理解真正的差异，以便能够有效地帮助组织正确地采用Scrum。 我们呼吁SAFe的所有者尊重人员和组织，并停止承诺可以在SAFe中使用Scrum和Scrum Master角色！ 因此，以下是在SAFe的描述中需要进行的最低限度修正： 从SAFe描述中删除所有有可能采用Scrum的声明。 在SAFe描述中重命名Scrum Master的角色，以排除其与Scrum有关的实际Scrum Master角色的关联。 * （*）如上所示，SAFe中的产品负责人和开发团队角色与真正的Scrum角色存在严重偏差。但是，只有Scrum Master角色与Scrum不可分割。 为了在该异议下“签名”并在下面显示您的姓名，请访问原文链接。

Index | Scrum Master | Product Owner | Dev Team | Scrum Scrum - SAFe请不要篡改Scrum！ 这里我们将解释，根据SAFe的描述实施的话，不可能采用Scrum的观点。 Scrum是用于开发、交付和维护复杂产品的框架 源自《Scrum指南》 Scrum（名词）：一个框架，人们可以用其解决复杂的适应性问题，同时以富有创造力的方式交付最高价值的产品。 源自《Scrum指南》 Scrum专为产品开发而设计。产品是为客户而生的。整个Scrum团队旨在产生最大的业务价值，始终专注于客户的需求和整个产品。 敏捷团队 – 负责定义、构建、测试以及在适当情况下部署解决方案价值部分的一组人 源自《规模化敏捷框架SAFe - 敏捷团队》 取而代之的是，SAFe描述表明，敏捷团队仅处理部分功能是可以接受的。在现实生活中，这通常会使团队专注于系统组件。 无论如何，每个敏捷团队仅提供功能的一部分，就无法为真正的客户带来任何价值。由于拥有自己的产品待办列表和产品负责人，他们既不关注客户需求也不关注整个产品，而是被迫在系统组件级别上进行本地优化。 如果按照SAFe描述规定，那么甚至还可以所有参与共同产品开发的开发团队都拥有一个产品负责人和一个产品待办列表。这将有机会在Scrum中进行适当的扩展。但是，SAFe的定义给出了完全不同的方案 - 每个敏捷团队都有自己的团队待办事项列表和自己的产品所有者。 根据SAFe当前的描述来实施敏捷，敏捷团队本身不是开发一个产品，所以没有理由去关注客户的需求。取而代之的是，这迫使团队在系统组件级别上进行本地优化。 在下面来自 SAFe 描述的图片中，我们可以看到一个程序板示例，其中显示了不同团队之间的众多功能依赖关系。这不是设计Scrum和规模化Scrum的方式，但这恰恰是完全错误的Scrum方法及其在SAFe中规模化的结果。 框架中的每个组件都有特定的用途，对于Scrum的成功和采用来说至关重要。 源自《Scrum指南》 Scrum是一个框架 - 如果缺少任何元素，对于具有特定上下文的特定公司而言，它可能行不通。但是，在这种情况下，这不是Scrum。 然而，由于如此处所述， SAFe中描述的 Scrum Master 的角色与其在Scrum中的实际含义有严重的偏差。而且，作为如此处所述和[此处所述]((/remove-scrum-from-safe-devteam/)，SAFe中描述的产品所有者和开发团队的角色与Scrum中的实际含义存在重大差异。 这意味着，根据其描述在SAFe中实施的任何内容，都不能与Scrum框架相关联。 本文链接 本文翻译自如下网站，如果译文和原稿有任何差异，请参考原文。 in case of any discrepancies between the translation and the original, the original version should be considered as the correct one Remove References To Scrum From SAFe!

Index | Scrum Master | Product Owner | Dev Team | Scrum Scrum Master - SAFe请不要篡改Scrum！ 在这里，我们将解释SAFe描述中引入了Scrum Master角色的观点，但该角色与其在Scrum中的实际含义有重大差异。 如《Scrum指南》中所述，以下内容是Scrum Master的三个重点领域之一： Scrum Master通过多种方式为组织服务，包括： - 领导并指导组织采用Scrum。 - 规划组织内的Scrum实施。 - 帮助员工和利益相关者了解并实施Scrum和经验式产品开发。 - 引领变革以提高Scrum团队的生产力。 - 与其他Scrum Master合作，以提高组织中Scrum应用的有效性。 源自《Scrum指南》 指导组织是Scrum Master的一项重要职责。 相反，在SAFe描述中： - 完全没有Scrum Master负责指导组织（coaching organization）的职责。 - 完全没有Scrum Master负责组织变革（organizational changes）的职责。 据我们所知，文化遵循结构。根据SAFe的描述创建的结构将迫使Scrum Master仅专注于团队，这仅是组织作为系统的一部分。而这通常会导致局部优化，并对整个系统产生负面影响。这是最关键的Scrum反模式之一。 此外，根据《Scrum指南》： 在Scrum指南中定义了，Scrum Master负责推广和支持Scrum。 源自《Scrum指南》 相反，在SAFe中 > 然而，某些团队（尤其是系统团队、运营和维护团队）选择将看板作为主要方法。 源自《规模化敏捷框架-敏捷团队》 尽管 Scrum Master 角色主要基于标准Scrum， 但敏捷团队（甚至是那些应用看板的团队）都可以建立此职位，以帮助团队实现其目标并与其他团队协调活动。 源自《规模化敏捷框架-Scrum Master》 在这些情况下，Scrum Master可以在完全不需要使用Scrum的团队中工作。在这种情况下，Scrum Master无法根据Scrum指南履行上述职责。