作为Scrum Master的开发经理有哪些不利条件？

人们普遍认为，团队经理不应该是Scrum的主人，但是我在努力地寻找原因。对于上下文，我是一个Scrum团队中的4个开发人员的应用程序开发经理。我来自Scrum Master的背景，并向组织介绍了Scrum。我从头开始建立了团队，并明确表示我所做的一切都是为了促进团队的工作，并且他们会做出决定。作为一个团队，我们非常开放-他们甚至在站立时让我沉默了一段时间，以消除我们开始获得的“报告”感觉。缺乏开放性通常是反对经理作为Scrum Master的最大理由，但处理得当，可以通过正确的文化轻松克服。

经验丰富的Scrum教练已警告过我，这是一种危险的情况，并且存在“万一情况不佳”的风险。我认为两个职位不会冲突，在这两个角色中，我对团队和个人的目标都是相同的。Scrum解决了团队内部的冲突，该冲突传统上可以是经理角色。冲刺的自我管理性质消除了经理传统上要做的工作分配。

作为开发经理，我真正剩下的就是确保满足个人需求，职业目标，工作场所等。我每周都会与每个团队成员进行交流，以提出任何问题并处理任何管理任务。其中很多与团队直接相关，或者与我作为Scrum Master的角色直接相关。

我知道在大型组织中这是如何难以管理的，并且是一个单独的角色，但是对于小型组织，我们当然不能为另一个Scrum Master或Development Manager辩护。

请告知我开发经理作为Scrum Master的陷阱，不包括我上面提出的和已经克服的要点。

本质上，您存在利益冲突。经理的工作是按时完成任务。Scrum管理员的工作是确保估计尽可能准确，并以可持续的速度进行。经理倾向于希望将更多的工作纳入冲刺中，而Scrum主管则倾向于希望可以现实完成的金额，而不受外部截止日期的影响。尽管一个好的经理可以平衡这种冲突，但是将工作分配给两个人要容易得多。经理通常更适合担任产品所有者的角色。

如果您的团队中没有人熟悉它，那么担任Scrum Master并没有错，但是如果您在几个月后交出该职位，您的团队将会看到好处。将角色视为同级角色很重要。甚至是非管理Scrum主管也经常会在一段时间后轮换出来，因为团队开始对他们像经理一样对待。

我相信主要的问题是，作为经理，您有权告诉团队该怎么做。Scrum主管除了执行Scrum原则外没有此权限。

这是什么意思？管理者的输入将隐含更多的权重。您可能不是故意想要或不想这么做，但是最终，您的团队成员的职业和薪水在某种程度上取决于您。他们知道。这污染了这种关系。

你还能做吗？当然。您只需要非常努力就可以证明自己是仆人领导，并且自上而下不会飞。

我实际上已经看到，当“技术经理”过多地参与项目的日常工作时，会发生什么事情，这不是一件很漂亮的事情。在我们的案例中，所讨论的经理不是 Scrum 管理员，而是试图通过某些决策。如果我们实际上没有一个单独的Scrum Master来进行防守，那将更加痛苦。

（顺便说一句，这不是我的经理，所以我在这一点上很客观。）

我将介绍我认为是主要的利益冲突；如果您认为以上任何一种都不适合您的情况，那么也许您可以两者都做。但是请确保您定期重新检查这些假设，以确保您不会陷入以下任何陷阱：

1. 技术经理通常负责多个团队中的特定角色。如果只有一个团队，那么它更像是“领导”而不是“经理”。责任的分散意味着与团队的时间减少，与项目/产品的时间减少，并且倾向于导致“即时运行”样式管理。

2. 技术经理对企业负有许多其他管理职责。他们需要进行辅导/培训，绩效评估，面试/招聘，长期基础设施/资源规划等。它本身可以很容易地成为一个全职工作，并且几乎没有花在促进工作上的钱。

3. 繁忙的日程安排也可以强加于团队。技术经理可能需要（或希望）在团队认为不合时宜的时候将团队成员拉进会议。管理和尝试消除干扰通常是Scrum管理员的工作，但是当您有自己的时间表要担心时，不可能客观地做到这一点。Scrum主管很少需要与团队成员单独开会，因为所有这些会议都已经预先安排好了（站立，回顾等）。

4. 技术经理必须处理跨领域的项目问题，他们的自然冲动将是试图使一切标准化—库，源代码控制，算法，布局，颜色等等。尽管这实际上对公司来说是一件好事，但最终没有人去挑战团队想要做的事情，他们可能有很好的理由想做一些不同的事情。这与Scrum和类似方法背后的“持续改进”理念背道而驰。

5. 在其管理角色中具有专家背景的管理人员将对如何完成工作以及需要多长时间有自己的强烈想法。作为一名经理，这不是一件坏事，但是作为一名Scrum 管理员，这通常意味着将团队成员偏向于他们本来不会同意的设计或估计中-并且他们可能比您对当前的问题了解更多。

