你是如何与难相处和不合作的人一起工作的?与那些好斗的或不专业的人呢?与那些积极反对议程的人呢?
Will Jessup 提到:开发人员通常有高智商,常不会我们说什么就去做什么。他以下面的一段对话为例:
“好了,我们来为这些卡片做做评估吧”
“为什么?我讨厌做评估”
“为了知道这个项目要用多长时间,那你有什么更好的办法来获取关于我们最佳评估的客户信息么?没有这个我们的预算就没法审批通过,没人会付钱。”
“嗯…不”
“如果我们做了这一评估,我们能得到完整的 bs(译注:应指的是 Breakdown structure)、整体估算、基于我们了解的一些职员变化评估出的时间表——至少我们有了些东西。”
“好的 =]”
Kevin Shine 建议,我们应该从说服他们接受转变为让他们出于自己意愿主动参与:“这两种思维方式差距很大。一种是协作的、合作的方式,另一种则更多是命令和控制式的。”他接着建议提供建议和支持,让团队得出自己的结论。最后,他说道:“不能强迫他们改变。相反,应向他们展现可能的未来并帮他们参与开创这样的未来。”
- 问个问题,如“为什么不”——而不是试图替你的方式辩护,问他们为什么你的方式不起作用。
- 要摆脱对抗,可以问“我们应该做什么?”而不是问“她”必须做什么。也许这样问能帮她意识到问题,然后她会找出问题所在。通常需要问许多问题才能找到根源。
- 参考外部专家的意见。
Bachan Anand 问团队是否意识到了问题,并说如果没有预见到这是个问题就无法改进。另外,他还指出,一名新 Scrum Master 需要时间来赢得团队的尊敬和信任。
Ashish Mahajan 提醒我们 Scrum 只是工具而非目标。如果缺少清晰的、有说服力的(目标)以及紧迫感,团队就无法承担责任。Ashish 建议通过 1-1 培训、根本原因分析、严格使用回顾来帮助团队成员自己发现问题。
George Dinwiddie 建议从他人的视角看问题。为什么他们会有这样的反应?什么是他们相信的,并能解释他们的行为?他推荐 Dale Emery 的“ Resistance as a Resource ”,还有 Esther Derby 的反馈。George 还整理了一个关于反馈的文章目录。
本文记者提到,让人们接受观点很难(如果不是不可能的话),而聆听则会更容易些。问别人些问题,设法了解他们的问题,不是他们在 Scrum 上的问题,而是更大的问题。用 Scrum 来帮助他们解决这些问题,他们会更快地发现它的价值。另外,他还建议:
‘为什么’是一个有潜在威胁的问题,这一问题很可能让被问的人处于防御姿态。问问‘什么 / 何时 / 在那儿’这类问题,能帮我们得到想要的结果,而不会面对防御性的反应。不要问“为什么不”,试试“计划扑克不起作用,你怎么看?”或是“是否能告诉我你认为问题是什么么?”这样我们就把焦点从人转移到问题上了。
查看英文原文: Working with Difficult People and Resistance in Scrum
评论