我该如何与适得其反的Scrum团队打交道？

背景故事：
在过去的三年中，我一直作为这个团队的一员，这次我们有三个不同的Scrum Master，他们的运作方式各不相同。

由于Scrum Master的这种变化以及他们运行节目的方式，它使我的团队对Scrum的想法麻木了，因为原则并没有得到一致的执行，并且其中一位Scrum Master是一个不相信敏捷的人。开发和只是保留事件和工件，以作为新手遵守公司决策。

现在，当我们进行Scrum活动时，我的团队成员感到非常烦恼和无聊，尤其是一个人对此非常口头。

现在：
两个月前，该公司任命我为我的团队的Scrum Master，因为我致力于敏捷及其原则。

在不愿意做Scrum的团队成员的大气压下，我遭受了巨大的痛苦。

如前所述，他们对整个过程感到恼火，这对我来说非常困难，因为他们没有参与进行有效的计划，回顾和每日Scrum所需的必要对话。

对他们来说，计划只是浪费时间，因为我们只是将溢出转移到新的Sprint中，而无论如何都不会完成工作，所以为什么要打扰呢。

在回顾期间，我只能感觉到他们想说“停止做Scrum”。一个人这样做，但其他人则保持沉默，我每次都要处理。

每日Scrum再次对他们来说只是浪费时间，因为他们没有人打扰他们谈论和计划一天。他们只是说：“我昨天处理任务X，今天将再次处理。” 而且大多数时候，他们只是在开玩笑，直到我变得更加严厉。

关于他们在这些活动中如何度过的时光，我的心态很大。但是我要死在里面，因为我对此充满热情，他们不再关心。

今天，一直反对我的人告诉我不要说“他们说这是他们为Sprint所做的承诺”，因为用他的话说，“我们从不完成Sprint。我们只是在任务中移动并接受新的下一个Sprint填补配额。我们实际上是看板。所以不要再这么说了。”

我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的每个人都不在乎。他们只是做事而不是处理障碍。他们抱怨障碍，但不对他们做任何事情。而当我尝试帮助他们时，他们只是耸了耸肩。

他们曾经很讨厌，但在过去的两年中，他们的意愿或多或少地下降了。

我如何让他们看到在这些会议中开玩笑和浪费时间使公司损失了很多钱？

您可能已经听到了很多有关失败软件项目的统计信息，并得出的结论是该失败不是技术性的。可以通过数百种技术解决方案来解决技术问题，但是使用Scrum解决工作场所环境中的问题是行不通的。

我的建议是完全停止将其视为技术问题。这与Scrum无关，与日常站立，冲刺，回顾或其他类似的事情无关。您需要与您的团队保持联系，并找到一种使他们以及您和您的上司满意的有效工作方式。

如果他们认为日常工作是个坏主意，则不应告诉他们进行日常工作，并尝试将推理方法融入其中。自己想一想每日提供给您的东西。向您的团队检查他们是否也重视这些优势。找出他们为什么不与您分享您的理解-理解他们的观点，而不是说服他们任何事情。然后检查日常工作是否真的对您的团队有所帮助，或者您是否可以通过其他一些机制实现更多目标。关于Scrum大师的有趣之处在于，他们是团队的仆人-完全废除Scrum可能会为他们提供最好的服务。

总之，不要再将重点放在Scrum上，而要回到敏捷的基础知识。您可能想从敏捷宣言一开始就开始：通过流程和工具来重视个人和交互。

以我的经验，被幻灭的团队需要先进行有效的回顾。因此，在我看来，回顾是敏捷过程中唯一必不可少的部分。其他所有内容都可能通过回顾进行更改。

在有效的回顾中，您不仅会抱怨问题，还至少选择其中一个问题并找出可能的解决方案，然后在下一次迭代中尝试该解决方案。在下一次回顾中，您将讨论该解决方案是如何工作或不工作，并在必要时进行进一步调整，或者选择另一个问题来解决。

当团队成员看到他们有权在流程中进行实际更改时，他们将变得更加乐于参与。

