ScrumMaster可以炒人吗？

敏捷是用来交付复杂产品的一种简单但有效的框架。它不是通用性的解决方案，也不是什么高招，更不是复杂的方法论。相反，敏捷为团队可以自组织地用经验解决复杂问题提供了最小边界。这种简单性是它最大的优点，但也造成围绕“敏捷”一词的许多误解和谬论。在这个帖子系列中，我们——你们的“流言终结者”Christiaan Verwijs和Barry Overeem——将阐述最常见的流言和误解。

 

 

以一个案例开始

 

 “所以Tim决定不再加入了吗？”一个沮丧的很明显的开发人员在参加每日站会时问到。那些在场的人耸着肩长吁短叹。“即使谈过需求之后，我们也要公开分享进展吗？””另一个开发人员补充问道，紧张显而易见。Tim至今快2个月没有参加每日站会，将时间花在了“非常重要的事情”上。Tim更喜欢用站会时间来写代码。但是，除了他在迭代结束时所做的众多承诺——通常会被别人撤销——没有人真正知道他实际上在做什么。开发团队在迭代回顾时数次提出这个问题，没能解决。团队的敏捷教练Tess已经在多个场合和Tim谈到这个问题，试图找到Tim的秘密。尽管聊的很好，也没能改变任何。团队渐渐厌倦了这种对抗。士气下降，而且因为Tim所做工作的以及给迭代带来何种影响的不确定性，团队越来越犹豫是否要实现迭代目标。在尝试很多不同方法针对这种情景却没能成功后，Tess决定把Tim从敏捷组挪走。

 

 

 

这个案例展示了在敏捷小组自组织的本质和使敏捷为团队和更广泛的组织工作之间的平衡。我们描述的案例仅仅是艰难决策的一个代表。

 

当被问起敏捷教练是否可以从团队移走任何人时，大多数人会响亮的回答“不”。它形成了团队里的等级，会伤害信任的氛围和开发团队的自组织本性。本文会基于上述案例，探讨敏捷教练要成为“服务型领导”意味着什么。

 

 

 

Scrum指南怎么说？

 

Scrum指南并没有明确指出敏捷教练可以从团队中删除某人。但是它确实强调了几个相关的职责：

• 敏捷教练负责如Scrum指南中定义般在团队和更广泛的组织中促进和支持敏捷；

• 作为服务型领导，敏捷教练帮助创造使团队有效敏捷工作的环境；

• 敏捷教练负责清除会妨碍开发团队前进的障碍。许多事情都可能成为障碍，从坏了的电脑到团队冲突，从计划中断到缺乏技能。但是他或她自己应该关注会危害迭代目标或是开发团队不能自己解决的障碍。更宽泛点说，敏捷教练尝试清除或解决会妨碍团队有效敏捷的工作的一切障碍（也就是整个组织）。

 

 

从另一方面来看敏捷教练作为服务型领导，通过设置和维持游戏规则，给玩家提供尽可能有效地玩游戏的自由和支持。尽管Scrum Master做了所有的事情来帮助人们在游戏中发挥最大的作用，但他或她的主要职责是确保游戏的正确运行。移植到产品开发上来，意味着这是在关于有价值的产品交付中，逐步学习并让更好的观点涌现。

 

清除障碍——任何阻碍游戏顺利进行的障碍——敏捷教练责任之一。所以现在问题变成：敏捷团队的成员有可能成为障碍吗？

 

敏捷团队的成员有可能变成障碍吗？

 

 

如果人变成了障碍？

 

虽然我们并不乐于给人贴上“障碍”的标签，但现实是人的确有可能妨碍敏捷的有效性。比如这些例子：

• 像案例中的，开发人员紧紧守着自己所有的“秘密”，不公开工作内容、进展如何或是其他人能如何帮助。无论他在做什么，没人真正知道。明显是因为这个开发者没有看到每日站会的价值也从不参加；

• 一个开发人员经常在晚上的时候单方面地扔掉团队编写的代码，用她认为比团队所产生的代码更好的代码来替代它——尽管开发团队越来越不满;

• 一名开发人员不放过任何一个机会来表达他对Scrum的不满，在各种敏捷活动中触发激烈的争论，并不顾他人的意愿把注意力从手头的事情上转移出去（“我们又来了……”）;

