精益原则加速Scrum成功

Posted 2021-04-25 艾拉驿站

Edited by Michael de la Maza& Cherie Silas
@Copyright 2018 Nirmaljeet Malhotra All rights reserved

对于一直走在敏捷之路上的组织，Scrum是一段时间以来的首选框架。框架的简单性及其实现经验性过程的能力是Scrum成功的背后原因。话虽如此，但有人可能会质疑团队通过Scrum是否真正达到了敏捷性。

Scrum和敏捷是经常互换使用的术语，这让做Scrum和变得敏捷之间的区别变得很重要。在我看来，如果Scrum是手段，那么敏捷就是终点。简而言之，Scrum就像是驾驶员手册。正在学习中的驾驶员会一直使用它，直到他/她将行驶规则内化为止。一旦在一段时间内持续驾驶，驾驶员就可以轻松掌握交通情况，而无需在每个步骤都去参考手册。

从做Scrum到敏捷 - 障碍              

Scrum的每个方面都有其目的。从角色，工件到事件，都有价值与之关联。然而， 值得注意的是，长期用Scrum的团队并不总是表现出高绩效团队的行为或模式。问题在于只是把Scrum当做一个流程采用，而没有在心里有个终点。在我与用scrum工作多年的组织合作时，一次又一次地验证了这一点。

基于敏捷宣言中价值观与敏捷原则，我们一直把敏捷称为一种理念。然而， 团队出于以下原因而难以成功地实现思维理念转变：

培训 – 大多数敏捷转型计划都是从培训开始的，这些培训旨在使团队熟悉Scrum框架，而对敏捷理念的关注很少。是的，培训已经涵盖了敏捷宣言和原则，但是对团队如何从做Scrum到获得敏捷性的教育不足。这通常会使团队相信Scrum是最终状态。

Scrum作为一个流程 – 对团队进行培训之后，下一步就是确保遵守框架。通常，团队将有一名Scrum Master，其职责是按照Scrum指南中的定义来推广和支持Scrum。有趣的是，尽管某些组织将其Scrum Master视为教练，但Scrum指南并未将术语“持续改进”与Scrum Master角色相关联。这也使团队将Scrum视为流程和最终状态。

流程合规性 – 具有多个团队的组织经常强制执行合规性，这归因于对流程一致性要求，以及使用Jira或Rally等支持工具的需求。这种合规性的想法通常与自组织和自管理团队的属性直接冲突，迫使团队生活在Scrum盒子中。

以上只是一些原因。您可能有自己的原因，但重点是强调需要超越流程。

运用精益原理    

这个知识库将敏捷的根源与精益联系在一起。精益从制造开始，并将其应用于需要转变观念的知识工作者。精益为软件开发引入了面向客户的灵活系统。在Scrum团队中应用精益原则已显示出令人鼓舞的结果。

玛丽和汤姆帊彭迪克(Mary and Tom Poppendieck)在他们的《精益软件开发：敏捷工具包》一书中概述了如何将这些精益原理应用于软件开发。以最简单的形式，这些精益原则可以应用于scrum之上，以加快从做scrum到敏捷的转变。

精益和敏捷从定义上来说是不同的，但它们可以是实现共同成果的重要伙伴。这是将精益原则应用于进一步促使Scrum团队变得更成熟的方法：

消除浪费 – 各种浪费都会影响Scrum团队的成果。在大型组织中，这些浪费通常归因于流程，复杂性，结构，筒仓，层级架构等。不懈地追求持续改进的组织和团队可以从有意识地逐步寻找消除浪费的机会中大大的受益。价值流映射应该在业务和开发流程级别进行，以暴露浪费并提出消除这些浪费的紧迫性。

内建质量 – Scrum团队的常见挣扎之一是交付“潜在可交付的”工件。原因包括需求质量，需求结构（未垂直划分），依赖关系，不稳定的环境，团队孤岛，流程，交接，度量标准等等。然而; 最常见的原因是迭代中产生的缺陷数量，或缺少支持端到端测试的工具和自动化，以及处理缺陷的理念。

大野耐一在谈到丰田生产系统时谈论到“自动化”（自我调节）。这个想法来自一个织机，当线程中断时，织机会自动停止。当应用于软件开发时，其想法是在发现缺陷后立即执行紧急，协作，蜂拥等行为。

另外，内建质量的精益原则首先倡导质量是每个人的工作，而不仅仅是测试的责任，且这需要是一个纪律性的实践。缺乏它也与消除浪费的首要原则相冲突。

创建知识 – 在玛丽和汤姆的书中，这被称为“扩大学习”，其中学习某物的最佳方法是通过去做，换句话说就是通过实际创造价值。精益说的也是通过实验学习。在Scrum团队中通常不会观察到这些行为和理念。

