What to do when you find resistance to change….

Back from holidays and ready to blog again. After a sustained period of overlapping work it had reduced my creative capacity somewhat.

Many of us have come across resistance to change while attempting to move a company more towards agile.

The classic story:

Hey we have a great job for you, just come and lead/work/be part of our team. We do agile software development and simply love working in an iterative manner. We have stand-ups and product owners and free ice-cream on tuesdays etc…

Sounds promising

Upon arriving and while not being ignorant to the fact that agile adoption requires both top down and bottom up change you get faced quickly with the real situation, which is: (not restricted to multiple layers of middle management) “I’ve done it this way before, it sort of worked then, I wont change it now”.

This can often discourage those new to agile from continuing in their agile career and in a state of “norming” simply adopt the path of least resistance.

I could perhaps give about 5 anti-patterns off the top of my head right now. But we all know what the problems are, as we are regularly faced by them, in fact whereever software development occurs you will find resistance to change.

Thing is people dont realise that change is here to stay! (I know cliche!)

So I am an agile adopter / coach / scrummaster / what do I do.

You have two options

1) Quit and work for an agile company that are already fully agile, eg. Rallydev Thoughtworks or perhaps try a more dot.com company which is genuinely agile. (Though the former might not be so impressed if they thought you weren’t able to at least convince your former colleagues that agile is a far better way of development even if changing them is far beyond your control).
2) Stay

Within option 2) you have also two options.

a) Choose to norm.
b) Choose to change the company.

a) If you choose to norm. I believe you will quickly become jaded, demoralised and perhaps institutionalised. This is dangerous for agile, especially if you are professing to be agile, in which case its like agile without the discipline or reinforcements that provides the transparency and feedback that is required to make good software in a reasonable amount of time.  If you do norm, make no pretense that you are doing agile.  In the hope that should they attempt agile again, they wont think that they have tried it and failed.  Agile is a revealer of the inherent problems in a system, this often causes people to blame agile more than change their failing system.

b) If you choose to change the company, then you have chosen a difficult thing. However this is my favourite option. I personally love this challenge, you may however need to manage your expectations you had when you joined the company.

To find out how you can change the company, you can often look at what doesn’t work and do the opposite.

1) Change everything all at once, on your own.

– Doesn’t work, because you get spread too thinly. You cannot back up your ideas and concepts.

Agile is iterative, reflecting frequently in small bursts, learning through small changes here and there. Its far better to do agile well with one team than attempt with 7 teams at once. You need to take something, own it, demonstrate the improvement and then move on with that as your foundation.

2) Expect everyone to agree with you and jump on board.

– Often it takes 1 to 1 persuasion and demonstration to get people onside. People dont like change. You might think that developers always are the first to embrace change, but (people – being people) dont often like the discipline that comes with agile. Often developers love to ditch the documentation and component designs but hate to become accountable to their code, especially their designs and techniques.

Guess what, sometimes people dont want to change, and you can’t make them. Which means you need to be stronger in Agile than they are in waterfall, or cowboy, or anti patterns etc… be prepared for conflict and stand your ground, but dont be a person of conflict for the sake of it. You prove the point for better software not to win an arguement.

3) Fight on all fronts.

– Like with spreading yourself thin, you dont need to argue agile on every case. You might see 50 improvements you might want to make, but guess what, they dont need to know about 48 of them right now, they can discover the others in a few weeks time. Work it bit by bit. You might want to ask the question “How are we being agile” as opposed to “are we agile”. Dont bash people with having standups perfect, TDD perfect, retrospectives perfect, customer relations perfect (product owner) all at the same time in the first week. (Unless you have the people at hand, and you have a big stick and they are co-located and perfect developers with perfect personalities). Work on common challenges one at a time. Allow the team to identify problems and then feedback themselves, treasure discovered is more valuable than treasure given.

4) Pure servant leadership.

Servant leadership is often described the best way (and I would tend to agree for many reasons), however its hard to influence if you have not got a stick. You see shepherds have a stick, they herd sheep, they dont need to beat the c*&p out of a sheep to get them going, they just need to show the stick, they stick saves the sheep, pulls them out of trouble and leads them in the right direction. Sometimes if you haven’t been given a stick (authority) its best to obtain one, get a bit of grit in yourself and you can do it. Its quite forgivable to leave if this doesn’t work at this point, however I have a strong belief that through persuasion, you can bring about change . Get some nuts. (Shameless Mr T Snickers reference). A great idea is to get linked in with a supportive community, perhaps like the XTC (Xtreme Tuesday Club) they will help back you up and repair you after your persuasion battles.

thats all my musings for now, and this is not an exhaustive list.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *