图片来自此资源 。您的竞争对手或合作伙伴已经实施了Scrum，并显示出良好的效果，当然您也希望达到这一目标。 我有个坏消息：如果使用不当，Scrum可能有害。
例如，此处是根据经验确定的Scrum可能干扰您的工作的情况的列表。
1.您是否计划将经典项目管理和Scrum中的角色结合起来
Scrum团队必须包括3个角色：产品负责人，开发团队和Scrum-Master。 在拟议组成的框架内，团队保持“扁平化”，也就是说，参与者之间没有直接的从属关系。 这样的团队有权独立做出有关所开发产品的所有决策。 Scrum中的角色清楚地描述了谁负责哪些问题。
现在，假设您打算在具有经典项目管理的团队中实施Scrum。 然后，Scrum团队开始在项目经理的参与下工作。 在这种情况下会发生什么？ 实际上，PM在这样的项目中根本没有什么可占据的。 我们转移给他的任何职责范围都会在Scrum团队中造成失衡。 给PM预算？ 优秀，即PM并不能控制产品的价值和含量，但是如果出现问题，将由谁来接受。 我们还会为他提供产品的价值吗？ 这样就有可能废除产品负责人。 但这不是Scrum。
随着Scrum的到来，团队中的角色和任务将如何变化2.您的工作要求非常明确
创建Scrum是为了开发具有高度不确定性的产品。 在需要频繁发布以获取市场反馈的情况下，此方法效果很好。 在我们的详细要求不能为创造力留出空间的情况下，或者当我们不需要客户/用户的反馈时，Scrum只会将团队时间花费在对产品开发没有多大价值的会议上。
如果一切都已经清楚了，为什么还要复杂化呢？
3.您从事的是短期项目
Scrum的基础是一种经验方法。 其含义是，我们转向团队的现有经验，以便能够预测其未来的成功。 如果我们正在进行的项目持续两个月，那么我们将根本没有时间积累足够的经验来应用它来改善工作流程。
4.团队不希望改变工作方式
这是实施Scrum的关键限制之一。 将Scrum用作准则几乎总是一个坏主意，首先，将价值传达给团队，“卖出想法”很重要。 但是即使在那之后，您也无法保证Scrum的想法将接近其所有参与者。 那些尚未在内部接受Scrum和敏捷价值观的人可以开始从内部破坏系统，“摇晃船”。
有几种可能的方案。 第一：Scrum根本不扎根。 如果大多数团队反对变更，则可能发生这种情况。 团队要么从一开始就组织一次骚乱，要么尽一切努力使新方法无效。
第二种选择：一个或多个参与者将不希望在新系统中工作。 通常，这种情况导致“有问题的”参与者自行离开团队。
改变 我们正在等待改变。
图片来自此资源 。5.您尚未准备好使用Scrum的所有必需实践
对于这种方法，他们甚至创造了特殊术语ScrumBut。 这是我们研究Scrum的时候，但是...我们不举行回顾展。 但是我们每周召开两次每日会议。 但是我们放弃了Scrum管理员的角色。 还有许多其他类似的“ buts”。
Scrum框架为所有这些情况提供了简单明了的答案。 是的，您可以将其他实践添加到团队的Scrum流程中（例如，XP中的实践）。 但是，不能，您不能拒绝任何Scrum元素，因为这不会是Scrum。
Scrum的所有角色，事件和工件都紧密地联系在一起，旨在实现一个共同的目标-有效地为客户提供最大价值的产品。 拒绝Scrum的任何部分都使我们偏离了这个目标。
6.您尚未准备好招募员工全职从事产品工作
您是否已看到生产性工作时间对您同时从事的项目数量的依赖关系图？ 如果没有，请注意。
该图本身是最好的论点，它有利于让员工一次参与一个项目的工作。 但是，如果她不说服您，请从一个项目与其他多个项目一起工作时所花费的时间中减去在强制性会议（日常会议，会议，计划，冲刺审查）上花费的时间。 团队成员将只有很少的时间来完成任务。 需要吗
此规则有例外。 例如，Scrum-Master可以一次与多个团队合作。 但是对于其他参与者，有必要确保仅最大程度地参与该项目。
7.您没有管理支持
正如我们希望员工采用新的工作方式一样，我们也需要管理层的支持。 重要的是要了解Scrum的引入，尤其是在
早期阶段可能需要一些投资。 例如，雇用敏捷教练或专业的Scrum主管，培训产品负责人，为员工进行Scrum培训等等。 领导者应准备好为新企业提供财务支持。
但这不是最重要的事情。 更重要的是，公司管理层应该分享Scrum的价值并准备改变公司的文化。 例如，领导者需要为他必须赋予新权力作为团队中新角色的一部分这一事实做好准备。 并非所有人都为此做好了准备，因此也可能需要在此级别“出售一个想法”。
此标准列表并不假装是详尽无遗的；您可以自己补充它或在评论中分享您的案例。