像许多经典的, 永无止境的冲突, 关于开发团队应该如何组织和自治的争论还在继续. 目前看来，Scrum的批评者似乎比支持者多. 最常见的三种抱怨是:

1. 这个过程可能是整个工作的中心.
2. 它很容易被误认为是微观管理.
3. 每天的单口相声会让人感觉像是一场必须证明其存在的会议.

在其他情况下，Scrum的角色没有得到适当的表示. Sometimes, 产品负责人想要在sprint中做太多事情，或者想要在sprint - a中改变优先级 Scrum master 谁痴迷于保持速度，并采用他们学到的每一个新的Scrum仪式. 在使用框架一段时间后，一个常见的问题似乎出现了:“是我们还是方法??”

Scrum的错误希望

虽然有许多功能障碍，如上面概述的, 对他们中的大多数人来说，一个简单的根本原因是Scrum并不是为了通过遵循流程来解决组织内部的潜在问题而设计的. 如果没有认识到这一点，新团队几乎一开始就会陷入危险之中.

错误希望1:Scrum让团队工作更快

在外人看来，Scrum使用的术语似乎可以在不增加额外资源的情况下加速流程. 很容易陷入术语的泥潭 Scrum的新团队 (e.g.什么是Scrum管理员? 产品负责人和产品经理的区别是什么? 什么是故事点，它们是如何分配的?)

更麻烦的是，许多人看到速度和冲刺这样的术语，就会想到“速度”.然而，任何的目的 敏捷方法包括Scrum在内，就是交付一个成品. Eventually, 当你的团队更能胜任Scrum时, 您将能够更快地交付新功能. 然而，速度不一定是主要目标. 这种区别应该在你的Scrum团队中清楚地表达出来，当你在公司内部建立支持Scrum方法的意识时也是如此.

You are not selling speed; you’re selling completion.

错误希望2:严格遵守Scrum将解决公司文化问题

每个人都有不同的工作方式. 有些人喜欢开会. 其他人则使用“努力工作，尽情玩耍”这样的短语.“重要的是要认识到，无论你的公司看重什么样的工作方式, 你接受了它的优点和缺点. 一家重视会议的公司可能很难应付每天的单人脱口秀. 积极进取和以速度为导向的团队会在冲刺中遇到范围蔓延的问题.

有时候，人们很容易忽视大局，尤其是对于新组建的团队. 重要的是交付成品，而不是遵循过程的每一个细节. 而不是指责方法, 总是想办法改进你的工作方式来实现你的目标.

错误希望之三:关键贡献者可以派代表参加会议

一旦你开始使用方法论, 至关重要的是，原来的团队参与，而不是代表. 我从开发者那里发现了一个普遍的抱怨, 而是Scrum主管和产品负责人在需要的时候无法使用，他们的委托也没有得到授权. 没有人喜欢来开会期待一个决定，却被告知能做决定的人不在.

授权可能是一种常见的做法，但在Scrum中，你还必须授权给参与者.

错误希望4:每天的单口相声会让每个人更专注

每天的站立会议不应该只关注每个人在过去24小时里做了什么. 优先考虑解决问题的障碍或新方法要重要得多.

Scrum要求某些角色，尤其是Scrum管理员，要有主见，但不能压倒一切. 对于Scrum管理员来说，创造一个积极的环境来完成产品是很重要的.

错误希望5:第一次尝试就能成功

Scrum包括猜测、演绎思维和犯错. 人们很少在第一次尝试时就能做对. Scrum在所有方面都是迭代的:不仅仅是在如何获得最终产品方面, 还在于你如何管理和操作这个过程. Scrum旨在为团队采用设置一个较低的进入门槛, 但它也需要承诺迭代并不断改进对框架的参与.

如何修复破损的Scrum流程

Scrum抵制沉没成本谬论. Scrum的迭代特性创造了适应或抛弃无效流程的机会. 考虑以下建议，如果你 Scrum process 没有你预期的那么有效吗.

调整你的期望