追溯过程就是为什么如果您拜访一家表现出色的公司中的所有团队，他们的做法都有些不同。我们有一些团队进行看板，一些团队进行XP，一些团队仅在星期一（星期三）星期五做站立训练。

如果您的团队不喜欢您如何处理宿醉，请集体讨论一些不同的方法。仅通过不断地回顾和尝试解决方案，我就赢得了非常勉强的开发人员。

好吧，让我们开始粗略地讲-问题的大部分与您有关-您听到了，但您不听。您的团队正在清楚地告诉您问题所在。您需要解决这些问题，而不是责怪您的团队。

规划

对他们来说，计划只是浪费时间，因为我们只是将溢出转移到新的Sprint中，而无论如何都不会完成工作，所以为什么要打扰呢。

究竟。如果您始终未能为任务分配正确的时间量，并且始终低估了它们，则会产生非常不利的影响：

• 开发人员觉得自己一直在承受压力。
• “我无法及时完成任何事情”。
• 由于该过程不起作用，因此他们理所当然地认为这是浪费时间。

解决方案：结合以下几种方法来修正您的估算：

• 故事点（时间和风险的组合）。
• 不允许任务进入大于55 SP的冲刺
• 比较估计
• 循证调度

为此，您绝对需要跟踪完成先前任务的实际时间，包括测试，编写文档，编写测试，最终用户培训，集成工作，部署。等等

一旦有给定任务的总时间，就可以将预期时间基于之前的任务。

询问每个成员是否比选择以前的任务感到更复杂或更容易，然后根据此任务调整分配的任务数。

如果您以前没有使用过SP，我的建议是从1h真正诚实的工作开始= 5SP。请记住，在通常的开发环境中，您每天可能会得到其中的6个，因此每天最多 30SP 。切勿允许花费超过2天才能完成的任务。理想情况下，根据我的经验，您每天应该有2个任务。

如果您没有正确地进行计划，那么其余的Scrum活动将看起来很浪费时间（包括计划）。

回顾性

在回顾期间，我只能感觉到他们想说“停止做Scrum”。一个人这样做，但其他人则保持沉默，我每次都要处理。

让我想起Daily beatings will continue until morale improves!了过去的两个工作。如果您没有消除障碍，那么它们是对的，那是浪费时间，这是正确的。

再说一遍，听人们在说什么。如果回顾会议期间提出的投诉没有得到解决，为什么还要烦恼呢？

所以：

• 考虑使用“六顶思考帽”技术来改善沟通。
• 减少在追溯上花费的时间，最多30分钟。
• 确保在回顾会议之前提出的投诉在下一个投诉之前得到解决。

每日SCRUM

每日Scrum再次对他们来说只是浪费时间，因为他们没有人打扰他们谈论和计划一天。他们只是说：“我昨天处理任务X，今天将再次处理。” 而且大多数时候，他们只是在开玩笑，直到我变得更加严厉。

听起来您这里有两个问题：SCRUM会议时间太长，您的计划和任务创建很糟糕。

两者都可以发出声音，就像召开会议是浪费时间。

对于SCRUM长度：

• 最多尝试15分钟。
• 尝试所有人站起来。
• 固定公式：
  • 你昨天在做什么
  • 你今天打算什么
  • 您的团队成员（不是您！）应该了解该任务及其对任务的影响。
• 如果您不想解决这些障碍，请不要打扰。

这是第二个证据，表明您的计划会损害您的情况-如果您没有要报告的具体内容，通常意味着任务太大，您只能说：我正在努力。

• 将任务分解为要点。
• 确保任务足够小以花费不到一天的时间。理想情况下，IMO，任务应持续约3小时，大约相当于13 SP，因此您在大多数情况下每天可以执行2次。

与团队打交道

今天，一直反对我的人告诉我不要说“他们说这是他们为Sprint所做的承诺”，因为用他的话说，“我们从不完成Sprint。我们只是在任务中移动并接受新的下一个Sprint填补配额。我们实际上是看板。所以不要再这么说了。”

他是对的。你错了。您正在对看板进行混蛋SCRUM和/或变体。完全不是他们的错。

