如果您的团队成员在 Scrum 会议期间不合作,您会怎么做?他们要么对他们当前正在处理的内容提供非常高层次的定义(“正在处理功能 x”),要么进入极其不相关的细节, 尽管受过良好的 SCRUM 方法教育。这导致scrum会议效率低下且无聊。

作为一名 Scrum Master,你有什么技巧可以在会议期间让人们发挥出最好的水平?

编辑添加:

你用什么技巧来制止说话过多的人而不冒犯别人?

您使用什么技巧来鼓励某人提供更详细的答案?

当你发现自己是唯一一个在倾听的人,而其他团队成员只是坐在那里甚至可能睡着时,你会作何反应?

有帮助吗?

解决方案

首先...确保人们都站起来......甚至不靠在墙上或桌子上。

从高层次上来说,我想说,每当你在团队中遇到问题时,最好的回应就是 询问团队 寻求解决方案。但是,以下是我用于解决您所面临问题的一​​些技术。

话太多

  • 让他/她单腿站立
  • 让他/她在发言时伸出手握住 scrum“发言”令牌。
  • 向 scrum 添加活动挂图以列出已提出的问题...当有人在不值得参加 Scrum 会议的话题上啰嗦时,打断他并说“嘿 - 说得好。我不确定每个人都需要讨论这个问题,如果我们把这个问题留作后续讨论怎么样?” 成功的关键是事后实际跟进并安排私下谈话。或者,说话者可能只是说“没必要......今天下午我将与乔一起处理“这个”或类似的事情,这可以实现减少风气的目标,而无需安排后续行动。

需要更多细节. 。这是为了 Scrum Master 还是团队的利益?

  • 等到之后再问个人更详细的问题。如果您认为团队也需要了解它们,请通过(在您的 scrum 后提问中)传达“我认为乔·史密斯听到您的意见会对这种事情有所帮助,您认为如何”来指导团队成员?”

团队不听.

  • 逐一询问他们。“Sally,我注意到你似乎并没有从 Scrum 中获益匪浅。我们如何调整它以使其对您有价值?”。
  • 在 scrum 期间向其他人发布问题。就像莎莉(Sally)说“我昨天与鲍勃(Bob)的代码集成在一起”,问鲍勃“那怎么样?” (我很少使用这个...以防止 scrum 花费太长时间)。
  • 我发现有时团队成员会养成老习惯,在 Scrum Master 或项目经理讲话时看着他们。当这种情况经常发生时,我会改变视线,将目光移开,这几乎迫使演讲者与团队中的其他成员进行目光接触,这可能有助于团队中其他成员的注意力。

其他提示

如果时间管理是你的问题。准备一个计时器,并在时间用完时让某人按响铃。确保任务被分解到足够的粒度——任何任务的时间都应该在 4 小时到 2 天之间。最多 3 天。在人们注册之前,任何高于此的内容都会进一步分解。

我认为这三个问题是:

  • 你昨天做了什么?
  • 你今天打算做什么?
  • 您在前进的道路上看到了哪些障碍?

细粒度任务(迭代后计划)应满足要点 1 和 2。第三个实际上取决于环境条件。随着时间的推移,计时器应该下意识地促使成员思考他们的问题并构造简短的句子。专注于具体的障碍,而不是解释原因或先决条件或其他什么。如果您与一个人谈论仅与你们俩相关的事情超过 5 分钟。停下来,做个笔记(稍后在他们的办公桌上谈话)然后继续前进。

更新:还要确保每个人都明白在 Scrum 会议之前进行“排练”可以节省每个人的时间。 思考 讨论你想传达什么,而不是直接参加站立会议。

他们应该说的是他们所取得的成就,而不是他们所做的工作,如果他们一无所获,那么是什么阻止了他们取得成就。

所提出的问题可以用不同的措辞

  1. 自上次会议以来我完成了什么?
  2. 在下次会议之前我要完成什么?
  3. 我的道路上有什么(障碍)?

同样重要的是,会议不是团队向 Scrum Master 报告,而是团队相互检查。如果人们直接对你(Scrum Master)说话,有一些技巧可以转移焦点。确保你不要看演讲者,甚至不要后退,这样视线就会改变,他们在说话时被迫看着队友。不过要微妙一点:)

