Home > Blogs > Overcoming Resistance

Overcoming Resistance

It never ceases to amaze me how many different ways we can come up to fight change. Whether it is dropping a few pounds, kicking that nasty smoking habit, shutting off the lights as we leave a room or getting better at developing software, we are clearly at our most inventive in finding ways to just stay put.

This is a clearly identified stage in Virginia Satir's change model: Resistance. Even though our brains will be telling us that there is a better way to do things, a real opportunity to improve on our existing level of performance, something inside us holds us back. It is comfortable here, we tell ourselves, it's not so bad now that we are used to it. Let's just stay put - that's so much easier.

No learning, no disruption, no chaos. Just the current status quo, which in many cases is the devil we know. While the allure of this current way of doing things can pull us back from almost any stage of change, it's primary strength seems to be in keeping us from heading down the path of change at all! Resistance = inertia.

As agents of change, our most critical task is to understand all of the barriers to change that are put up, and to break them down. For many of these barriers, our job is to expose them for what they really are: excuses and rationalizations that won't hold up to scrutiny. It is one thing to present a better future, but a strong change agent understands that we need to sell to overcome the resistance.

In changing how we develop software there are many forms of resistance, but the primary ones fall into a couple of categories. We will often hear things like "we tried different ways of doing things, it didn't work", or "we don't have the time to learn new approaches", or my personal favourite, "we can't afford to do those things". There will be variations on these themes (the latest I heard was that the group was operating under spending constraints), of course, but these are the big three (and actually, the last two are different spins on the same resistance). Listen closely as people put up their barriers to doing things differently, there's a good chance that most of what you hear will fall into these areas.

Let's start with the second barrier, the 'there's no ROI in this stuff' resistance. This can take the form of not enough time, money or resources, but these are essentially equivalent for the purposes of selling change. It is interesting to note that most teams cite 'not enough resources' as the greatest issue they face, so it is worth starting there: even if it is not cited as a barrier, bring it out for discussion. In almost every situation I have come across, this barrier arises because it is the numerator that is not well understood. Even if we can clearly cite the value of the proposed changed practices, few organizations have at their fingertips the current cost of non-quality. We need to expose that blackened lung that incents people to quit smoking, or those jeans that won't button up to get people to shed pounds.

In software teams, this is the elephant sitting in the room that nobody talks about. Almost every team can quickly start to appreciate the costs associated with their current practices with a few nudges. Anecdotal recollection can be quite generous, but even then if we sit back and ask how often we deliver on time, or how much time we spend cleaning up messes, people will start seeing the potential for return. Then we can walk down the path of taking a few measures. Grab the first 20 or so defects you have in your defect tracking system, and count how many have their basis in something that could be reasonably have been identified in early-stage analysis (typically it is half or more). Get people to measure how much time they spend working on things they thought they had washed their hands of, even for a week or two (again, numbers around a half are not uncommon). On-time delivery? Unmanaged scope change? Employee turnover? Overtime and burning the midnight oil? Heroic efforts? Lost customers? Customer reported defects?

The list goes on. We can very quickly build a compelling argument that there really is a return to be had, it simply was not top of mind, and almost certainly was not being measured. Armed with this, we can have a rational discussion that addresses this barrier, and we usually get to the point where the discussion becomes "we can't afford NOT to change". The more real and more personal the data we can provide, the better.

That first barrier, the 'this stuff didn't work in the past' barrier, usually comes as a result of misdirected or overwhelming change that has been inflicted on the group in the past. Once incented to actually change, we need to be careful to identify the smallest possible change that will provide the greatest impact against the most relevant cost. Too many change initiatives take on too much, which dilutes the value of the return, increases the cost of the investment, deepens the chaos and lengthens the duration before we start seeing value. "We're going to follow the Unified Process" can literally destroy a business, and even "we're going to do Scrum" can inject too much change if the team is not ready for it. Better to go with something like architecting the system, or starting a daily status meeting, if those things are the ones that will provide the best value.

If we select properly, we can see dramatic returns almost immediately. This, in turn, reduces the likelihood of barriers cropping up next time around, as the team starts to understand that this change stuff doesn't have to be so bad after all. It's all about selling to overcome the resistance.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.