Scrum Master的成功定义是什么?-InfoQ

今天是你的第一天。这可能不是你第一次担任 Scrum Master 的角色了，但今天却不同。你面对的是一个新的团队、新的组织。以及面对完全不同的、一系列的挑战。

你曾做过这个工作，但并不处在这个环境，不是与这个团队、与这个组织合作。那么你怎样调整呢？如何接受新团队的挑战呢？从过去的经验中，你可以使用什么工具来帮助你在这个环境中获取成功呢？你对过去使用的工具都有所记录，不是吗？

我们都曾经、或者以后会在这样类似的处境下。作为 Scrum Master，如果我们想获得成功，必须针对合作的不同团队和组织创建自身的方法。幸运的是，我们不需要独自创建那些方法并设计 Scrum Master 工具。我们有很多有用的外部资源，可以帮助我们创建自己的 Scrum Master 工具箱。从优秀的实践书籍，如 Jurgen Appelo 的《 Workout 》，到经典的诸如DeMarco 与Lister 编写的《 Peopleware 》，再到更侧重教练的书籍，例如Lyssa Adkins 编写的《如何构建敏捷项目管理团队》。但是学习的最好方式就是与很多的、有不同经验的Scrum Master 们交谈。从经验的多样化中，我们可以构建出自己的方法，并且通过尝试不同的方法获取灵感，直到找到适合特定环境的方法。

大量的多样化的方法是Scrum Master 的一个关键资源，因为他们不会一遍又一遍地面对同样的情况，而是几乎每天都会面临新的情况。在有一个新成员加入后参加每日例会；或者在一次失败的演示之后立刻规划Sprint，我们需要访问深度工具箱，想出创新和有参与度的实践、技术以及方法来帮助团队和组织获得成功。

为了帮助Scrum Master 们创建自己的方法，我们在 Scrum Master 工具箱播客中收集了很多不同的观点，并且在这里整理了一部分供大家以后阅读和参考。下面你会找到具有15 款工具和方法的一个列表，供全世界的Scrum Master 们使用。经验丰富的Scrum Master 们解释了他们如何定义和衡量自己作为Scrum Master 的成功，并分享了有关如何获得成功的经验教训。从处理干系人，到如何改进教练技能，再到如何帮助团队达到可持续发展的步伐。下面分享的内容来自多年的经验教训，将有助于你改善Scrum Master 的表现。

我们也添加了一些说明和警告，你必须要考虑一下。这个目的是：帮助你成为一名成功的Scrum Master。

让我们开始。

来自经验丰富的Scrum Master 们最重要的经验教训

首先，你如何衡量成功？经验丰富的Scrum Master 们分享的最常见的经验教训就是：要获得成功，首先必须要定义成功，然后在衡量你的方法。每一名Scrum Master 做的方式都会有点不同，但是他们都这样做了。下面就是一些具体的例子与问题，可以用来衡量自己作为Scrum Master 的成功。

1.定义衡量自身成功的方法，然后跟踪自己的发展计划，就像遵循团队发展那样。 Jeff Kosciejew 列出了三个问题，他根据这些问题来评估自身的成功：

团队在这个 Sprint 是否交付了准备好的软件产品？
每个人是否都满意、或骄傲于他们取得的成果？
我们是否改进了工作方式（例如我们是否比上个 Sprint 交付了更多的价值？）

Scrum Master 拥有自己的问题，这种方法似乎在其他 Scrum Master 们中也很流行。 Dominic Krimmer 创建了自己的清单来评估他作为 Scrum Master 的表现：

是否有团队愿景？
是否有清晰定义的 Sprint 目标或者关注点？
Scrum 板是否及时更新，使工作可见并透明。
是否有控制面板，用来沟通产品的状态？
用户故事的质量是否好？

最终 Stefano Porro 推荐了另一个问题列表：

团队，或者团队成员是否觉得他们的贡献是有价值的，并认为是很重要的？
团队工作在这个项目上是否开心？
如果给团队一个选择，他们是否还想在以后让你继续承担 Scrum Master 的角色并与你一起合作？
每日站会的“参与指数”是否在正常水平?(参与指数 = 影响团队工作的非请求干预数量。)