我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的每个人都不在乎。

我想你一点都不懂。他们可能比以前更关心，但是责备他们不仅不会改善任何事情，而且只会使情况变得更糟。如果那是岩石底部，他们实际上可能会开始挖掘。

他们只是做事而不是处理障碍。

在这里，我认为工作是他们工作的全部。我不知道应该由谁来处理障碍。...哦，对了。Scrum大师。这是你的工作。他们告诉你怎么了。您修复它。并非相反。

这可能就是为什么您在回顾展上有这么多问题的原因。

我如何让他们看到在这些会议中开玩笑和打圈圈花了公司很多钱？

停止无用的会议，他们会在开水器附近开玩笑。另请参见有关殴打提高士气的段落。如果他们使用幽默作为防御机制，您会遇到一些严重的问题！

开个玩笑-与您的团队一起工作，而不是反对。（谁在乎公司的钱？您现在是股东吗？）

总结一下

您的错误计划使SCRUM的其他部分失败，并且每个参与其中的人都感到痛苦。他们看到什么也没有改变，没有解决任何问题，也没有听到他们的抱怨。

改善您的计划，您将改善流程和士气。

尽一切努力消除障碍，您的团队将进步更快。问他们他们觉得您应该如何帮助他们。

最重要的是：听你的人说话。他们已经告诉过您（和我）出了什么问题。

祝好运！

敏捷的主要原则之一是回去，纠正所有错误。这不仅包括代码重构和错误修复，还包括开发过程。

那么，为什么不与您的团队开会，看看如何改善开发过程？如果那意味着没有混乱或站立会议，那就这样。

另外，您正在打破敏捷宣言中的原则之一：“流程和工具上的个人和交互”。

另一方面，如果您的团队认为迭代开发不好，那么也许您做错了。如果您没有完成一次迭代中计划的所有事情，那就没关系-您始终可以将事情移到下一次迭代中。这就是为什么您将事物标记为“必须包含”，“很好拥有”等原因。只要提供新功能，就可以很好地完成工作。

只是一小撮人：在我以前和现在的公司中，我们做了并且仍然在做站立会议。根据我的经验，他们每次都花费30分钟以上的状态报告会议，而我却几乎没有提供任何信息，因此浪费了大量时间。人们谈论他们的问题，老实说我不在乎。
在我以前的公司中，他们很机灵，意识到站立时会出现此问题，并在人们开始抱怨后立即将其阻止。

如果您想观看有关Scrum的非常好的视频，请参阅“ Robert C. Martin-Scrum遗忘的土地 ”。

作为我的优先任务，我将研究那些不断发展的任务。无法达到目标会极大地令人沮丧。您投入太多吗？是否有应分类的肥胖记录？是否有您无法控制的瓶颈？您对“完成”有明确的定义吗？要求明确吗？每个开发人员的小时数是否合理（即考虑到管理员，站台，计划，回顾，键盘中断，非项目工作）。

接下来，抛弃所有不起作用的东西。没有价值的过程只是个时间贼。如果不专心做事，不为团队提供价值，站起来会消耗大量时间。最好将时间花在其他地方。如果规模太大，也可能考虑将团队拆分。

设法弄清哪些因素会使团队失去动力。进行回顾，更重要的是，对输出采取行动。庆祝成功和寻找失败同样重要。

最后，您可能想要评估可以先破坏品牌的Scrum管理员的方法。我曾在一个有毒的Scrum主管下工作，在此之前，无论您是否知道，所引发的每个问题都被添加到您的工作负载中。最终结果：问题被忽略了，每个人都很少团队合作地在自己的小区域工作。

在我看来，让团队有效地关闭sprint（至少关闭故事的80％）是一项最重要的事情。如果您的团队始终缺阵，则表明您需要调整估算值。