无论是缩短上市时间, 创造引人注目的产品, 或者帮助团队协作, 成功需要承诺和时间. For new teams, 要实现的一个合理的里程碑是，在每次冲刺之后，你是否可以引入工作, testable code 进入您的生产环境.

高级团队可以通过他们按需构建、测试和部署的能力来衡量成功. 你是否能够测量和量化用户对新功能的反应? 更广泛的组织是否准备好支持团队对产品所做的更改?

授权你的参与者

在线下指导团队成员如何增加他们对团队的价值是很重要的. 如果他们被要求做决定，你可以这样做来增强他们的信心 coaching 他们决定何时以及如何包括其他团队成员. 管理者需要准备好清除障碍，并在需要时支持团队.

积极解决问题

Scrum并不是为了让你的公司焕然一新. 如果你没有解决问题, 你很可能会在产品开发过程中发现这些问题. Scrum管理员可以引入框架，为团队成员创造一种积极的方式来组织他们的反馈，以减少冲突感.

一个这样的例子是“我希望，我想知道，如果”框架. 在团队讨论或 retrospectives，团队成员可以通过以下三个短语中的一个来开始他们的陈述来给出反馈. For example, they could say, “我希望站立会议能更多地关注我那天可能需要注意的障碍.你也可以用自己的开场白，比如“我喜欢……”.

Holocracy的Triage方法是另一种在会议中有用的结构化反馈解决方案, 由布莱恩·罗伯逊(Brian Robertson)创建，并被Zappos等公司使用. 例如，参与者建立一个讨论“紧张关系”的议程. 每个参与者通过说“我有一个紧张”来描述他们的问题，然后列出他们需要解决这个问题的人员和资源. 通过鼓励参与者直接将问题视为“紧张关系”,“全民政治使参与者能够自由交流，而不会产生冲突的气氛.

使用回顾来解决问题，并在过程中进行迭代

在许多公司，回顾没有得到应有的重视. 这主要是因为许多人担心回顾会成为旧争论的场所, conflict, and grievance. 对于团队来说，制定反映团队价值观和公司文化的基本规则至关重要.

同样重要的是，需要避免对静态流程进行投资. 曾经有效的方法可能不会永远有效. 许多团队都在努力解决参与者流失的问题. 这在许多公司都很常见，因为参与者被重新分配到其他团队, get promoted, 或者干脆离开公司. 随着团队组成的发展, 重要的是不要坚持认为Scrum中的一切都是迭代的. 错误是会发生的，但希望它们在迭代过程中是短暂的.

当参与者在场时，Scrum效果最好

作为团队的一员，你必须保证随时待命. 产品开发可能是你的公司为提高长期增长所能承担的最关键的过程. Therefore, 重要的是，Scrum过程, 作为新产品开发的主要途径, 得到应有的关注. 在很多环境中, 开发团队的工作通常脱离推动公司目标的决策和讨论. Scrum是不同的. 在Scrum中，决策、方向和开发作为一个过程结合在一起. 在Scrum方法中召开的会议中，派遣代表或将团队成员排除在外是一个非常重要的过程.

总结:你可以修复破损的Scrum过程

因为它的迭代性质, Scrum有助于保护业务不会在道路上走得太远，并承诺可能最终成为一个糟糕的想法或执行不力的过程. 坚持这一原则有助于从过去的错误中解脱出来，并迭代地改进Scrum过程.

关注个人和团队是很重要的. 团队成员变化. 所有的项目都是不同的. 严格遵守流程并不总是产生最好的结果. 在这个过程之外，你对团队成员的投入与你在这个过程中的表现同样重要.

Scrum是灵活的. 如果有些东西不起作用，请考虑将其他框架中的元素都纳入其中 Agile and outside. 识别并采用对抗性讨论的结构化沟通风格.

Scrum通过使团队能够构建完整的产品来响应不断变化的客户需求，从而有利于长期的ROI. Scrum可能是最好的方法，它可以防止你过度致力于糟糕的想法，同时给好想法一些进一步发展的空间.