6. 团队成员总是很难区分请求和订单。他们不会告诉您这一点，甚至自己也可能不会意识到。即使您清楚地表明，在他们的脑海中，您只是在问而不是在说，您仍然是他们的经理，并且在职业层面上冒险说“不”。这可能是所有问题中最隐蔽的，因为您无能为力 -只是他们的态度而不是您的态度很重要。

如果您确定自己永远不会陷入任何陷阱，那就去做...但是我重复一遍，请确保您经常与您的团队（以及其他团队/经理！）交谈来验证您的假设。并确保它们不会以您可能不会注意到的微妙或无意识的方式发生。

在积极的方面，我要补充一点，即您认为这个问题足够重要，可以实际提出问题，这意味着您可能在两个职位上都相当出色。无论如何，关心团队，而不仅仅是您自己的职业野心，可能占良好管理的一半以上。

......但两者都是好并不一定意味着你可以在既有良好的同时，所有的时间。请注意这一点。

这不是宗教，Scrum的规则也不是教条。如果曾经有过合并HR经理/ Srum Master职位的案例，那您做得很好。请注意您提到的陷阱，但是永远不会有一套完全适合每种情况的规则。

如果您的团队对您同时担任这两个角色感到满意，那么就没有理由仅仅为了符合书中的规定而进行调整。

我看到的最大问题是团队中与您（经理）有关的问题。如果他们是初级或缺乏信心，他们可能会害怕在回顾中大声疾呼。这可能会限制回顾的有效性。当经理在场时，许多人都会害怕说“我觉得经理不现实”。

因此，也许您可​​以通过追溯来解决这个问题。现在，您的团队在没有Scrum Master的情况下进行回顾，这也有可能限制回顾的有效性。

无论哪种情况，都对团队产生负面影响。

我看到的主要问题是您正在向团队发送有关团队组织的冲突消息。

以下是两个可能的团队组织。两者都可以成功。它们不一样。（它们不是唯一可能的选择。）

1. 该团队有一位正式指定的领导者。团队负责人最终对团队的整体绩效负责。团队负责人可能不会做出所有决定，但是团队负责人对所有决定拥有最终决定权。
2. 该团队是自组织的，没有正式指定的领导者。团队中的每个人都要为自己和团队的整体表现负责。Scrum Master促进了Scrum流程，但无权为团队做出单方面决策。

听起来您真正的团队结构是＃1，但是通过使用术语和Scrum的若干流程，您就意味着该结构是＃2。我的观点是＃1不是Scrum。

以下是有关解决冲突的两个建议。

1. 保持现状，但要明确说明自己是团队负责人，并且没有100％关注Scrum。可能会有助于解释，虽然您看到了将经理和Scrum主管的职责分开的价值，但这对公司而言并不可行。
2. 尽可能将Scrum Master的职责移交给其他人。即使您仍然必须承担一些责任，例如清除障碍和转移与组织其他成员的分心，仍然可以由同龄人完成许多Scrum Master工作。

作为Scrum Master的开发经理有哪些不利条件？

聘请开发经理来：

• 解决发展问题。
• 监控并减少技术债务。
• 培养技术人员。

他们的背景和专业知识使他们无法专注于技术问题。

另一方面，项目经理/ scrum master被雇用；

• 确保项目成功。
• 将工作和分类错误/问题分配给适当的开发资源。
• 与开发团队合作，消除所有可能延迟项目完成的障碍。
• 将项目状态转发给高层管理人员。

• 当项目或公司发展到一定规模时，要求开发经理同时履行这两项职责是低效率且不明智的。

• 开发经理应该倾向于“深入研究”代码和/或体系结构，而项目经理/ scrum主管应始终关注事物的“ 50,000英尺”观点。

• 大多数开发经理花了多年的时间来开发代码。他们非常熟悉开发问题。

  • 因此，它们在解决技术问题时最有用。
• 项目经理/ scrum主管角色需要非常有组织且非常详细的人员，但不是超级技术人员。
• 当您有能力让这些人专注于他们擅长的事情时，企业将变得最高效。
• 而且，当您可以从开发经理的职责中分担与Scrum相关的职责时，他/她可以将更多时间用于技术问题和减少技术债务。

我会听经验丰富的Scrum教练。您有可能在99％的时间内都能正常工作。但是，当令人恐惧的事情发生了，而角色冲突时，您将有机会不仅破坏个人与您的关系，而且破坏整个团队的福祉。而且，在一次搞砸之后，您作为Scrum主管和经理的角色将受到损害。

如果我是您，我会确定团队中有潜力成为Scrum Master的个人，并与他/她一起去。我一直将Scrum管理员视为团队信任的人，并且了解流程，业务和可怕的技术知识。如果您选择了一个有能力的人，那么Scrum Master角色不是（甚至不是接近）全职工作。