Scrum团队中的主要团队成员

在团队成员尝试承担责任的任务最初没有分配给他，而是分配给Scrum Master的情况下，您会怎么做？

Scrum团队是自我组织的，因此可以为占主导地位的人留出空间。其他人应该问他关于他们正在执行的任务的想法，但是必须控制他的主导地位。

你可以做什么：

• 激励他人独立但相互协作-如果您与他们的经理和人力资源合作，这将为他们设定一些期望，并定期进行评估，那么这将是最好的选择。
• 站立，计划和回顾期间；让其他团队成员先发言。在审核期间，让其他团队成员介绍他们实施的用户故事。
• 让其他人先选择任务，以便主导开发人员不能只选择他想做的任务。
• 使对编程涉及一些任务，以便支配团队成员与其他开发人员合作。
• 保持民主-团队成员的意见不足以更改流程-Scrum仅在团队沟通清晰时才起作用，否则您只会互相阻碍。
• 如果以上方法均无济于事，则应与主要团队成员交谈并向他解释情况-但请注意，Scrum中没有团队负责人。如果得到管理层的支持，您也可能威胁到他的工作稳定，但这应该是最后的选择。

如果主导团队成员不想失去统治地位，而被动团队成员不想变得更加主动，则需要他们的经理和人力资源部门的支持。如果管理层不鼓励Scrum流程，则可能会出现问题。

大概是这个问题的原因是因为您觉得团队由于这个支配者而表现不佳。也许是因为团队的其他成员没有贡献100％，原因是什么呢？

作为经理，如果有的话，您有责任确保所有员工都了解他们的角色。具体来说，对它们的期望以及如何对其进行评估。作为Scrum团队的成员，每个人都对团队的成功负有个人责任。因此，这个支配团队的成员需要知道他们没有履行职责，并将对此进行评估。

反馈是关键。如果召开团队会议，并且此人主导了讨论，将他的设计和方法强加给团队的其余成员，并将其余的推入被动角色，则需要直率地和私下告诉他，他没有满足要求的角色。如果您发现他只是偷偷地突出自己的个人成就，那么就需要召集他，并让他了解个人成就的价值远不及帮助团队取得团队成就。

所有这些都很艰难，但这就是经理和Scrum Master的目的。

还有另一种可能的方式来解决此问题。使它成为团队问题。叫他们在一起，告诉他们他们表现不佳，这就是原因。请他们提出解决方案。您可能会感到惊讶。

为什么不问Alpha开发者他的意见。他完全可能不知道自己的影响。把他放在一边，告诉他你的想法。您甚至可以讨论“嘿，您是我们的主要开发人员，但是我们需要将这些人员提升到您的水平，我需要您的帮助来确定我们该如何做？”。将他的统治地位变成资产。看看他是否可以看到这样做的方法。

如果他衡量了自己对团队的支持程度，并将他们提升到自己的水平，那么他将更有动力做到这一点。

您暗示他实际上不是出于团队利益而工作（我想），即他某种程度上是邪恶的，然后是的，将其删除。但是一个聪明人曾经对我说过：当无能或简单无知的可能性更大时，请不要怀有恶意。

看起来他试图成为Scrum Master。

弄清您的立场，并采取相应的行动。

Scrum Master的作用是增强团队合作精神。如果您无法使这个唯一的人成为团队成员，请将其从团队中删除。

快速说明：主导开发人员没有被动开发人员更多的问题。

目前，冲刺计划是一个在团队中轮换的角色

冲刺计划应该让整个团队参与，而不是一次交给一个人。除非有充分的理由，否则我认为这是一个严重的问题。

如果您说的是真实客观的话，那么您将面临一个主要问题：不参与的人和阻止真正敏捷过程的“统治者”。作为管理员，您需要采取行动。也许您想让您的项目经理对这种情况充满信心。

许多团队偏离了敏捷的核心，这是您的工作将它们带回。您需要教导敏捷价值并将其重新融入团队。实际上，您应该不断传授敏捷价值观。展现您对敏捷的愿景，使其清晰而有力。向他们展示您对“敏捷做得好”的承诺。

为此，请引导他们完成敏捷的宣言和Scrum值。问他们合作对他们意味着什么，为什么重要。向他们询问信任在敏捷中的作用。现在是时候讨论为什么在Scrum中没有团队领导角色，没有项目经理角色的时候了，这是整个团队负责开发出色软件的责任，而不是个人的责任。

围绕此计划整个回顾性会议。让他们致力于一些价值观，并在下一次回顾中进行跟进。不要用中性的方法指指点点。

介绍强制其他成员安全发表意见的方法。五个拳头这样简单的事情对于让团队中的沉默者听到是很重要的。很明显，团队不同意主导者。规划扑克效果很好，但关键是之前不允许任何讨论显示牌。任何有助于在不引发冲突的情况下让其他人听到的东西都是有帮助的。

如果一切顺利，那么一切都准备就绪。否则，请与他讨论该问题。使用教练并提出有力的问题，可以帮助他清楚地意识到问题。试图找出他担任主角的根本原因。也许他对团队缺乏信任（为什么？），也许他觉得自己对成功负责（为什么？）。我怀疑这个角色不是他想要的，很可能他希望改变。他可能会过来意识到这一点。

也许“优势”开发者是通过个人表现而不是团队成就来回报的？

过去，我确保通过培养他人的贡献，也能通过他们的目标来奖励那些非常善于表达意见的人。

总的来说，我认为对奖励Scrum成员的个人贡献而不是团队成就的奖励是不好的。

您也可以尝试在团队中为所有团队成员进行360反馈，前提是您认为其他团队成员的意见是真实的。

建议他成为下一个冲刺的Scrum Master。

愿意承担责任的人不是问题（只要他们不想垄断他们），这正是我们希望通过自组织实现的目标。

顺便说一下，具有轮换Scrum主管角色的团队并不少见。

Scrum主管的唯一任务是确保每个人都遵守Scrum图书规则。如果非Scrum管理员可以自己完成此操作而不会受到Scrum管理员的干扰，那只会表明您的状态非常好（Scrum-）！从Scrum的角度来看，Scrum管理员要做的事情越少，您的团队就越有条理和精干。最终，可以/应该取消Scrum管理员的角色，他在那里可以帮助您入门并教您Scrum。

同样，Scrum管理员不参与开发过程。他应该确保所有利益相关者及时就正确的事情进行沟通，他了解Scrum并提供有关Scrum的指导，他不是产品所有者或项目负责人。如果您遇到不同的事情，那么您可能不会以敏捷的精神去做Scrum。当然，在较小的环境中，Scrum master可能是团队成员之一或利益相关者在其中扮演的角色。然后，这只是时候办理手续了。不要将其与领导角色混为一谈，它是指导角色。

拥护个人主义和个人绩效，但也要尝试使被动的个人变得更有参与性。

我的经验表明，尽管乍看之下它们看起来很相似，但共产主义和敏捷并不相同。敏捷不是针对无阶级社会（团队），而是针对有效的软件。

尝试使您的Alpha开发人员了解他可以通过要求和指导而不是总是首先回答并取得个人成就来帮助您发展其他技能。您的Alpha开发人员肯定是在乎优质软件的开发人员，这是您自己不会丢掉的东西。