How do you work with difficult and uncooperative people? People who are combative or unprofessional? People who seem actively opposed to the agenda?
Will Jessup notes that developers tend to be highly intelligent people and often won’t just do something because we say so. He suggests a dialogue:
"OK, we're going to do estimates for these cards"
"Why? I hate doing estimates"
"Do you have a better way of getting the client information about our best
estimate for how long this project is going to take? Without this we can't
get the budget approved and nobody gets paid."
"Hmm... no"
"So if we do this estimate we'll have our complete bs, total guess,
estimated timeline based on a bunch of stuff we know will change - but at
least it is something."
"OK =]"
Kevin Shine suggests that we should move from selling to getting them to buy in of their own accord: “There is a big mind shift between these 2 thinking approaches. One is collaborative and cooperative and the other is more command and control.” He goes onto suggest provide advice and support, let the team come to their own conclusions. He closes by saying: “You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.”
- Ask a question like “why not” – instead of trying to justify your approach ask them why it wouldn’t work.
- Turn the problem away from confrontation by asking "What should we do?" not what "she" has to do. Perhaps asking that helps her to acknowledge the problem and then she finds out what the issue is. This often requires many questions to find the root.
- Make references to external authority.
Bachan Anand asks if the team is even aware of the problem(s), saying they can’t improve if they don’t perceive it as an issue. In addition he points out that a new Scrum Master needs time to gain the respect and trust of the team members.
Ashish Mahajan reminds us that Scrum is just a tool and not the goal. Lacking a clear and compelling and a sense of urgency the team doesn’t commit. Ashish goes onto suggest 1-1 coaching, root cause analysis and rigorous use of retrospectives to help team members discover issues on their own.
George Dinwiddie suggests looking at the problem from the other person's perspective. Why are they reacting this way? What do they believe that would explain their behavior? He recommends Dale Emery’s “Resistance as a Resource”, anything from Esther Derby on feedback. George has also compiled a bibliography of articles on feedback.
This reporter notes that it is difficult if not impossible to sell people on ideas, instead it's better to listen. Ask people questions that seek to understand the problems they have, not their problems with Scrum, but their bigger problems. Use Scrum to help them solve those problems and they will discover its value far faster. In addition this reporter suggested:
'Why' is a potentially dangerous question, there is a high likelihood that it put the person being asked on the defensive. Asking What/When/Where questions help us achieve many of the same ends without the defensive reaction. Instead of "Why not", try "What do you think won't work with planning poker" or "Can you tell me what you think the problem is?" We move the focus from the person to the problem.