01、TL;DR:一个团队什么时候应该停止使用Scrum?
什么时候才能超越Scrum?毕竟许多类似思想、实践等事务迟早会过时;那为什么Scrum会是个例外?此外，我们不是通过实践Scrum来获得报酬，而是在既定的约束条件下解决客户的问题，同时又能为组织的可持续发展作出贡献。Scrum是一种工具，一种有用的实践，它既不是宗教，也不是哲学。这让我们回到了最初的问题:是否在某一个时刻，Scrum团队应该停止使用Scrum?
02、设置使用Scrum的环境以使您受益
当我问Scrum团队是否在某个时刻应该停止使用Scrum时，我的意思并不是说一开始使用Scrum是毫无用处的。例如，如果你看到下面的Stacey矩阵，你会注意到用红色表示的区域：简单和混乱。
- "简单 "不需要精心设计的风险缓解策略，因为最佳实践通常是有效的;你不需要一个冲刺计划来准备一个(你选择的大汉堡)有薯条和苏打水的菜单。
- 在光谱的另一端，“混乱”的重点是在无秩序的状态下保持稳定。当我们处理新的实践时，短期的行动-感觉-回应方法是有益的，但考虑到sprint作为中心计划实例的重要性，这不一定是Scrum的强项。
因此，这两个领域从一开始就不适合使用Scrum。
我也不是指你的团队因为技术原因未能解决客户所认为的问题或者因为根本就没有问题需要解决的情况。(因为我们都知道，很多初创企业都没有找到值得解决的问题;我自己也遇到过这样的情况。)最后，我也并不是指那些认为在任何情况下使用Scrum都是不利的专家，你根本不应该掺和到他们中去。
在本文中，我指的是一个能解决客户问题的 Scrum 团队。一个随着时间的推移对问题和解决方案空间有很好理解的团队。我想到的是一个 Scrum 团队，它体现了良好的 Scrum 应用的理念，在组织中享有良好的声望。然而，这个团队是否会遇到Scrum不再有用的情况呢?或者他们会永远快乐地应用Scrum吗？
03、导致重新考虑Scrum的演变
我过去观察到的是，由于Scrum团队的成功工作所带来的缓慢但稳定的发展，进一步向产品生命周期的成熟阶段迈进。一开始是对未知领域的探索，比如在团队最初知之甚少的领域中，什么东西是值得构建的。后来变成了有条不紊地推进，随着Scrum团队对主要挑战的掌握，需要做风险缓解的情况也越来越少。
回到Stacy矩阵，Scrum团队从“难懂的”[1]转移到“难处理的”[2]。
04、Scrum团队如何注意到他们何时从"难懂的"变为"难处理的"？
一些指标可以帮助 Scrum 团队理解他们作为一个团队所取得的进步，以及产品的日益成熟，也可以帮助证明他们最初使用 Scrum 的决定是否正确，例如:
- 产品成熟度的提高会使开发过程变得更加稳定，而且波动更小;在交付增量时中断变少。
- 可以得分的匹配点更少了，进展变得更加循序渐进，因为“大功能”已经具备，现在专注于小的改进。
- Scrum 团队在创建团队统一的 Sprint 目标方面遇到越来越多的困难; 越来越多的产品待办事项不能集中在一个主题下。
- 波动性的降低导致了规划范围的扩大。至少，人们会忍不住提前进行计划，这也适合团队的利益相关者的关系管理。(Scrum 团队最好通过枯燥而可靠的交付来与利益相关者建立信任。)
- 利益相关者对团队的能力有了更多的信任，例如在Sprint评审中的参与减少了。(当Scrum团队成功地交付有价值的增量并允许你做你自己的计划时，为什么还要作为利益相关者对他们呼来唤去呢？)
- 打个比方，Scrum团队从跳跃式前进过渡到稳步前进。
根据我的经验，没有唯一的阈值表明完成了从“难懂的”到“难处理的”的转换。相反，注意到这个缓慢而不明显的过程需要Scrum Master和所有团队成员的专门观察。此外，它还需要心理安全感来挑战正常工作的规律。正如前面所提到的: 我们不是通过实践Scrum来获得报酬，而是在既定的约束条件下解决客户的问题，同时又能为组织的可持续发展作出贡献。
05、结论:什么时候应该停止使用Scrum？
在某个时刻选择Scrum并不意味着我们将永远使用Scrum。可能有一天，我们决定停止使用Scrum，因为它不再服务于最初的目的:在降低风险的同时找出值得构建的东西。当我们注意到我们的工作方式与另一种方法存在竞争时，如果新的工作方式能带来更好的投资回报，我们就应该考虑并可能调整我们使用Scrum的决定。(不过，请注意，我所说的“投资回报”并不仅仅是从财务角度考虑的。还有其他因素，例如团队健康或产品质量。)像往常一样，在这个过程的早期让所有团队成员参与进来是个好主意。你有没有和一个决定停止使用Scrum的团队合作过?如果有，请在评论中与我们分享: 他们为得出这一结论采取了哪些步骤，结果如何？
