一般情况下，在我的ScrumMaster认证课的第一天开始时，我会跟学员一起过一下为期2天的课程的日程安排。课程中安排了关于“会议”的话题，通常，我会顺便指出scrum被人抱怨例行会议太多，但是我会接着声明，这是个很容易被反驳的观点，因为大多数会议都不是很长。如果非要批判scrum的话，应该能找到比“scrum导致团队沟通太多”更好的理由。
说完以上那些话，我总是期待某个学员能叫我马上说出几个理由来。但是，通常没人提出来，我也就转到下一个话题了。
然而，我认为保持批判性很重要，因此，我借这篇博文来批判一下Scrum。
我对Scrum最强烈的不满就是，很多Scrum团队太过专注于检查是否在某个时间箱里完成了工作，而没有花精力为他们所面临的问题寻找更具创新意义的解决方案。
在上世纪90年代中期，Scrum都是被用来寻找创新的解决方案的（我是这样做的，我看到别人也是这样做的）。团队接受一个难题，并被分配了一个月（或四周）来解决这个问题。拥有如此长的时间，因而团队能够尝试一个或更多的潜在解决方案，一旦尝试失败，也能从容地退而求其次，转而采用已知的更保守的、确实有效的方法。
在如今的Scrum版本中，许多团队已经变得过度沉迷于确保完成一切承诺要完成的工作。这导致这些团队一开始就采用了保守的方法。许多团队从没有尝试过任何疯狂想法，来寻找创新方法。
我完全相信这是sprint变短导致的结果（sprint通常是两个星期）。如果一个可能有效但是又有些风险的实验性方法未能成功，那么这个较短的sprint就没有足够的时间来使用保守方法重新来过了。
两周长的sprint如此普遍，我愿意承担一份“责任”。我承认这是我偏爱的长度，而且，我还认为对于大多数团队来说两个星期是个合适的长度。如果我对团队不是很了解的话，两个星期会是我给出的默认建议。
因此，对于许多团队，sprint变得越短，他们在创意、试验和突破性想法上的牺牲就越多。
我不认为应对办法是所有团队立即恢复到四周的sprint。因为我觉得成熟的Scrum团队已经找到了一种平衡，他们能从偶尔的创新探索中获得益处。
以上是我对Scrum最大的抱怨，也是我在如今的实施过程中看到的。那你呢？你有没发现Scrum定义或者实施过程中存在些不合理的东西呢？
原作者：Mike Cohn 译者：Scrum中文网
英文出处：http://www.mountaingoatsoftware.com/blog/my-primary-criticism-of-scrum
