InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Overcoming Resistance to Change

Posted by Mark Levison on Aug 21, 2008

Sections
Process & Practices
Topics
Agile Techniques ,
Change ,
Agile
Tags
agile2008 ,
Facilitation ,
Management

At Agile 2008, Dave Nicolette and Lasse Koskela, author of Test Driven: TDD and Acceptance TDD for Java Developers, ran a workshop on "Overcoming Resistance to Change". Any change whether an Agile implementation or re-arranging the office furniture is going to encounter some resistance. The real question is how we react when that happens.

When people resist changes we propose our first reactions are often emotional (anger and frustration): They're stupid, stubborn, etc. As Dave pointed out thinking like this will not help us achieve positive change.

Reasons for resistance were broken down into three basic types:

  • Cognitive: I don't understand what should change, the benefits or how to change.
  • Emotional: Can I do this? Will I like it? Do I feel threatened? ...
  • Behavioral:  I refuse to be told what to do.

Forms of Resistance:

  • Active or Passive
  • Overt or Covert
  • Individual or Group
  • Aggressive or Timid

We were invited to play Dale Emery's: Resistance as a Resource Game - answering the question "Why would 'an intelligent, competent, sincere person of good will' resist a proposed change?". According to Dale the purpose of the game "To create, learn, remember, and express ideas about how to respond to resistance". In our version of the game each table worked together to discuss a few examples of resistance. For each resistance we proposed possible a Reason and then one or more Responses for each reason.

When it came time for the role playing Lasse join this reporters group and played the role of a Team Member who refused to standup. As a group we had discussed a number of emotional reasons that this person might be refusing to stand. However when this reporter acted as Scrum Master he completely forgot the emotional side and made cognitive appeals - which had no affect on Lasse. In the end the team stepped in and asked Lasse to be part of the team and try standing for the next couple of sprints.

Who will resist depends on the source of the ideas and their conflicting priorities. Developers want to deliver quality, customers might want features and management to protect their budget. So each will view proposals for changes from the others through their own lens.

In handling resistance we were reminded on Kotter and Schlesinger's Six Approach Model:

  1. Facilitation. Support helps employees deal with fear and anxiety during a transition period.
  2. Education and Communication Up-front communication and education helps employees see the logic in the change effort.
  3. Participation and Involvement. When employees are involved in the change effort they are more likely to buy into change rather than resist it.
  4. Negotiation and Agreement. This can be done by allowing change resistors to veto elements of change that are threatening, or change resistors can be offered incentives to leave.
  5. Manipulation and Co-option. This often involves selecting leaders of the resisters to participate in the change effort. If these leaders are given only a symbolic role then there is high chance that this tactic will back fire.
  6. Explicit and Implicit Coercion - Where speed is essential and to be used only as last resort. Managers can explicitly or implicitly force employees into accepting change by making clear that resisting to change can lead to losing jobs, firing, transferring or not promoting employees.

As Dave and Lasse both said its best to focus on the first three and leave the others alone as they can make the situation worse.

Johanna Rothman adds that when you see resistance you should consider if its a reflection of your resistance.

So when we're faced with resistance to proposed change, step back and consider playing Dale's gam with a partner it may help illuminate the underlying problem and also responses that help improve the situation.

The hard part is remembering to actively consider the reasons by Mark Levison Posted
  1. Back to top

    The hard part is remembering to actively consider the reasons

    by Mark Levison

    There have been several times since the conference that I've found myself in situations with people actively resisting new ideas. I find it a real struggle to step and ask myself about their reasons and what appropriate responses might be.

    Its very humbling to try and put into practice new ideas like this.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.