你用什么问题来衡量成功并不重要，重要的是你有自己的问题列表，或者是清单，你可以定期地跟踪，从而帮助你专注在正确的话题上，这些话题是作为 Scrum Master 需要发展技能的方面。就像 Andy Deighton 说的：首先你可能会忽视成功的定义，但迟早你会需要一个指南、一种方式来衡量你作为专业Scrum Maser 的个人发展。问问你自己：作为专业的Scrum Master，你是否忽视了成功？

最常见的Scrum Master 成功定义以及如何实现

我很高兴你会问：作为Scrum Master，在工作中成功的结果最常见的表象是什么？目前为止，从播客的三十多名受访者中列出的最常见的成功定义是：团队“拥有”流程。这有许多不同的形式，从团队控制Scrum 流程中的会议或者仪式，到团队积极与组织的其他团队或干系人联系。Scrum Master 的难题是：我们如何帮助团队“拥有”这个过程？这有一些由经验丰富Scrum Master 们列出的一些工具：

2.离开几天，并且评估团队控制流程和会议的效果如何。 Matt Dominici 提出了这一想法，他告诉我们控制权的水平只有在你离开的时候才能看到。如果你几天后回来发现团队迷失了，并且抛弃了过程，这就是一个清晰的信号，团队并没有准备好去“拥有”这个过程。但不要气馁，这个工具还是有用的，因为当你回来的时候，你可以评估丢失了什么，或者团队哪部分没有做好，并且集中关注在那些话题上进行指导。例如，如果你回来发现团队放弃了变化部分的测试，那么你就知道仍然需要帮助团队理解那部分的工作，或者缺少工具帮他们将测试整合到日常工作中。

3.关注于为团队定义和提供平台上。Jeff Kosciejew 基于音乐玩家的经验解释，乐器（或角色）提供正确的条件与环境使得其他人得以成功。他把团队的构建称之为“平台”。Scrum Master 一定是一样的，所以 Scrum Master 的一个重要特征就是，在当时的背景下，从容地担任支持与启用的角色。每个不同的仪式都需要不同的方法来创建这个平台。例如，在每日站会上，你只需要简单地走出圈外。当团队正在讨论他们相关的工作时就退到后面，并且在他们需要你的帮助时，或者引导会议中必须要干涉时再介入。这种身体的撤退有助于团队意识到你在那里支持他们，而且鼓励他们拥有会议的自主权。

Scrum Master 们最常用的工具

每个人心中都有这样一个问题：世界各地的 Scrum Master 们最常使用的工具是什么。毋庸置疑，根据你自身的经验会有自己的想法。但是这个问题的答案让我有点吃惊…

4.有很多一对一谈话，并做记录。起初听起来很简单，在我们采访的 Scrum Master 们中，交谈是最常用的工具。Matt Dominici 解释了他如何使用谈话作为首选工具，了解影响团队的是什么，例如用它来作为衡量团队幸福的工具。对话是一款足够简单的工具，但却经常被遗忘和使用。改善对话技巧的一种方式是阅读 Dale Carnegie 编写的《如何赢得朋友并影响他人》，作者列出了你必须记住的清晰列表，可以增进与你每日合作的人的关系。Carnegie 建议：总是先谈论对方关心的内容；以他们的视角了解他们真正感兴趣的是什么；不要一开始就争论，这样你无法赢得他们。在另一篇文章中， Tim Bourguignon 提醒我们必须记下正在进行中的所有想法，并记录每一次的谈话，这是一种很好的方式，记住你理解的内容，并从容地管理你与合作人的关系。

都是关于为什么

5. 帮助团队定义他们的目标，团队才会发现他们自身对成功的定义。 Luis Gonçalves 提醒我们，拥有清晰的目标是积极主动与成功的关键之一。没有共同的目标，团队无法一致行动。在播客中，Luis 建议为我们合作的团队举办一个特定的工作坊，帮助他们定义团队的目标。这个工作坊是受Daniel Pink 书中所启发，你可以在《Drive: The Surprising Truth About What Motivates Us 》中阅读更多内容。

