While helping an organization/team transition to Agile, you would see resistance from different roles for different reasons. Let us try to review some of the common resistances and their possible reasons.

Middle/Senior Management

Resists to:

• Self-managing culture, team empowerment
• Favouring team performance metrics over individual performance metrics
• New metrics for measuring progress of work
• Flexible scope and/or schedule

Common Reasons: Perceived threat to status and control, inertia/comfort zone, need for certainty of plan and execution.

Team Leads/ Scrum Masters

Resist to:

• Team members report updates to team rather than leads
• Self-organizing team culture
  • team estimates work
  • whole team participates in decision making
  • team members pull work
• Connecting with team members throughout the day

Common Reasons: Perceived threat to status, loss of autonomy and control, lack of trust in team members, inertia/ comfort zone

Product Owners

Resist to:

• Timely team interaction – attending standups, backlog refinement meeting, answering queries, etc.
• Writing effective stories, especially acceptance criteria
• Regular prioritization of product backlog

Common Reasons: Inertia to learning, comfort zone and time constraints (thinly spread over multiple activities).

QA Managers

Resist to:

• Cross-functional (or feature) teams – testers becoming part of individual teams

Common Reasons: Perceived threat to status and control

Architects/ Senior Members

Resist to:

• Minimal relevant documentation over detailed and precise documentation
• Peer code reviews over reviews only by specialists
• Team members estimate work – stories and tasks
• Flat team hierarchy

Common Reasons: Perceived threat to status and control, self-focus over team focus

Team Members

Resist to:

• Collective ownership of code and process
• Being punctual to team meetings
• Active collaboration with other members:
  • Active participation in daily standup, retrospective, etc.
  • Collaboration throughout the day
  • Pair programming
  • Multiple developers collaborating on a single work item
• Picking tasks outside their domain or technical specialization
• Relative size estimation
• Keeping the visual board live all the time

Common Reasons: Individualistic behaviour – Self-focus over team focus, Inertia/ Comfort zone, need for autonomy – working at own pace

Customers

Resist to:

• Flexible contracts over fixed contracts
• Regular availability to development team
• Flexible release scope and/or schedule

Common Reasons: Need for financial certainty, lack of trust, need for autonomy (working at own pace)

How to Deal with Resistance?

How you deal with resistance depends on the type of resistance:

1.      Logical Resistance

If the resistance seems logical, provide logical reasoning – with facts and case studies. Try to make it a two way communication, rather than one way. If you get a feeling someone is not able to understand a simple thing, there are chances the resistance is emotional.

2.      Emotional Resistance

Most of the times, resistance to change is emotional (often wrapped inside logic). If the resistance is emotional, no logic could help. Instead, try the following approach:

1. ACKNOWLEDGE: Before jumping onto solutions, take a pause and acknowledge their concerns and feelings.
2. Make them see VALUE: When the resistance is emotional, we need to start with the heart. Try to make the resisting individuals see value in change. Why should they care? What would they benefit from change? Use powerful questioning rather than simply telling/advising them.
3. Support with LOGIC: Provide facts, case studies only after they begin to see value in change.
4. Gain AGREEMENT: Ask for their thoughts and evaluate their agreement with your thought process. Use their current agreement as the baseline for next step. Don’t push for perfect agreement.
5. Seek COMMITMENT: Ask what things they are open to try out in immediate feature. Favour short-term commitments over perfect long-term solutions, especially when the resistance feels strong/deep.

Thanks for taking time to read. Hope you found this post valuable. Please share your thoughts in comments sections below.