Working with Difficult People and Resistance in Scrum

Posted by Mark Levison on Nov 24, 2010

Sections

Process & Practices

Topics

Coaching ,

Adopting Agile ,

Scrum Master ,

Coaching and Mentoring ,

Agile in the Enterprise ,

Scrum ,

Agile ,

Change

Share |

RELATED Research

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.”

Gustavo Cebrian Garcia:

• 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.

RelatedVendorContent

Agile Maturity Model Applied to Building and Releasing Software

Five Key Practices to Agile ALM

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Kanban for Agile Teams

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   Clearly not just about Scrum

   by Mark Levison

   This discussion came up on a Scrum mailing list, clearly however the problem of difficult people is outside of "Scrum" per se. I kept Scrum in the item text because its the context people provided their words in.

   Reply

2. Back to top

   Difficult people

   by Esther Derby

   Few people wake up in the morning and decide "I'm going to be difficult at work today." It's more accurate to say "he's difficult for *me* to work with."
   
   Then you can get curious about why you have trouble relating. From his own point of view, the "difficult" person isn't trying to be difficult, he's trying to be helpful (even though it may not look like it, and you may not be the person he's trying to help.) Try to figure out who he might be helping, and you may see more options for action.
   
   As for "resistance." put on your decoder ring and you'll find that it often means "the other person isn't doing what I want him to do with the speed and enthusiasm that I desire." Most people don't like to be told what to do. But many people are interested in solving problems. You could start by framing the problem, rather than pushing a solution. Until the other person agrees there's a problem, you are stuck in the big game, Who Gets to Tell Who What to Do.

   Reply

3. Back to top

   Re: Difficult people

   by Mark Levison

   Thanks Esther - I think you've made a very interesting point. We always need to bear in mind that "difficult" or any other label is just from our point of view or context. We need to step away from our context and see theirs. Like you I'm a big believer in helping people see the problem and letting them solve it. My problem is that I don't always remember to act in accordance with my beliefs.
   
   Cheers
   Mark Levison
   Agile Pain Relief Consulting

   Reply

4. Back to top

   the article name should be

   by Andrej Ruckij

   Working with Difficult People and Resistance in Project :)
   
   
   Andrej
   www.agilemindstorm.com

   Reply