团队应该接受这一点，尽管要让开发人员更真实地进行估算可能非常困难-我在一个团队中，一年未完成冲刺（始终少于冲刺的50％） ，总是低估，在每一个计划/回顾会议中，我都是一个孤独的声音，告诉他们您的估计很糟糕，您愚蠢地过分自信，不再为阻碍您进行估计的借口找借口，而是调整估计以反映现实（也许比这更外交，但这是基本观点）-当您担任该职位时，我将完全同意您团队的巡回演讲，他说此过程是在浪费时间，因为您实际上是在做KonBon，无论你叫它什么。在某种程度上，他的观点得到了实际情况的证实。它'

在某些时候，您必须重新设置事情，您必须让团队大幅补偿他们的估计，以使系统正常运转。一旦团队开始一致地结束故事，他们应该认识到敏捷过程主要是常识，而未能以某种方式实现则对您的生产力有害。但是，只要不认真地对待“承诺”和“冲刺目标”（当他们未能始终如一地实现它们时就会发生），那么整个事情就是假的，并且会浪费团队的生产力。

要让人们以截然不同的冲刺（在估计，计划，承诺等方面）买进是很困难的，由于两个因素，我最终在那个团队中做到了这一点。一个人只是从JIRA收集数据，然后说：“没有任何借口，数字是遥遥无期的，它们总是朝着一个方向偏离，我们需要更正它，我不希望复古有借口，我想“数量的总和” –另一个是高层管理人员带来的压力，我最终向他们解释说……“这个过程的目的是使我们的开发时间表可预测。如果我们每完成固定数量的工作，独立于此的sprint很好，我们的董事会需要准确地反映我们所做的工作。相对于我们的实际输出，管理层更了解我们相对于承诺的成功，为了您自己，使投影与输出保持一致，这样看来您正在完成工作，而不是花费每个冲刺的一半什么也不做。人们离这个时代越远，他们看到自己失败的机会就越多，复古的借口甚至不在他们的职权范围之内，他们只是看到你失败了。”

最终，我们的团队获得了牵引力，事情开始变得更加顺畅，低调和低调，甚至在流程真正开始运作后，我们甚至开始获得更高的输出。因此，tl; dr-采取一切必要措施以相对较高的成功率开始关闭sprint。如果您不这样做，那么您团队中的巡回赛将继续通过结果验证他对Scrum的抵抗力，并且最终将是正确的，因为您的过程实际上只是在浪费所有人的时间。

作为Scrum Master，您指导并指导团队提高生产力。Scrum框架是实现此目标的强大工具，但是Scrum框架绝对绝不能成为目标，否则您将成为Cargo Cult。

看来您从事货运崇拜已有3年了，人们意识到这是一种可怕的项目管理方法。好消息是您有聪明的人，他们做对了。不幸的是，您公司中的某些人称其为Scrum，但是您又有了聪明的人，他们甚至告诉您团队的工作不称为Scrum。

计划只是浪费时间，因为我们只是将溢出转移到新的Sprint中，而无论如何都不会完成工作，所以为什么要打扰呢。

究竟。何必呢？您需要找到答案，或者更确切地说，您需要更改计划和冲刺本身，因此有必要进行计划。要么，要么停止浪费时间与毫无意义的Sprint计划。您可能想请公司派遣Scrum Master培训给您，因为运行出色的Sprint计划并非易事。

在回顾期间，其他人保持沉默，我每次都要处理。

如果您在每个回顾展上都在处理相同的问题，那么人们甚至都不会在这个回顾展上打扰（不再吗？），这只是浪费时间。除非您或团队可以以某种方式解决回顾会议中提出的问题，否则会议只会使团队士气低落。回顾会议中提出的问题必须解决，下一次回顾会议应取得进展。

每日Scrum再次对他们来说只是浪费时间，因为他们没有人打扰他们谈论和计划一天。他们只是说：“我昨天处理任务X，今天将再次处理。”

的确，如果每个人都花几天时间从事相同的工作，那又何必浪费他们的时间呢？他们是完全正确的，“每日站立”确实是毫无意义的。Standup促进了许多任务的紧密协作，每个任务都可以在半天或更短的时间内完成。如果您的任务无法通过这种方式分解（由于Sprint计划中断，或者因为您的任务实际上与Scrum不合适），那么举行5分钟的每日站立会议就没有多大意义了（这是不超过5分钟，对吧？）。

