干系人懒得参加 Sprint 评审会?7招搞定

Sprint 评审会(Sprint Review)是一种能让干系人至少每几周参与到项目中来的固定方式。Sprint评审会是团队拿着构建好的功能,和需要这些功能的人进行交流的时机。

因此,Sprint评审会可能是每个迭代中最让人兴奋的会议。然而,事实中的评审会往往事与愿违,干系人或者不来参加,或者觉得无聊,又或者只是消极的坐着等待会议结束。

Sprint 评审会是协作的关键时刻。

  • Scrum Master、产品负责人和开发人员需要(且应该)得到对于已交付功能的反馈,以及关于下一步交付内容的想法。

  • 干系人需要(且应该)了解产品或服务的进展情况,同时他们希望引导项目往正确的方向发展。

我见过数百个团队的低效Sprint评审会。我还总结了七种方法来帮助团队和干系人把Sprint评审会变得更有趣和有吸引力。

1. 选择合适的日期和时间

有时,评审会的出席率很低,仅仅是因为会议召开的时间或是日期不合适。
我曾经合作过的一个团队,Sprint周期是一星期,每周五结束。他们把Sprint 评审会安排在周一早上10 点,以确保开会前大家都到办公室了。
参加的人寥寥无几。Scrum Master很困惑,因为干系人在其他方面都和团队积极合作。经过询问,Scrum Master很快就发现了问题所在。许多位干系人都向同一名主管汇报,他们每周一午餐时会召开员工会议。这位主管很难取悦,所以大家经常要在周一早上花几个小时为会议做准备。这段准备时间让那些关键干系人没法来参加Sprint评审会。

如果你的评审会参与率不高,请先从简单的原因和解决方案入手,例如日期和时间是否对潜在参会者造成不便。

2. 让干系人参与到评审的过程中

如果干系人不来参加你的Sprint评审会,请先反思一下。也许你的评审会太过枯燥乏味,没办法吸引利他们来参加。

如果团队把Sprint期间所做的一切工作都演示一遍,那评审会可能会变得很无聊。例如,只能用一种方式修复的错误就没有必要演示了,只需告诉相关的干系人这个错误已经修复,然后继续。如果他们确实想要看一下细节,再进行演示,通常他们可能并不会这样要求。
当讨论拖得太久时,评审也会变得枯燥。不论是由谁主持评审会(通常会是 Scrum Master),都必须注意让大家的讨论紧扣主题,保持参与度。

图片

讨论对于在会议期间收集反馈是至关重要的。但要小心不要讨论得过于深入,除非约有四分之三的参会者都需要加入讨论。
如果一小部分参会者需要花更多时间来讨论某件事,请先记下来。告诉大家你会安排后续的沟通或会议,然后继续其他议题。

还有一个让会议更不枯燥的方法,是让干系人直接参与进来。把键盘或App的控制权交给他们。如果在你描述产品的同时,一位干系人正在操作,其他人也会振作起来,给予更多关注。

Sprint 评审

3. 让干系人认同评审会的重要性

你和我都知道什么是Sprint评审以及为什么干系人应该腾出时间参与评审。但是Scrum 团队之外的人理解评审会和干系人参与度的重要性吗?也许并不。

除非你明确告知干系人评审会是一个什么样的会议,他们将如何参与进来,又会做出哪些决策,否则他们很可能会认为没有参加的必要。

怎样能获得干系人对Sprint评审会的支持和认同?
我的一种方法是在日历邀请中加入议程。在议程中,我列出了Sprint 目标和将要讨论的产品待办项,以及需要在评审会期间做出的关键决策。
有了这些信息,潜在的参与者就可以决定他们是否应该参加。例如,我记得有一次团队计划在评审会中展示他们在Sprint期间完成的可用性方面的改进,一位在可用性方面并不专业的重要干系人决定他不需要参加这次会议。
在这种情况下,我认为这是一个正确的决定。只需要公布Sprint目标,将要评审的用户故事,以及要做出的决定,就能很好的帮助人们决定是否来参加。

你可能会发现更多的人选择参加,但就像这位分析总监一样,也会有一些人选择放弃偶尔的评审。这对团队来说也是一种胜利,因为干系人知道了我们尊重他们的时间。

4. 让评审会保持简短