6. “为什么”定义了成功，开始之前始终询问为什么。在同样的思想上，Stefano Porro 提醒我们在开始之前询问“为什么”的重要性。Stefano 给我们讲了一个故事，团队失败了，因为他们只关注“如何”，并且他们在工作中从未考虑过“为什么”。Stefano 根据这个经验改变了他担任 Scrum Master 的方法，现在经常问“为什么”，从而确保他和团队理解这项工作的原因。只有知道了为什么做，我们才能更好地做我们要做的，并且作为 Scrum Master，我们必须确保这个团队绩效的根本推动者是明确的。

教练立场

**7.学会辅导团队是Scrum Master**最重要的旅程之一。如果团队不成功，就不会有成功的 Scrum Master，因此我们必须学会与团队合作。与团队合作意味着我们不断地支持团队，而不是替他们工作，为他们解决自身的问题，更不是替他们开会。因此教练立场也是Scrum Master 工作关键的一个方面。在奖金的章节中， Bob Marshall 介绍了《非暴力沟通（Nonviolent Communication (NVC)) 》，这种方法有助于Scrum Master 用具体的工具来帮助与团队交互。NVC 要求我们接受的是，不能强迫任何人做任何事情，否则我们必须确保做事情的原因是清楚的，并且是被接受的。NVC 对每一名Scrum Master 在教练方面都是很好的激发和引导。

8.过去合作的团队与你未来合作的团队并不相同；针对团队发展阶段调整实践。每个团队都是在不断发展中的。我们与团队合作的方式也必须要演变，得以适应团队发展的阶段。Dominic Krimme 提醒我们布鲁斯 - 塔克曼团队发展模型中已知的阶段：形成阶段、震荡阶段、规划阶段、成熟阶段。动态地解释了每一阶段的方法，以及为什么这个配方不能用于所有阶段。理解团队现处于哪个阶段，以及这一阶段的正确方法是什么，这是Scrum Master 一项关键的技能。

9.教练行为发生在认同者之间，在开始之前要征求同意。本着 NVC 的精神，我们不能强迫团队接受被指导。教练需要征得所有参与人员的同意。 Steve Holyer 要求我们在开始做 Scrum Master 工作之前，与团队设计我们的教练联盟。如果他们仍然承诺最初的约定，有了共同的目标和一系列的期望，后面你就可以要求团队，并且提醒他们这是在参与初期大家明确认同的约定。这是获得许可的一个非常具体的方式，并且当后期形势紧张时重新获得他们的认同。这种教练联盟是你与团队的“合约”，并有助于你让团队重新调整团队整体的工作目标。

衡量一切

衡量成功意味着要衡量。并且 Tim Bourguignon 对此很认真：

10. 衡量一切，并记录一切。Tim Bourguignon 解释说作为 Scrum Master 我们受益于衡量“一切”，并且保持我们所能做到的任何度量。这样我们可以过后查看整个趋势。下面告诉你如何开始：

开始记录所有的事情。在会议中、在讨论过后，始终记录。
衡量你所能衡量的：完成的任务、周期、功能、迭代等等。
作为 Scrum Master，要得到所有的数据。这你周与每名团队成员交谈了几次？有几次你感觉到迷茫，或不知道如何进行？
查看趋势。只有数字可以帮你查看趋势。衡量并退后一步查看大的方向。

尽管一开始可能会让人感到畏惧，但你不必开始就做所有的度量。而是观察你的环境，来定义你想要跟踪的、可以更好理解情况的 3 个度量。用下一个回顾作为衡量的触发器。考虑哪一个话题想要带到回顾上讨论（或者问团队他们想要讨论哪个话题），然后保持与特定话题相关的度量。这样你就可以开始，并且会有短期的回报；在下一次回顾你就会获得所需要的信息。