“我们从未完成Sprint。我们只是移入任务，而在下一个Sprint中接受新任务以填满配额。我们实际上是在做看板。所以不要这么说。”

我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的每个人都不在乎。

不，你绝对不明白他为什么这么说。您有障碍的根本原因-您需要解决-错误。他们不在乎，因为团队的项目管理实践很糟糕。关心做货崇拜和更努力地做货崇拜并不能阻止它成为货崇拜，这是现有的最差的项目管理方法之一（在您的防御中：也是最广泛使用的方法）。

您能对此做什么？

1. 听他们的担忧。再次，您很幸运，有了聪明的人。

2. 帮助他们解决障碍。

就是这样，真的。您将需要试验如何更改Sprint计划，每日Scrum和回顾展，以使其对团队有价值-即使您想删除Scrum标签，您仍然要召开这3次会议，它们的频率和目的相似项目管理方法论。至于您要如何进行实验（频率，内容，主持会议的人，时间，持续时间等），这非常简单：请团队。不要将您的想法强加于他们，如果有任何事情，您应该让他们将其想法强加于您（假设他们可以就某些想法达成一致）。

如果您担心会失去控制，请事先设置一些界限，例如：

• 会议的标签保持不变。
• 会议仍在举行，会议频率的变化不能超过2倍。
• 您目前正在实验中，因此任何更改只能持续2个sprint，之后您将恢复为旧模式（最好在几周内给出时间，以防他们想将sprint持续时间加倍时产生歧义）。

我认为每个人都在《敏捷宣言》中引用了同一行。我将做同样的事情：“流程和工具上的个人和交互”。

如果您是SCRUM的主人，然后要使用SCRUM来完成这项工作，则必须以一个人与另一个人进行交互的方式来对待它们。开始集思广益如何使流程更好。也许您可以说服他们喜欢SCRUM。也许他们可以说服您使用其他过程。让我们找出答案！

听起来团队已经意识到当前的系统无法完成任务。您能鼓励他们相信它能胜任吗？您提到了一些示例。如果您将Sprint填满，以至于它始终泄漏...请停止。是您的SCRUM团队。帮助他们停止过度投入。推迟管理，以腾出一些空间。使用SCRUM的好处。用它向管理人员展示数据，他们正在努力地努力，以至于他们失去了流程中的价值。如果管理层希望将SCRUM作为一个过程，请让他们帮助建立修复它所需的空间和能量。作为SCRUM的主人，您的任务是解决问题，使团队高效。

另一种有用的方法可以是在旧的程序中产生一个新的程序。继续以同样无用的方式运行SCRUM，但是请警惕时间表的一小部分，然后说：“在我们的时间表的这一部分中，我们将弄清楚如何正确使用工具。” 不要在那里过量使用。使用您的指标。专注于在那里的所有会议。只是“ SCRUM”项目的其余部分，可以作为盾牌，使您和您的团队在保持管理层满意的同时“通过开发并帮助他人来开发更好的软件开发方式”。随着时间的流逝，您会希望将越来越多的有价值的任务放入此存储桶中，而旧的存储桶将慢慢消失。很快，您将拥有一个充满活力的软件开发环境，没有人比这更明智。

或混合搭配。我开发了一个反乱序程序。客户希望能够在流程中的任何时候添加新任务，并让我们立即对其采取行动。（这实际上是一个理智的请求：他们的工作非常不稳定，他们经常需要快速的支持……这就是我们的报酬）。当然，我们必须弄清楚如何处理他们的“当您在冲刺中答应X时为什么不做X”问题。我们的解决方案实际上是建立一个两步过程。将长期任务放入SCRUM中以进行适当的优先级排序。短期任务置于自制流程中，该流程着重于客户端和开发人员之间的紧密交互。据了解，欢迎客户使用此短期流程来推动我们，但他们知道这样做会推动Sprint' 的时间轴，并且禁止他们添加请求，而不能同时听到并解决它们引起的调度问题。结果？有效。大多数任务都按应有的方式放在了SCRUM流程中，并且紧急情况与它们无缝地交互。态度是：“如果您想成为客户，请排队观看SCRUM故事。如果您想成为合作伙伴，请随时下来与我们合作，使该产品正常工作！！”