我讨厌冗长的会议。会议时间一旦超过 90 分钟,我就会非常焦躁不安。我不是一个人。
Sprint评审会的主持人需要保持会议快节奏进行。
让评审快速进行的一个简单方法是提前计划好由谁来做什么。商定将要演示哪些产品待办项,按什么顺序以及由谁来演示。如果没有提前准备好这些,对干系人是不太尊重的。
此外,还可以考虑在评审会中加入一些娱乐元素,来增加一点小乐趣,吸引大家的注意力,或者破冰。当然,这并不是说你必须想方设法让每个评审会都变成“马戏之王”,但稍许花哨一点也无妨。

让参会者想要得到更多,而不是希望会议时间更短。通过提及(不是展示)细微的变化,或者演示某个新功能的80% 而不是每个小细节来做到这一点。如果有人询问,再进行其余部分的演示。

5. 征求反馈并认真对待

Sprint 评审是一个双向的活动。是一场对话,而不是演示。并不是所有团队都了解其中的差异。我参加过太多没有请干系人分享观点的评审会。
如果我每隔几周就被邀请参加一次会议,并要求我坐在那里听演讲,没有机会分享我的意见,那我肯定不会再去了。所以,如果你不征求干系人的意见,也不要为他们不出现在会议上感到惊讶。
当然,更糟糕的是在征求干系人的意见后,却又不采取行动。我并不是指团队必须采纳每个干系人提出的建议,但至少应该对每一条都认真考虑。

Sprint 评审

这里的解决方案有两个方面:
  • 首先,在开始演示每个产品待办项的同时,询问干系人的想法。

  • 其次,如果没有得到答复,尝试询问更具体的问题或询问特定的人。
从一位较资深的干系人开始,询问演示内容中的具体部分。或者询问某类用户是否更喜欢不同的东西。
通常,一旦开始得到反馈,其他人就自然会进行补充。
之后,请务必要考虑所得到的意见。最好能尽快采纳其中的一些意见,以便让干系人看到他们的反馈确实很重要。请务必在下一次的评审会中指出这些变化,并提醒大家这些改进是反馈带来的结果。

 

6. 当进展可见时进行评审

鼓励干系人参与 Sprint 评审的第六种方法和前几个不太一样。有时开发团队没有太多可展示的内容,所以人们会觉得不值得花时间。
这种情况可能会发生在进行为期一周的短迭代的团队中。许多产品或系统都很复杂,需要时间来完成工作。团队可能会在一周内完成用户故事或其他产品待办项。但对于为期一周的 Sprint,这些待办项可能非常小 —— 也许太小而不足以给干系人留下什么深刻印象。
你有没有这样一位朋友,他一直在减肥,但减的速度非常慢?也许他一年内减了十几斤,这很棒。但如果你每周或每天都见到他的话,这些体重变化可能并不会很显眼。
短迭代也是如此,尤其是对于复杂的产品或系统。
如果你觉得这可能是干系人不参会的原因,那么首先要做的就是询问他们。如果他们确认这是原因之一,可以考虑适当延长迭代周期。或者保留短迭代,但每隔一个迭代再开展一次 Sprint 评审会。

我知道这有悖于 Scrum 的规则,但你计算一下,如果团队跑一周的迭代,但每两周开一次评审会,那么他们的评审会频率依旧是跑四周迭代的团队的两倍。团队可能有很多理由想要维持一周的迭代周期,而不是直接延长迭代时间。

 

7. 为忙碌的干系人寻找解决方案

你的干系人都很忙。我深知这一点,因为我上一次遇到不忙的人还是在 1993 年。项目的干系人通常都是非常忙碌的,他们有自己的日常职责,然后又在开发中的产品中承担了新的职责。
要证明在评审会中投入时间是值得的,有一个方法是让大家知道这可以为后续节省下很多时间。在每次评审中投入少量时间,可以省下日后可能不必要的时间花费。它有助于避免问题,并在项目早期消除任何潜在的不确定因素。
我曾经参与过一个呼叫中心系统的项目。开发人员和 Scrum Master 根本不被允许和干系人沟通,甚至在评审会上也不行。原因是这些呼叫中心的客服人员都太忙了(这也正是他们需要新软件的原因)。
但由于无法直接了解到他们的一手需求,我们做了一些错误的决定。
一切沟通都必须得通过产品负责人来进行,这对于项目中的一百多名开发人员来说,完全不是一个行得通的解决方案。

Sprint 评审

如果你的干系人因为太忙而无法参会,你有两个选择:

1、向他们宣传 Sprint 评审会的价值。

