scrum团队会议太多了吗

Scrum团队的会议太多了吗?

在进行CSM(认证Scrum Master)授课时,我听到的最常批评之一是“Scrum团队有太多的会议了”。

由于Scrum具有每日Scrum站会、Sprint计划会议、Sprint评审会议、Sprint回顾会议,甚至可能还有产品待办列表精化会议,也就不难理解为什么人们会这样评论。

但是让我们看看这是不是真的。

一个实验

这里有一个实验,我希望你能试试,尤其是如果你认为Scrum会议太多。

从5-10中选择一个随机数。然后回想一下,你的团队是什么时候开始以敏捷方式开始工作的,或者他们是什么时候开始能较好地以敏捷方式工作的。

在你的工作日历(无论是在outlook、Google、苹果日历,或者其他什么程序)中,定位到这个月。现在,记得你在上一段中选择的随机数吗?再向前回滚随机数所对应的月数。

因此,例如,假设你们团队在十月份开始掌握敏捷的诀窍,而且你选择了5这个随机数。那样的话,你需要从十月向前回滚五个月,即查看五月份。

接下来,审视那个月的情况,记下你在这个月的所有会议。如果你和我以前做过同样的事情,你可能会发现在敏捷转型之前你已经有了同样多或者更多的会议——只是会议不同而已。

您可能偶尔会与相关干系人开会。你会和你的老板召开一次周会。你可能会有几个工作小组。然后会有设计评审会,可能是评审设计、技术、数据库或别的什么。你可能有一个周例会。

可能还有些代码审查或评审会。可能在白板前会有些一次性的设计讨论会。加上几个电话会议。此外还需要考虑的是,你可能会有一些会议并没有排入日历中,所以你现在可能看不到。

完全有可能你敏捷前的会议数量比敏捷后还多。

当然绝不会对每个人来说都是这样的。但是,在我亲自进行这项实验时,有大约一半的人在开始Scrum之前有更多的会议。而最有可能在敏捷转型前拥有更多会议的人,是那些需要与其他人协同工作的团队成员。

为什么我们会觉得Scrum有太多的会议?

那么,为什么会普遍感觉Scrum有太多的会议呢?

是因为这些会议都有名字。当我们给某个事物命名时,它就可能会成为批评的对象。人们会抱怨“那些该死的Sprint计划会议”以及“烦人的每日Scrum站会”(他们可能会使用更丰富多彩的语言来抱怨)。

在Scrum之前你日程上的大多数会议都是没有名字的,而且也不是例行进行的会议。他们更像是“与玛丽的设计讨论会”、“与阿施施的代码审查会,”或“珍妮特的测试用例讨论会”。

你可能有过很多设计讨论会,但他们并不全是与玛丽一起召开的,也绝对不会有“与玛丽的讨论设计会”这种正式名称。

而当一个会议例行进行的并且被命名时,遭受批评也就变得容易多了。

如果Scrum运行的好,给人的感觉是帮助而非累赘。

Scrum的会议绝对有可能会成为累赘。并且,确实有很多团队在开会上花费了太长的时间。每当向一个团队建议多花点时间在某个Scrum会议上时,我都必定会告诉二十个或者三十个团队要减少会议时间。(尤为常见的是冗长的Sprint计划会议和产品代办列表精化会议。)

但是,一旦做得好,Scrum就会帮助而非妨碍产品的快速开发。每个会议都应该做到类似于:

  • 正确的时间
  •  正确的时长
  • 正确的与会人员
  • 以及正确的详细程度

Scrum框架的设置使这成为可能。如果一个Scrum团队对其会议不太感兴趣,那么Scrum Master应该仔细审视一下会议是如何进行的。

很可能,会议应该继续进行,但要更有效率,而不是放弃会议。

总会有些团队成员会批评任何会议。对某些人来说,就算是十年开一次会,仍然会嫌多。但是,一旦会议运作的很好,许多Scrum团队成员就会发现,他们在会议上花费的时间会比采用Scrum之前更少。

 

原文链接:https://www.mountaingoatsoftware.com/blog/do-scrum-teams-meet-too-much

作者:Mike Cohn

译者:李洁(Jerry Li)