11.观察指标，它会向你显示“系统”的表现行为，因此你可以帮助团队理解他们的情况。我们的团队处于特定的环境中。他们受企业的政策、使用的技术、交互的其他团队以及组织文化的影响。衡量局部的指标不会帮助你理解整个系统的行为。这就是为什么 Neil Killick 建议你查看系统指标，例如精益指标中的周期时间与前置时间。前置时间有助于你理解需求或用户故事在系统中花费的时间，而周期时间有助于你理解从团队开始工作到交付用户故事所使用的时间。这有一个具体的例子说明这些指标如何使用：如果团队A 在开始的Sprint 中完成了所有的用户故事，但是故事的前置时间很长（我们说几个月），你就知道应该关注于理解是什么原因使得用户故事没有到达团队这里（如果这个延迟是在Sprint 开始之前），或者关注于理解为什么用户故事在上线之前存留这么久（如果这个延迟是在用户故事做完之后）。在一个案例中，我合作的一个团队用户故事的平均周期是几周，但是前置时间长达数月。这些度量帮助客户理解了，当开发团队完成用户故事的开发后，必须减少等待测试的时间。

所有都是可持续发展步伐

Scrum 强调的是工作的可持续步伐。在软件开发界，经常听到的一句是“软件开发是一场马拉松而不是一个冲刺。”Scrum 就采用了这样的方法，团队的目标之一就是找到可持续发展步伐。但是，作为 Scrum Master，怎么知道团队的工作是可持续发展的步伐呢？此问题有多个答案。其中一个最通用的答案是应该衡量团队的幸福指数。

12.衡量团队的幸福指数来评估可持续性。 Andy Deighton 在播客上推荐了几款可以衡量幸福指数的工具。旅行路线图（Journey Lines）就是一款这样的工具，你可以用在回顾会议上，从个人或团队的视角对一个冲刺或更长时间（例如一个项目）进行评估。另外一款衡量团队幸福的工具是幸福之门（Happiness Door ），这款工具结合了其他的几个以衡量幸福指数为目的的工具。你还可以将该技术用于衡量发生的特定事件给团队带来的影响，例如在规划会议之后、评审会议之后，或者与干系人开完会之后等等。幸福门是一款更加实时的工具，及时地帮助团队反思和应对在特定点发生的事情。还有其他一些衡量幸福指数的方法，并且在其他方面也会影响工作的可持续性，在本文中的这一想法是说，作为（缺乏）可持续性的症状，你可以衡量幸福指数，以及对影响团队的特定话题或事件使用该方法。

最终，我们必须产生价值才能继续玩游戏

Alistair Cockburn 在他畅销书《敏捷软件开发，合作游戏》中介绍了他的思想，软件开发就是一场“无限的，合作游戏”。用Alistair 声称的游戏理论来说，软件开发在一个项目中、或一次交付中并没有终点，而团队的目标就是“准备下一场运动”，因此他们可以继续玩软件开发的游戏。在实践中，这意味着不管我们现在做的有多成功，我们必须继续开发有价值的软件，解决客户和用户的真正问题，以能够继续玩这个游戏。

13.成功就是生产一些有价值的东西，帮助团队衡量生产的价值。很有可能的情况是，用增量的方式生产高质量的软件，却没有产生任何价值。 Antti Tevanlinna 在文中描述了一个经验教训的事实，他从中明白了：不管你生产的软件有多好，最终产品在市场上的成功界定了软件开发的成功。作为Scrum Master 我们必须能够帮助团队理解他们生产的东西是否有价值。我们可以通过让产品负责人与团队和客户沟通来定义和校验制造软件的价值。询问客户（或者客户代表）有关生产软件的价值是我们可以使用的一种方法，但并不总是可行的，所以Scrum Master 必须积极地与团队和产品负责人合作，定义方法来衡量团队交付软件的价值。如果你想了解更多有关如何做到这一点的内容，那么精益创业社区中正在讨论这些方法，可以作为很好的开始。

