你是如何与难相处和不合作的人一起工作的？与那些好斗的或不专业的人呢？与那些积极反对议程的人呢？
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
中国开发者画像洞察研究报告 2024
分析开发者的行为模式、工作价值、职业发展等内容，帮助整个行业生态更深入地理解开发者，为他们提供更精准...
评论