我在软件开发领域已经工作了10年了。大约8年前，我的公司开始了将所有项目转向采用Scrum框架的历程。作为一个年轻的开发人员，我们的管理层告诉我，Scrum可以让我们更好地管理自己的任务。一开始，我对这个想法很兴奋，因为我认为这意味着我们可以更好地平衡工作和生活，但是，天哪，我错了。这些是我采用Scrum框架的经验:
大多数公司不能用Scrum工作，因为他们有严格的截止完成日期。
Scrum所教授的课程之一是产品积压项目的优先顺序和去优先化。然而，在大多数情况下，这一点并没有得到尊重，或者说他们根本无法得到尊重。
在我们的Sprints过程中，通常会发现更多的PBI和任务，而且在大多数情况下，没有任何东西可以被取消优先级；比如，谁会为一个他们不需要的功能付钱呢？从理论上讲，这意味着交付日期应该推后，但在现实中，开发人员往往在他们的能力范围之外工作......。
哦......，那么你的开发团队只是不善于计划？你说得太对了，我们不善于计划！！！你知道需要多少计划吗？你知道在Scrum中需要多少计划吗？你期望用户和开发团队一起坐下来，看看他们所有的用户故事，然后开始把它们分解成PBIs吗？这需要几个小时，甚至几天的时间；用户也有自己的核心工作，所以没有人有这样的时间...... 事实上，大多数时候，用户甚至不知道他们有哪些PBIs，因为...... 他们不知道如何将他们的用户故事分解成PBIs，以及2.
用户没有时间去写需求... 有一个用户走过来对我说，嘿，伙计，你知道在我们开始使用Scrum来运行我们的项目之前，我有几个月的时间来考虑我的需求，并把它们详细地记录成适当的用例，但现在，我只是被推入项目，并被期望在你们编码时拿出它们。对我来说，要跟上并真正想清楚我的需求和测试方案是非常困难的。
用户必须经历毫无意义的站立会议、冲刺计划等。在这一点上，他们只是在那里，因为框架是这样说的。作为Scrum主管，大多数时候，我会告诉他们，他们在那里是可有可无的，因为他们不需要听，XXX已经连续第三天得到一个空指针异常了！"。
下降图是个骗局。我不知道大多数Scrum团队的情况，但我通常不会听到人们在燃烧。如果图表一直在下降，这就是好事，不是吗？不，不是的；它只是意味着时间已经过去，但这并不意味着工作已经完成。从现实的角度来看，我们也需要燃烧起来......
管理层希望看到 "进度表"。比如说，来吧! 这只是微观管理......如果图表顺利烧毁，他们会认为项目进展顺利，而且他们会质疑每一个峰值。试图向他们解释每一个小的峰值只是一种巨大的时间浪费......因为它通常归结为，没有足够的时间，或者资源。
能力也是一个骗局。员工们通常会有临时的工作，或者在Sprints中间开会；几乎不可能考虑到这些事情。
在每个Sprint周期后交付一个功能是可笑的，而且几乎不可能...... 首先，我们强调开发人员要在很短的时间内开发一些东西，但却承诺他们只需要在自己的能力范围内工作...... 其次，用户通常不会仅仅测试一个功能的部分......他们需要测试整个系统。他们需要对整个系统进行测试，以确保它在整合后能正常工作。即使他们同意按特性进行测试，他们也会在完成后重新测试所有东西；这只是在浪费大家的时间。另外，如果发现任何bug，开发人员必须花时间来修复它们，这就占用了下一个Sprint周期的开发时间......
Scrum希望我们对所有的事情进行微观规划，使之达到几乎精确的程度，这实在是太荒谬了，太耗时了，也太累了。有人记得我们在Scrum之前是如何工作的吗？当我们进行开发时，我们会定期给我们的用户发送一些截图，以确保我们在正确的轨道上；这与Scrum教练告诉我们的由于在瀑布法中缺乏沟通而呈现出完全不同的产品的恐怖故事相反。这真的是关于人的问题，而不是关于所使用的方法学。