2、让不同的干系人参与进来。
你可能已经尝试过解释评审会的价值。如果这个方法以前行不通,那么现在也很可能不起作用,除非你可以举一些例子来说明如果定期进行评审就可以避免的混乱或问题。
让不同的干系人参与进来这个建议可能会让你觉得好笑,但我真心的认为这是一种选择。
我常常看到项目的干系人是组织中非常非常重要的角色。他们确实没有时间参与评审会,或是履行团队期望干系人承担的其他职责。
在这种情况下,解决方案是让这些潜在干系人意识到他们太忙了,并将干系人的角色委托给更有时间参与的人。
当你向干系人提出这个建议时,要避免听起来像是在指责他们没有做好本职工作。相反,要表现出对他们的努力表示赞赏和感激,再讨论他们委托代表而不是亲自参与项目的可能性。

我与许多干系人进行过这样的对话,他们听到我提出将责任委托出去的建议,显然松了口气。在内心深处,他们也知道这是正确的做法。

敏捷项目需要干系人的投入

干系人不参与 Sprint 评审是一个严重的问题。这会导致错误在流程后期才被发现,有时甚至会影响上线的最后期限。
缺乏干系人的参与也会向团队传达这样的信息:我们的产品并不重要。然而事实几乎肯定不是这样。

这篇文章中总结的七个技巧,应该可以帮助你解决干系人不参加Sprint评审会最常见的一些原因。

你怎么看?

你的Sprint评审会有过出席率很低的情况吗?你是否也在获得干系人支持方面遇到过困难?
都有哪些原因?你顺利解决了问题吗?本文描述的技巧是否对你有所帮助?你是否还尝试过其他的方法?
欢迎在评论区留言,分享你的想法和经验。

注:部分图片来源于网络

原文地址:

https://www.mountaingoatsoftware.com/blog/top-7-ways-to-get-stakeholders-to-attend-sprint-reviews

 

关于作者

Mike Cohn
Mike是敏捷联盟及Scrum联盟创始人之一,是帮助企业适应和改进敏捷过程及技术,以建立极致高效团队的专家。著有《用户故事与敏捷方法》,《敏捷估算与规划》,《Scrum敏捷软件开发》以及视频课程《更好的用户故事》。

 

火爆 售票中
Scrum.Org 主办
搜索
近期公开班
领导大规模敏捷Leading SAFe认证徽章
11月30-12月1日(周六、周日)
Leading SAFe领导大规模敏捷认证课
远程
Scott Wang 王庆付 授课
scrum alliance csm认证徽章
12月14-15日 (周六、周日)
Scrum Master (CSM) 中文认证课
远程
Lance Zhang 张宁宁 授课
safe scrum master ssm
12月14-15日(周六、周日)
SAFe ScrumMaster 官方认证公开班
远程
Eric Liao 廖靖斌 授课
Scrum.org专业Scrum产品负责人(PSPO)认证徽章
1月4-5日 (周六、周日)
专业Scrum产品负责人(PSPO)中文认证公开课
远程
Derek Ding 丁志润 授课
专业Scrum Master (PSM I) 认证徽章
11月16-17日 (周六、周日)
专业Scrum Master (PSM I) 认证公开课
远程
Derek Ding & Lorenz 授课
大规模敏捷顾问SAFe SPC认证课徽章
11月2-5日(周六-周二)
SAFe认证-SPC SAFe认证培训师导师班
上海-面授
Marsha Xue , Alex Guan 授课
safe scrum master ssm
8月10-11日
SAFe ScrumMaster 官方认证公开班
Eric Liao 廖靖斌 授课
scrum alliance csm认证徽章
11月09-10日
Scrum Master (CSM) 中文认证课
Lance Zhang 授课
scrum alliance csm认证徽章
10月26-27日
Scrum Master (CSM) 中文认证课
中文远程
Scott Dunn & Eric Liao 授课
领导大规模敏捷Leading SAFe认证徽章
10月19-20日
Leading SAFe领导大规模敏捷认证课
Eric Liao 廖靖斌 授课
Scrum联盟acsm认证徽章
10月19-20日
高级Scrum Master(A-CSM)认证公开课
Jim Wang 王军 授课
0
0
小时
0
分钟
0
由Scrum.org主办的 2024中国Scrum大会 8月17日将在上海开幕
0
0
小时
0
分钟
0
预约回电
留下您的手机号,我们会在第一时间联系您。
热线电话:400-696-6280
预约回电
预约成功,我们会尽快联系您。