我之所以这样说，是因为我真的知道。您在高层管理中存在一个问题，即过度计划，无法设置优先级以及愿意添加更多项目但不推迟发布日期的问题。

我曾经说过，没有一种方法可以像这样运作，但是既然我看过看板就可以了，但这只是因为看板不必关心。过量使用时，它继续起作用。它不会更快地带来结果，但不允许将队列中的备份放在任何人身上，因此管理问题在于管理。反馈报告显示过载，这是正确的。

由于Scrum Masters及其运行方式的这种变化

哦，这可能是您的问题。Scrum主管不在那里进行表演，他也不是项目负责人。他在那里确保所有利益相关者都在沟通并且操作是透明的。

我想知道团队来自哪里。在Scrum（包括不可避免的Scrum管理员）落在他们身上之前，难道是他们或多或少是自主的吗？为什么首先引入Scrum？应该解决什么？

Scrum应该提供指导，您的团队正在明确表示他们没有以任何方式体验到它的帮助。他们不在乎指导，他们认为这是不适当的时间浪费。显然，至少有一个决策者认为他们无论如何都要受到指导。谁？为什么？他们有观点吗？

这是一个问题，不仅限于软件。

在任何工作环境中，都会有不同个性和能力的不同人。即使Scrum是一种完美的方法，由于其个性和能力，仍然会有人们反对它。

开发人员以合理的方式处理困难的任务。为了做到这一点，每个开发人员都将有自己的方式来处理可能会厌恶诸如Scrum之类的事情。如果所有开发人员都以完全相同的方式从头开始进行培训，则使用一种模式可能会容易得多，但否则需要在开发人员或管理方面进行调整。

此外，独立的思想家（开发人员和其他专家）通常不喜欢被告知如何做事，因为那是他们的工作，意见冲突很容易发生。对于逻辑思想家来说，Scrum似乎是毫无意义的仪式，而逻辑思想家通常会针对眼前的每个问题进行分析并采取相应的行动。

以下内容似乎暗示了问题所在，而不是问题所在。绝对不止如此。我只能（出于经验）假设开发人员尝试过但遭到阻止。我已经看过很多次了，开发人员想要修复某些东西，但是系统的东西（管理，公司政策等）使它几乎不可能，因此他们放弃了。他们是否真的不在乎，还是不仅仅在乎做一些他们认为无济于事的事情（可能是经验不足）。

我理解他为什么这么说，但是他似乎并没有意识到这是事实，因为他和团队中的每个人都不在乎。他们只是做事而不是处理障碍。他们抱怨障碍，但不对他们做任何事情。而当我尝试帮助他们时，他们只是耸了耸肩。

他们曾经很讨厌，但在过去的两年中，他们的意愿或多或少地下降了。

我如何让他们看到在这些会议中开玩笑和打圈圈花了公司很多钱？

如果某件事被强加给他人，则取决于人们强迫该方法说服他们受益。尽管我真的不相信强迫人们做事，但我还是建议在任何情况下都应该听取所有人的意见，并开发出一种适合当前环境的方法。

Scrum并非没有缺点。我当然可以为自己说话，但是我认为开发人员讨厌它是有充分理由的。我的诚实意见是，绝对不能尝试。

要了解原因，请阅读每个Scrum管理员应该了解的Scrum。它不是我写的，但是所有的一切都代表了我的经历，我只能总结为纯粹的恐怖。

就我而言，我尤其在第5点遭受了痛苦。基本上，scrum将我视为孩子和失败者。现在，我是一个足智多谋的开发人员，可以帮助我的同事们……难怪我更喜欢！

我现在有一个新的（非scrum的）老板，可以走动并与人们交谈，对此我感到非常感谢！之所以可行，部分原因是我们还拥有一个聊天室（我们使用最多的聊天室）供开发人员之间进行交流。如果有人在讨论议程，我们会把它放在那儿。会议仅用于开发人员的临时讨论，而不是为自己设置人为的每日截止日期。