• 一名开发人员利用她的资历，不断地批评他人的工作，当她在房间里时总是会让别人感到不安

这些例子本身并没有充分的理由将某人从团队中剔除。但是，如果同时出现了下列情况呢？

• 这种情况已经持续了一段时间，并且没有改善的期望

• 开发团队很清楚并且也不喜欢这种状况，迭代回顾会上已有几次关于它的对话。但却未能将改变的意愿付诸行动。团队害怕采取措施，觉得不是他们的责任也没有勇气去做一个太冲突的决定比如从队伍里剔除掉某些人

• Scrum Master已经与该成员进行多次谈话，来帮助他们意识到他们对团队的影响;

 

 

换句话说，有一个未解决的冲突正在损害Scrum团队的功能。考虑到了有这种冲突，一个Scrum Master却什么都不做，等待团队自己做出决定，这真的是合理的吗？如果每个人都清楚这是行不通的，而且它影响了团队的运作，那么Scrum Master就会是一个合适的人——作为一个服务领导者——介入并做需要做的事情——不管多么困难。

 

 

一个Scrum Master什么都不做等待团队自己做出决定，这真的合理吗？

 

 

 

对信任的影响？

 

一个常见的反对意见是，从团队中移除人员会损害信任。当人们知道Scrum Master可以采取这样的行动时，他们又会如何感到安全呢？

 

这个论点假设从一开始就有一个“信任的环境”可以被破坏。但是，如果一个团队正在处理一场未解决的冲突——就像前面提到的例子一样——已经有很多事情正在发生，它们正在极大地损害信任。更有可能的是，这个团队在“人工和谐”的状态下生存——一种不太健康的现状。如下列信任的环境为例，是否会出现在前面提到的有冲突的团队中？

• 进行艰难的对话而不用担心报复;

• 对某件事持批评态度或持怀疑态度，而不用担心遭到报复或被取笑;

• 在没有受到指责或惩罚的情况下犯错误;

• 依靠团队中的其他人来帮助你，当你陷入困境时;

• 可以“深情地战斗”（进行一场激烈的辩论，而不影响相关人员之间的关系）;

• 承认你不知道某件事，或者害怕它，而不用担心后果;

• 依靠人们所说的是他们真正的想法（例如，不是表面的）;

 

如果你仔细阅读字里行间，不难发现这些行为与缺乏透明度、检查和适应联系起来——都是关于Scrum的核心原则，也是Scrum Master要保护的核心。

 

那么相反的情况更有可能是真的吗？与其损耗信任，不如将一个成员从团队中移除，这将有助于恢复信任。在团队动力方面，它为团队创造了空间，让他们找到更有效的协作方式。而Scrum Master也证明了他或她愿意做出这样一个艰难的决定，比如为了团队的利益而移除某人。移除可能是帮助恢复信任的强大信号，而不是减少信任。

 

与其损耗信任，不如将一个成员从团队中移除，这将有助于恢复信任。

 

 

为什么不把决定权转交给HR或管理层呢？

 

在这篇文章中，对这个难题的一个常见的回应是将决策委托给团队之外的一些成员，比如人力资源或管理层，让他们根据呈现出来的证据做决定。然而，这种方法揭示了在Scrum中关于管理角色的传统观念的持续存在。

 

为了有效地与Scrum合作，Scrum指南只规定了三个角色：一个产品负责人、一个Scrum Master和一个开发团队。这三种角色共同拥有了完全的职责可以作为一个团队来决定产品开发和他们的内部过程。尽管管理层当然可以参与其中，但他们并不是做出决定的人。如果他们想替团队做决定，这将破坏Scrum团队的自组织特性，并释放出一种决定开发和内部流程的权力并不真正属于Scrum团队。他们如果拥有或想要决定意味着团队并不是真正的自组织。记住，将某人从团队中移走并不意味着被解雇。他们很有可能在另一个团队或公司的另一个职位上有很大的价值——仅仅是在这个团队中没有。

 

记住，将某人从团队中移走并不意味着被解雇。

 

 

怎样从敏捷小组踢人？

 

将某人从团队中移除是一个艰难的决定，而且确实应该是最后的手段。Scrum Master应该尽一切可能帮助解决冲突。但如果其他方法都失败了，移除是一个可行的选择。尽管从团队中移除某人肯定没有“最好的方法”，但以下是一些基于我们的经验给Scrum Master的参考：

