当 Scrum 不起作用时该怎么办

Scrum 很棒！ 除非它不是。 当 Scrum 似乎不起作用时，您会怎么做？
诊断一：使用过程错误

如果你对失败的直接反应是“哦，那一定意味着你做错了 Scrum”，那么就要小心了。

Scrum 确实经常被滥用（在这种情况下，补救措施是明确的）。但是，如果您没有检查手头的情况就直接得出结论，那么您就犯了 错误地认为 Scrum 总是正确的解决方案。“如果你的项目失败了，那么你做错了 Scrum”这句话的意思是，通过 逻辑转换 ，“如果你正确地做 Scrum，你的项目就会成功。” 记住弗雷德所说的关于 的话 ！

那么，如果 Scrum 使用得当，而项目似乎仍然失败了怎么办？

诊断2：出现责备信号

Scrum 旨在暴露问题。 在一个案例中，客户在第一个冲刺后取消了一个项目。 根据团队的速度和他们估计的未来速度，产品负责人意识到这个项目需要很长时间才能盈利。 所以他取消了。

有时旁观者会说：“看，他们一开始做 scrum，项目就搞垮了！” 幸运的是，他们没有这样做，他们没有意识到 Scrum 通过及早终止了一个糟糕的项目，帮助他们节省了大量资金。Scrum 造成了“一种很好的痛苦”。

当问题被 Scrum 暴露时，专注于问题——而不是 Scrum。

但是，如果问题似乎是由 Scrum 引起的呢？

诊断3：不耐烦

新团队的第一个冲刺通常是一团糟。 在新团队学会有效协作之前，需要进行几次冲刺。 不耐烦的人可能会得出 Scrum 不起作用的结论：“嘿，看看这烂摊子！ 团队在第一个 sprint 中没有产生任何有用的东西，他们有一半的时间在便签上争论数字！” 要有耐心，给团队时间犯错并从中吸取教训。

当您学习弹吉他（或任何乐器）时，最初听起来会很糟糕。 这并不意味着仪器不起作用，它只是意味着您应该继续练习并观察渐进式改进。

那么，如果我们的耐心耗尽了怎么办？ 如果团队执行了几次冲刺但没有交付任何东西怎么办？

诊断 4：不适应流程

假设您几个月来一直在“按原样”进行 Scrum，并且您一直在为同样的问题苦苦思索。 如果你继续这样做，那么你可能会（错误地认为由 Scrum 引发的痛苦，总是“好的痛苦”），。
是时候发展您自己的 Scrum 流程了。

是的，您可以更改 Scrum。 你应该。 但只有在您确定诊断 1、2 和 3 不适用之后。

花费太多时间争论任务估计？ 消除任务估计，或完全消除任务。

花太多时间争论故事估计？ 改为估算 T 恤尺寸 (S/M/L)，或完全停止估算。 速度可以基于计算故事而不是计算故事点数。

无法弄清楚如何以一致的方式将 15 人分成更小的团队？ 让它们在逐个特征的基础上有机地形成和改革。

产品负责人是否迫切希望在 sprint 中改变事物？ 让他们在冲刺期间交换一个新故事怎么样，只要他们取出一个尚未开始的现有故事？

这些变化会让情况变得更好吗？ 你不试试就知道了。

这还是scrum吗？我不确定，但这真的很重要吗？任何对你有用的都是对的，任何不适合你的都是错的。谨防 （害怕做错 Scrum。症状：陷入困惑中）

诊断5：使用错误的流程

在某些情况下，Scrum 是不合适的。

假设我们有一个运营、维护或支持团队，其主要目的是反应性。 他们每天都会进行小错误修复和增强。 这些不能分批处理到冲刺中，因为优先级变化太快。 当团队有时间时，他们会致力于长期运行的改进。 这些长时间运行的任务的大小不能很好地适应冲刺； 它们被分成代表客户价值的块。

在这种情况下，冲刺和相关的计划会议会让人觉得是在浪费时间。

Scrum 的其他部分——跨职能团队、日常会议，所有这些都可以。 迭代和其他节奏可能没问题。 但是冲刺是一个有时间限制的、固定范围的迭代，有时这不是工作的正确工具。

在这些情况下， 看板 正在快速传播。看板的 WIP 限制提供了与 Scrum 中的冲刺相同类型的正“交付压力”，但方式不同。迭代并不是实现敏捷的唯一方式，事实上，在 甚至没有提到迭代 敏捷宣言 或 敏捷原则中 。

总结：当 Scrum 不起作用时怎么办

这里的关键是，不要急于下结论。 像任何好医生一样，在提出补救措施之前先诊断问题（因果图对此很有效）。

区分“使用错误的工具”和“错误的使用工具”。 无论你做什么，都不要责怪工具。Scrum 不会成功或失败，人们会。 人们选择在何处、何时、如何以及为何应用 Scrum。