编辑:

我抄袭自http://www.implementingscrum.com/2007/04/02/work-naked/

当你发现自己是唯一一个倾听的人,而其他团队成员只是倾听时,你会如何反应 甚至可能睡着了?

嗯,你们真的在开站立会议吗?这听起来可能很做作,但除了让人们更难入睡之外,它还有助于营造一种快速挤在一起而不是悠闲开会的感觉。

我看到的改进之一是使用“说话棒”(我们实际上使用软球)。它可以额外关注当前正在讲话的人,并使与另一个人的过渡更加明显。

当你发现自己是唯一一个在倾听的人,而其他团队成员只是坐在那里甚至可能睡着时,你会作何反应?

如果我已经听过其他人所说的话,我会问一个没有关注这可能会如何影响他们正在做的事情的人的问题。非常喜欢学校老师,但这足以让他们再次回应并参与会议。

我也同意 基夫

为了让您的团队参与其中,他们必须看到其中的价值,而不仅仅是因为您告诉他们这样做而这样做。

Scrum 是一个站立会议,“说话棒”的概念是一个很好的观点。

这里的关键不是你有一个或几个不合作的团队成员,而是在我看来,一个更根本的问题:Scrum 团队应该是自我管理的,而 Scrum 会议的目的是保持 团队 告知。如果其他团队成员没有要求澄清并指出不合作的成员,那么就需要进行 Scrum 的再教育。

请记住,Scrum Master 并不是被报告的对象,他/她只是消除流程障碍的人。这确实包括促进 Scrum 会议,但团队确实有责任独立于 Scrum Master 来理解并要求澄清。

询问您需要的具体细节。人们不会知道你感兴趣的东西。

还要尝试提出一些指导方针,以便在会议前进行更好、更有效的演示。

在 Scrum 会议之外与他们交谈,并告诉他们其他人如何看待他们展示当前工作的方式。我认为他们并不是故意不合作,只是不习惯 Scrum 会议应有的详细程度。

您还可以询问他们在会议期间希望从其他人那里获得多少信息。

您所说的“scrum 会议”是指每天的“站会”吗?如果是这样,我相信这些时间通常控制在 15-20 分钟左右。所以把时间平均分配给每个人,一旦有人用完所有的时间,他就不能说话了。这可能很残酷,但我相信这就是应该发生的事情。

Scrum 是一个自下而上的过程,因此原则上每个团队成员都应该支持该过程。

团队是如何组建的?是因为组织传统还是因为共同目标?

并不是每个人都认同 Scrum 理念,我们应该尊重这一点。也许对所有人来说最好的是这些成员不是 Scrum 团队的一部分?

有些人只是不明白需要什么。您可以尝试使用一些关键短语来引导对话。

如果有人提供了太多细节,那么你可以尝试用“还有什么”来打断他们。这将暗示他们已经完成了这一点。或者您可以尝试“好吧,我们可以讨论一下离线”类型的方向。

对于不相信的人,可以询问他们做了什么以及将要做什么。

为了便于讨论,假设某人确实有一些事情需要告诉团队,并且需要一些时间。您是否有合适的地点、时间或方法(电子邮件、其他类型的会议、午餐时间)来执行此操作?只需打断对方的话,让他们知道不适合举行站立会议。

另外,这在开发过程中会产生什么问题?如果由于缺乏沟通而出现错误,人们需要面对为什么他们在站立会议期间不提及这些事情。

  • 您可以计划最大平均时间来解释您做了什么以及将要做什么。
  • 对于那些不愿意说太多的人,我想 Scrum Master 有责任鼓励人们更清楚地了解他的任务。
  • 如果人们仍然不分享他们正在做的事情,一个根本的解决方案是使用画布板,团队中的人员必须将他们正在做的任务移动到各自的区域(在开发中,准备验证,在代码审查中) 。然后你就可以确定他正在从事哪项任务。
  • 每次日常会议结束后,记得询问障碍或任何类型的问题,有时人们不记得在他的时间说或不想分享他们的问题。
许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top