• 确保被质疑的人已经有足够的机会改进。因此，这一决定不应完全出乎意料;

• 诚实地说出将某人从团队剔除的原因；

• 不要当着团队所有人在场时宣布这个决定，私下找到他宣布这个决定。待人友好，有同情心，但坚定而坚决。花足够的时间给这个人一个机会去回应，问他们脑子里想的是什么; 

• 确保你在决策过程中涉及必要的人员和部门（比如人力资源管理部门），同时还要控制你作为Scrum管理者所做的决定; 

• 不要把它变成个人的，不要用个人理由来证明这一点。坚持正确的事实，或者（至少）由团队中的大多数人分享; 

• 一起决定从此时如何开始。根据当下情况，成员可能希望马上离开。但他们也可能更愿意完成当前的冲刺。无论哪种情况，确保在决定后的几天内与此人有跟进;

• 在作出决定后，与开发团队分享。让他们有机会回应并反思所发生的一切。这也许是一个放松的时刻，但也可能是关于如何在未来如何预防这一问题的艰难对话;

• 不要表现得冷漠和强硬。公开表明这对你来说不是一个容易的决定，但因为对团队有好处所以是必要的;

• 将某人从一个团队中剔除是很困难的——特别是对于被移除的人来说。要格外尊重和同情;

• 不要向别人吹嘘你是如何从团队中移除某人的，或者你是如何挺身而出，做了一些困难的事情。对被你移除的人，以及需要的情况，给予最大的尊重。把某人从团队中剔除不是什么值得骄傲的事情。

 

 

如果是产品负责人呢？

 

我们认为，这篇文章中提到的所有要点也适用于产品负责人。针对产品负责人可以通过多种方式参与到游戏中来：

• 产品负责人不愿意或者不能充分为开发团队澄清需求并确定需要构建哪些内容;

• 产品负责人没有授权或完全缺乏产品愿景来对产品做出任何决定，使得快速检查和适应变得非常困难;

• 产品负责人正在创造一种不适合敏捷的氛围，例如，将重点放在承诺和控制上。

 

如果所有其他的解决方案都失败了，那么Scrum Master的最后一招就是用更适合这个角色的组织内部或外部的人来代替产品负责人。如果这个人找不到，那么敏捷的价值就会降低到所有人会怀疑它是否有用的程度。这再次强调了Scrum Master有多么需要管理的授权。

 

 

关于文化差异的一点建议

 

每一种文化在处理人际冲突和信任方面都是不同的。作为作者，我们的观点深受荷兰文化的影响，在这种文化中，直率、开放和不受拐弯抹角的影响是有价值的。但其他文化看重的是不同的东西，比如为群体挽回面子或做出个人牺牲。无论在哪种文化中工作，Scrum Master仍然主要负责帮助团队有效地与Scrum合作。如果有人妨碍了（比如从结构上），他们就应该做点什么了。但是，作为一个Scrum Master，你所做的事情应该是在你所被影响的文化价值观范围内的。

 

无论在哪种文化中工作，Scrum Master仍然主要负责帮助团队有效地与Scrum合作。

 

 

关于精神障碍的一点建议

 

在指导健康的个人和帮助有严重的精神障碍的人们（如抑郁、成瘾、精疲力竭）之间存在着巨大的差异。不管多么诱人，把这个留给专业人士吧。作为一个Scrum Master，你应该做的一件事就是让自己认识到这些疾病的症状。当你看到这些症状出现在一个团队中，为有问题的人提供专业的帮助。

 

将严重的精神障碍（如抑郁、成瘾、精疲力竭）留给专业人士。

 

 

 

结语

 

我们认为如果有人成为团队实施敏捷的障碍，敏捷教练就有权请他们离开团队。敏捷教练的第一个责任就是确保敏捷为团队和更广泛的组织工作。这个责任赋予了他能踢人的权力。显然，这个艰难的决定不可能会轻松。在这个帖子中，我们分享了在哪些情况下踢人是可选项的一些观点，以及最佳方式的建议。

 

你认为这篇文章怎么样呢？你也曾经历过团队成员被敏捷教练从组里移走吗？后来又发生了什么呢？