I spent my lunch hour at the Path to Agility conference talking with a friend of mine who is in the middle of trying to get his team to embrace some agile practices, particularly around automated testing. Some of the changes that he’s trying to implement are causing some friction with the team who are not embracing the change.

People not wanting to change is nothing new. But what is the reason behind that unwillingness? It’s real easy to blame the team members and just say that they don’t care, they’re lazy, they like technology X instead of the new thing, etc.

Instead of just blaming others, maybe we should look at how we (as the change facilitators) are helping to create a desire to change and an awareness that there is even a need for change. If you’ve been doing your job a certain way for the last 10 years at the same company and you’ve been getting praised for your work or getting good performance reviews and raises, why should you change? After all, your company has been telling you that you have been doing an exceptional job. And now you’re being told that the way that you’ve been doing it is wrong?

This is what makes situations like this particularly challenging. Before we can even expect people to change, we need to show them that although they have been doing a good job in the past, we have an idea of how they can do their job even better. For some teams, having 50 bugs in production each month might seem good to them if last year they had 80 bugs in production each month, when for some teams having 5 bugs a month in production is a lot.

Unfortunately there is no easy answer to this problem. In fact, I can’t even say that I really know how to effectively handle these things. What I am learning is that the people side of software development is probably the most difficult part, and it’s probably where we all need the most work.