Scrum团队的怀疑论者

我的公司最近改用了敏捷的工作方式，作为其中的一部分，我们开始使用SCRUM。尽管我对此感到很自在，并觉得这种方式要优于传统方式，但我的一些队友却没有相同的看法。实际上，他们对“所有这些敏捷的东西”都持怀疑态度，并且没有认真对待它。例如，一个队友总是在会议上迟到，并且并不在乎。国际海事组织的管理人员试图不注意到这一点（也许是因为它是新的，并且人们需要时间来适应它）。

我的问题是，如何在不引起团队内部冲突的情况下解决此问题？

面对极端怀疑时，我尝试一些操作：

1）我演示技术，如TDD，持续部署，结对编程，需求收集与用户，短迭代等等。我不打电话约敏捷宣言（我做竖琴关于软件工匠对这些技术的敏捷或竖琴-但这是不同的; p）。我只是向团队成员展示使他们的生活更轻松的有用工具和技术。一旦看到每天的好处，他们就会倾向于选择敏捷的潮流。

2.）我不会立即转换为完整的SCRUM（或其他）方法。总是最好一次介绍敏捷的一些小方面。

3.）我同意怀疑者的观点（一定程度上）。敏捷不是灵丹妙药，SCRUM，看板，精益等也不是灵丹妙药。取而代之的是，我与他们一起工作，看看哪些方面可以立即使他们受益（CI服务器通常是理所当然的），然后我尝试其余的工作：“让独立的人试用一周，然后对其进行审查”。

像任何方法一样，SCRUM和其他方法都需要与团队和组织实际合作，而不是疏远他们。

因此，直接回答您的问题。与团队一起提高：

“我对站立的姿势也有些怀疑，但是我认为作为一个团队，我们应该给它一个合适的时间，为时一周（不要找借口！），然后再对其进行检查，看看它是否对我们有用。人们会做什么？认为？”

错误实施Scrum的典型案例。

Scrum已被强加给团队。（整个）团队没有选择它。

当您想要实施它时，您必须得到团队和管理层的全力支持，否则它将根本无法正常工作。

抵制变革是您的敌人。

我强烈建议您从头开始，向团队介绍Scrum，并让他们提出问题。

如果您没有提出建议，请不要尝试使用他们不想要的方法来强迫他们。他们会竭尽全力破坏它。每天站起来迟到是您的行为之一。

请注意，Scrum可能不适合您的公司。唯一可以回答这个问题的人是在基地工作的人。团队。

日常会议的概念可能不适用于某人正在做的事情。这些会议不是免费的。

如果您正在做的事情需要大量的长期注意力，例如沉重的数学运算，那么会议将使您脱轨并感到沮丧。我和这样的人一起工作，他喜欢每周开会，这是完全合理的。

说实话，如果我在您的编程团队中，我可能会持怀疑态度！我已经看到了各种各样的方法论，这些方法论应该彻底改变事物，并使项目按时，在预算范围内并且没有错误。这只是最新的。我为什么要相信蛇油？10年前，同一个人正在鞭打其他东西，几年后将会出现新的事物。别误会我，我认为某些新方法带来了一些有用的想法。不幸的是，它们也带来了很多教条和愚蠢的想法。

他不参加会议真的有关系吗？只需给他分配一些编程任务，然后让他按照自己的方式去做即可。如果他的工作令人满意，那就顺其自然。如果他的工作不令人满意，请更换他。为什么人们关注Scrum如此重要？

多年来，我看到许多优秀的程序员辞职或感到恼火，因为他们的经理不断引入新的方法。他们只想编码并完成工作。相信我，从现在开始的几年后，您将诅咒混乱，并追随最新的潮流。

如果您正在做敏捷，那么您应该有一份积压的工作。使用scrum分发积压的任务。

在会议开始时首先选择（最佳）任务。当您晚来者到来时，请给他剩下的一切。

不管他是编程天赋的天赋，他都能获得别人所不愿做的艰巨任务。如果他试图承担其他任务或从事其他工作，则整个团队都需要依靠他，并迫使他仅完成他的“选择”任务。您可能应该有一个构建母版，如果他不在选择的作品上，可以拒绝他的更改。

团队也应该设定目标并可能补偿。您可以以团队投票的方式对不参加的人进行奖励。这确实取决于您的管理授予敏捷团队的所有权数量。提醒管理那些伤害团队并阻止团队成功的人员。

提醒他，如果他准时出现，他可以参加该过程。

Scrum团队应该是自组织的。Scrum还通过在所有方面实现极端透明来工作。

因此，显而易见的答案是，Scrum Master召集了一个会议，解释了问题（但不要自欺欺人，团队中的每个人都已经确切地知道了问题所在），然后告诉他们他们有1个小时来找出问题所在。他们将为此做。然后他坐在角落里，闭上嘴。

显然，这是Scrum的新团队。所以关键是Scrum Master必须接受团队提出的任何答案。如果他否决了这些想法，或者将自己的想法强加到解决方案上，他将破坏团队需要与他建立的信任关系，使他们能够自我组织。团队可能会决定什么都不做。

无论如何，应该在Sprint回顾展上审查该问题，并可以讨论他们提出的任何解决方案的有效性。

避免“团队冲突”甚至根本不是一个因素。

解雇队友，这样他就不会在团队内部引起争议。

浏览过去的工作，挖掘多个示例，瀑布式方法使您过去多次失望。然后将案例提交给队友。瞥见常识，他将看到光。

编程是一项精确的活动，因此很少有个人会接受这些事实。至少在理论上。

谁决定切换，为什么？那些持怀疑态度的人根本就决定了，还是只是放弃了他们的决定？

您是否过于僵化和/或快速地实施新方法？您是否使用旧方法推出了好的（不一定是完美的）产品？您是否向怀疑论者证明了它将如何使他们受益？你能示范一下吗？那些“看见了光”的人向怀疑者展示了它如何使他们，团队和公司受益吗？

可能您是在要求他们仅凭信徒的话接受一切。这些怀疑论者很可能以前已经采用了新的方法论，并且从没有意识到任何好处。

也许您可以使用新程序仅由信徒进行一个或两个项目。进行实际测量，并向怀疑论者证明真正的好处。甚至在怀疑者和他们的旧方式之间以及信徒和他们的新方式之间建立起一点竞争。

当然，如果怀疑论者获胜，您该怎么办？

召开团队会议，讨论并弄清楚您的公司为什么选择SCRUM，并让每个人都知道他们对SCRUM的看法，这将为当前的运营模式增加价值。有时公司确实会做出愚蠢的选择（我参加过Scrum会议，没有人真正听过，每个人都抱怨昨天所做的事情并离开了。这些团队通常达到平衡，例如-“我不会质疑你，你也不会搞乱和我在一起”，然后在那儿徘徊。那只是浪费时间），所以请选择最适合您的选择。

退伍军人通常对任何可能改变其目前工作作风的东西都有很大的抵抗力，因此您必须确保有足够的胡萝卜让他们摆脱惯性。在这种情况下，我要么和那个人以1：1的比例，要么让他成为Scrum Master ：）。一旦您赋予他们责任，他们就会找到和平或完全放弃它，因为它没有增加价值。两者都是双赢。