阻碍Scrum团队创建知识原则的一些常见反模式包括团队结构，其中团队由许多专业技能组成，从而创建了筒仓成功标准和成果。此外，还可以看到Scrum团队以建立可预测性为借口做“基础”工作。这就是为什么敏捷将术语“进化”与软件开发的所有动态方面（包括需求，架构，设计等）相关联的原因。

推迟承诺 – 尽管Scrum围绕着短反馈周期的想法，但团队通常会因各种原因而面临时间或范围的挑战，或两者兼有。这种情况通常在这种组织内可见：将敏捷性限制在团队中，且仍可能有PMO参与年度计划活动，从而导致承担假象的承诺。

同样，在团队级，团队无法履行其迭代承诺（即使术语“承诺”已从Scrum指南中删除）也可能对团队很不利，导致在其他领域（通常是质量）上的妥协 。

延迟承诺的精益原则并不意味着团队不做计划或做出不知情的决定。它鼓励在最后负责任的时刻做出决定。这个时刻可能因公司，行业和团队而异，但基本思想是确认和进行实验以做出明智的决策。

在为战斗做准备时，我总是发现那些做好的计划没有用，但随时进行规划是不可或缺的” –德怀特·艾森豪威尔

快速交付 -“快速交付能力”是大多数公司采用敏捷方法的最常见原因。快速可以在不同的上下文中被不同地解释。一个示例是Etsy，它每小时将代码多次交付生产。但并非所有企业都一样。

“快速”一词最初旨在实现快速反馈，以使团队能够检视并调整，以让客户满意。

每个团队都希望尽快交付并尽快把价值交付到客户手中，但是大多数Scrum团队由于各种原因而无法做到这一点。一些例子：

- 组织和团队的结构导致复杂性增加

- 缺乏支持的实践和工具

- 大增量，过于展望未来

- 缺乏消除障碍的紧迫性

- 倾向于建立完美的解决方案

回到前面提到的原则，快速交付可以是消除浪费，内建质量和创建知识的结果。集中精力应用这些原则会滞后快速交付的结果

您会在精益中经常听到的概念之一是“概念到现金”。它指的是从构思创意到客户开始购买该产品的前置时间，也可以通过尽快节省成本，降低成本等来开始增加价值。

尊重员工 –  Scrum的5个价值观（承诺，勇气，专注，开放和尊重）有助于在团队中建立信任，并且Scrum团队成员在使用Scrum角色，事件和工件时应学习和探索这些价值观。但是，通常观察到的是，在团队外部做出了直接影响团队的重要决定。简而言之，决策不是从工作发生的地方做出的。

团队面临的另一个挑战是心理安全问题。在精益的世界中，尊重就是发展和赋能员工，并信任他们会做正确的事。精益谈到了“ Gemba”的概念，这是指领导者走访并观察工作发生的地方，询问并与团队一起识别解决问题的对策。

精益还通过以下方法来鼓励尊重员工：积极有效的沟通，鼓励健康的冲突，将与工作相关的问题作为一个团队来解决，并相互赋能以做到最好。

整体优化 – 局部优化是软件开发中的一个严重问题。玛丽和汤姆指出了局部优化背后的两个关键原因。首先是开发人员为了提高速度而发布草率的代码，其次是由于开发测试之间的交接而产生的较长的周期时间。

精益建议使用价值流映射来设计，生产和向客户交付产品或服务。在识别了价值在团队中的流动方式后，许多组织决定将他们的软件开发团队组织成完整的，跨职能的，集中办公的产品团队，这使他们能够拥有从头到尾交付一切需求，且不需要依赖其他团队。

Scrum是一个框架，这意味着它是系统的必要支持结构或基本结构。熟悉Scrum并达到预期结果的团队可以应用上述原则，在各个级别快速将自己转型为一支绩效卓越的团队。

无论团队选择采用哪种框架，重要的是要理解该方法背后的原理，以确保采取可持续的规范实践。如果您的团队正在做Scrum，但没有有意识的执行敏捷精益原则，那么结果可能会很慢，而且旅程很长。

end

Nirmaljeet Malhotra is a passionate agile, product, lean and leadership coach. He has been part of multiple small and large agile adoption and transformation journeys and has focused on continually improving his coaching skills to enable organizations succeed with change.

In his present role, Nirmal works Amazon Web Services and is passionately applying agile mindset and principles to cloud adoption.

Nirmal holds a Master’s degree in computer science and many certifications in agile, coaching and leadership. He likes to share his experiences and thoughts through his blog nirmaljeet.com. He is also a frequent speaker at conferences and meetups.

Nirmal can be reached at [e-mail]

译文：Ella Yao

校审：Lance Zhang