我对Scrum的批评

一般情况下,在我的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