在Scrum中与难相处的人和顽固的人一起工作

作者 Mark Levison 译者 陈宇 发布于 2010年11月28日

领域

过程 & 实践

主题

教练 ,

Scrum Master ,

敏捷实施 ,

教练和指导 ,

企业级敏捷 ,

Scrum ,

变更 ,

敏捷

分享到

你是如何与难相处和不合作的人一起工作的？与那些好斗的或不专业的人呢？与那些积极反对议程的人呢？

Will Jessup提到：开发人员通常有高智商，常不会我们说什么就去做什么。他以下面的一段对话为例：

“好了，我们来为这些卡片做做评估吧”
“为什么？我讨厌做评估”
“为了知道这个项目要用多长时间，那你有什么更好的办法来获取关于我们最佳评估的客户信息么？没有这个我们的预算就没法审批通过，没人会付钱。”
“嗯...不”
“如果我们做了这一评估，我们能得到完整的bs（译注：应指的是Breakdown structure）、整体估算、基于我们了解的一些职员变化评估出的时间表——至少我们有了些东西。”
“好的 =]”

Kevin Shine建议，我们应该从说服他们接受转变为让他们出于自己意愿主动参与：“这两种思维方式差距很大。一种是协作的、合作的方式，另一种则更多是命令和控制式的。”他接着建议提供建议和支持，让团队得出自己的结论。最后，他说道：“不能强迫他们改变。相反，应向他们展现可能的未来并帮他们参与开创这样的未来。”

Gustavo Cebrian Garcia：

• 问个问题，如“为什么不”——而不是试图替你的方式辩护，问他们为什么你的方式不起作用。
• 要摆脱对抗，可以问“我们应该做什么？”而不是问“她”必须做什么。也许这样问能帮她意识到问题，然后她会找出问题所在。通常需要问许多问题才能找到根源。
• 参考外部专家的意见。

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

译者 陈宇 有多年的C++软件开发经验，对敏捷开发有浓厚兴趣。在项目管理方面也些兴趣及经验，PMP。

1. 返回顶部

   沟通技巧已成为协作成功与否的最大瓶颈！

   发表人 高 翌翔

   除非是自闭症的患者，否则的话，只要使用恰当的方式、方法进行引导，正常人都会愿意与他人沟通。
   
   当然，沟通双方的以一种平等、平和的心态进行交流也是至关重要的！
   
   沟通同样需要学习和实践！

   回复

2. 返回顶部

   沟通在团队协作中着实重要

   发表人 Huang Simon

   沟通作为项目管理中的一个非常重要的环节，不管是在敏捷开发之中还是在传统的软件开发之中，对于一个团队而言，都在一定程度上影响着软件产品的质量甚或项目的失败。很多时候，团队协作之中的沟通是需要技巧的，且采用什么样的方式进行沟通也是有所讲究的。

   回复