您已经得到了很多很好的答案。这里还有其他几点可能会有所帮助：

改变方法很难

在工作区中这是一个巨大的挑战，因为您在“这就是我们的工作方式”的惯性下工作，并且要面对截止日期和业务需求的压力。

您得出的结论是您的团队需要花更多的时间进行计划，而不是更少，这是非常正确的；计划是您目前所处时间不多的地方，需要改进。问题是，您不能仅仅通过规定新规则来达到目标​​。在成为新的帮助之前，新规则是新的负担。而且，如果它们不能立即提供巨大价值，那么您将获得回避而不是合作。

我强烈建议Roy Osherove在这个主题上。他简要介绍了如何在您的公司中计划和实施变更，并且在本视频中对这个话题进行了更深入的探讨。

Osherove的基本观点是，必须应对以下所有挑战：

个人动机： 为什么有人应该关心以特定的方式行事？
个人能力： 他们真的可以做到吗？
社会动机： 这种行为是否存在同伴压力？
社交能力： 我周围的人是否支持我的行为，并在需要帮助时帮助我？
结构性动机：对好/坏行为有奖励/惩罚吗？
结构能力： 物理环境是否支持这种行为？

您需要学习分解任务

您的团队认为“我昨天处理任务X，今天将再次处理”，从某种意义上说，任务被推迟一周，它们似乎是正确的。

在这里真正有用的是学习如何将任务分解为小部分。什么你要找的是问题的答案：“好吧，你的工作任务X，但在任务X具体是什么，你对工作的今天？”

一些答案可能是：

• 我正在学习此类旧代码。
• 我正在修复错误，其症状是（症状）。
  • 如果这是一个持续不断的错误，并且需要一段时间：“今天我要尝试的是...（计划）”
• 我需要更改此界面。
• 我在写测试。
• 我正在集成未经测试的代码。

... 等等等等。能够观察一天或一周内实际可以完成的工作，这是Agile的一大优势。但这意味着您实际上需要查看各个日子的解决方案，而不是每当准备就绪时就会准备就绪的整体任务X。

完成与交付

一个普遍的问题（对于敏捷和总体而言是工作场所规划）是截止日期往往来自管理层，而不是开发人员。该截止日期可能与要完成的实际工作背道而驰-特别是，它可能希望尽快交付。

问题是，“尽快交付”是一个非常混乱的过程。它鼓励偷工减料；编码“快速而肮脏”；忽视指导方针；不清理自己。它鼓励一种“尝试一下，看它是否有效。如果可以，交付，如果不可以，请尝试其他方法”的心态。用这样的措辞，您可以看到为什么没人能预测任何事情需要多长时间。

如果您有条不紊地进行工作，如果您对计划和测试严格，等等，那么您已经建立了许多路标和安全网。这可能会花费更长的时间 -您花了很多时间来处理无法进一步立即交付的事情，而且，您可能还不太擅长这种工作流程-但它的波动性要小得多。

因此，要问自己一件事：开发人员是否根据他们实际看到的需求设置了冲刺目标？还是管理层设定了最后期限，让开发人员尝试将其承诺安排在类似sprint的时间表中？

如果没有足够的时间来计划开发人员或按照可靠的计划工作，那么开发人员就无法做出有用的估算也就不足为奇了。:)

这可能是一个不受欢迎的观点，但是您可能对此无能为力。

我可以想象，随着团队的存在和领导者的不断涌动，那些对团队真正不满意的人离开了。剩下的就是那些可能会抱怨的人，但是对实际为改善这种状况而付出的努力不感兴趣。他们只想花费8个小时的黑客代码，而不会被任何人打扰，只能在一天结束时回家。您在这里所拥有的似乎是严重的动机问题。解决该问题不是Scrum管理员的工作。谁来付钱给那些人是一个问题。

如果确实如此，那么只有真正的选择是摆脱当前的团队，并从头开始。也许留下您认为是团队中最好的一两个人，然后开除或将其余人员转移到其他团队。您至少应该与您的上司讨论这种可能性。