14. Scrum对价值定义有特定的描述，明智使用它。Antti Tevanlinna 也提出了一个警告，在 Scrum 中，价值的定义“隐藏”在待办目录中。如果团队不熟悉待办目录，那么他们创造软件的愿景也就被隐藏起来。团队了解了他们必须工作的用户故事是不够的，他们还必须了解故事的上下文。一些简单的问题例如“有了这个用户故事，用户想要实现什么？”，这有助于团队理解为什么实现这一特定功能的原因。理解要实现用户故事的“为什么”，对团队制作最好的产品是至关重要的。作为 Scrum Master，我们必须保证团队和产品负责人定期讨论故事的“为什么”，并且对他们制造软件的愿景达成一致。只有那样，我们才能保证价值不会被待办目录或产品负责人的思想所隐藏，而是可以被团队理解和共享的。

敏捷就是管理（或者缩短）反馈周期

Scrum 是敏捷的一种方法，特别强调反馈周期的长度。它要求我们定义一个时间盒（Sprint），即一个完整的开发周期，从挖掘需求到发布产品。强调这个的原因是，在周期最后，我们得到反馈，这样可以使团队持续改进。但 Sprint 并不是唯一的反馈循环。作为 Scrum Master，你要弄清并管理很多的反馈循环。

15.Scrum Master**** 最关键的工具是反馈循环 ；定义并让他们的周期尽量更短。Antti Tevanlinna 提到，尤其是客户参与的反馈循环对团队至关重要。作为 Scrum Master，我们必须理解团队需要什么类型的反馈才能做好他们的工作，并且让这一反馈发生。其中一个基本的反馈循环就是评审会议，团队演示他们完成的功能，从干系人那里收集反馈，不仅是功能性的，而且是工作方式方面的。成功的 Scrum Master 需要确保反馈循环足够快（1-2 周是好的循环），而且有效。准备特定的方式来收集和处理反馈，这会保证收到的反馈是开放的，而不被认为是反对的（当有负面的反馈时），或者无关的。请记住，反馈都是有价值的，只是团队最后选择如何回应（或者不回应）反馈而已。

结论

当团队最终“拥有”这个过程，Scrum Master 的工作看起来就结束了，但并非如此。一旦团队“拥有”这个过程，我们必须将关注重心转移到团队动态、组织障碍、与干系人交互上等等。通过采访 30 位 Scrum Master 工具箱播客中的人，我了解到的是 Scrum Master 成功的定义非常广泛，不同的人注重不同的方面。不仅如此，而且就团队和组织变革来说，我们也必须关注在不同的方面。然而在收集过去 6 个月采访的答案上，有一个共同的趋势，我们看到了 Scrum Master 的成功有两个主要的定义：作为团队帮助团队成功，以及作为业务帮助组织成功。

这两方面的成功定义，对我们理解 Scrum Master 的角色都是有效和关键的。我们必须在这些维度上不断地评估我们的工作，并帮助团队和干系人理解这两个维度。在定制对自己的成功定义时确保考虑这两个因素。

这有一个挑战：作为 Scrum Master 制定你自己的成功定义并写在下面的评论中。在接下来的 4 周衡量你的表现，然后回来，发布这四周来演化的结果和问题。当你回来的时候分享一下使用什么工具和实践来评估 Scrum Master 的成功。让我们持续构建我们的专业知识。这是一个年轻的行业，但注定在当前是很重要的，因为到处都在运行软件。Scrum Master 社区也期待你的想法和见解。

关于作者

Vasco Duarte 通过关注产品开发团队，产品的端到端生命周期，致力于将产品开发组织转型到产品业务组织。Vasco 目前是 Oikosofy 的执行合伙人。产品经理、Scrum Master、项目经理、总监、敏捷教练只是他在软件开发组织中承担的部分角色。Vasco 在 1997 年就开始在软件行业工作，并且从 2004 年成为敏捷实践者。他也曾作为组织敏捷转型的敏捷教练或领袖，在小型企业、中型企业和大型企业工作。他还曾是 Avira、诺基亚和 F-Secure 公司敏捷组织和敏捷文化转型的一名领导及催化师。