I discussed recently changing the process in one of teams in the organization. In theory everything is totally easy. We need to assess current situation, find out what should be changed to improve the way the team works, apply new ideas and support them over some time to make them persistent and then go for a couple of beers and congratulate each other a stunning success.
In this specific situation we have already a couple of ideas which should help. And yes, they include K-word. Yet still the plan is to start as we didn’t know much about the team. We try to act as the hammer wasn’t the only tool in our toolbox, even though we do have a hammer too.
Once we know what is wrong we can apply a cure. And that’s where the hard part begins. If you look at typical pattern of change implementation you will see that the first period after inviting change sucks. People don’t know yet how to work with the new tool, process, rule, you-name-it. Outcomes are likely to be worse than with the old approach. After all, no one said changes are easy.
Now, here is the trick: if you’re trying to implement change you not only strive to overcome typical issues but also have a reluctant team, which doesn’t want any change at all, you’re going to fail.
People will get enough arguments to abandon change and if all they want is to get back to the good old way of doing things they will use this chance. What do you need to do then?
Get more team buy-in.
Actually this is what you should start with. When you assess current situation you talk with team members. If you don’t talk with people your assessment stinks anyway and I don’t want to touch it even with a stick. Use this opportunity to get people buy-in. You will need every single supporter you can have when issues start popping out.
Don’t implement change unless you’re able to convince people it is a reasonable idea which would help them and you really don’t try to make their lives more miserable. Even if you personally are convinced that you have a silver bullet which would change your crappy software house into another Google, only better, you won’t win against people who have to follow your process, execute your idea and deal with all of side effects of a new situation.
When I read discussions about some approach, which appears to be working rather poorly, the first thing which comes to my mind is lack of buy-in among people who are affected by the change. In terms of implementing agile we often forget that problems seen within development team are often triggered outside, likely by management. That’s why, for the purpose of this article, I use term “team” to name everyone whose work will be significantly affected by the change.
Anyway the pattern remains the same. You just need more buy-in. You may need to work on this with development team but you may need to work with management too. Whichever case is true in your situation, go fix it before you start implementing change. That is, unless you find it pleasant to fail.
Subscribe RSS feed
“Don’t implement change unless you’re able to convince people it is a reasonable idea which would help”
I do completely agree with this statement. It doesn’t matter how small the change is, people has to be convinced that it make sense and it will help.
However I have met people who are fully aware that there are problems with current process but are completely not willing to try anything new because ‘it won’t work anyway’. Do you have some techniques to approach people with such attitude? Or maybe you would assume that some people simply won’t like the change and they have to deal with it (or leave)? To make it even harder … what if such people are senior members of a team?
If we discuss groups of people you won’t have everyone on your side, that’s for sure so your question is no surprise.
First of all I’d try to work individually with a reluctant person to get their buy-in but I know it isn’t always possible. Yet I am still surprised how many times people were able to get my buy-in on ideas I didn’t initially like, i.e. ISO implementation.
1. Dealing with a team member.
If a reluctant person is one of junior team members the issue is fairly easy to solve. Get majority on your side or at least all important influencers in the team. Then you should have enough supporters to sustain the change and those who are reluctant would eventually follow.
It becomes harder when we discuss one of informal leaders of the team. You have a few choices. If you’re able to get support of all others, go for it. Odds are the guy would eventually change his mind, although it isn’t that likely. If he’s still a problem you can push him harder and harder trying to make him compliant with the rest of the team. You can also allow him to work different if it doesn’t harm the team. I worked with a developer who would be a great example here. And finally you can exclude problematic person from a team assuming that their attitude do much harm to the team and it isn’t balanced with effects of their job.
2. Dealing with management
This is usually the most difficult situation. You have no power whatsoever over the reluctant person, yet they can ruin whatever you’re trying to do. If you aren’t able to convince them with words try to do it with results. It may require additional effort or even temporary sacrificing tasks done for other people but if you treat it as a short term-investment it may be worth the effort. Another idea is to entrench. Do your job, be consistent, try to prevail the first difficult period to the moment when results start to show. Then it should be easier to convince the person. You can also get support from your superiors, hiring them as a shield. If your boss is a supporter of the idea you can ask her to help you to deal with those who don’t want to adjust. It worked for me well a few times. And finally you can go to war, which isn’t really recommended, even though sometimes it works. I won a couple of wars like this, but once the war came back to me later to kick my butt painfully.
Also cott Berkun has a very good (part of a) post on dealing with reluctance to change: http://www.scottberkun.com/blog/2010/how-to-fix-a-team/
Thanks for your comprehensive and useful response. Also Scott’s post is very interesting.