As technical professionals, developers are often accused of ignoring human issues and focusing too much on the technical aspects of a solution. Hugh MacLeod said it best:
I'm 1/4 of the way through the book Leadership on the Line: Staying Alive Through the Dangers of Leading
Habits, values, and attitudes, even dysfunctional ones, are part of one's identity. To change the way people see and do things is to challenge how they define themselves.
Being a Big Swinging Developer is all about changing the way that people see and do things and that second sentence up there explains a lot of the resistance you'll face. It's not enough to show people what they can do, you need to show them who they can be. For example, I know lots of programmers who love agile development techniques and have trouble getting others to follow suit. This can lead to a lot of frustration as the Agiles think that the Non-Agiles "just don't get it." I don't think that that's the case. I think the folks who resist agile techniques do so because they don't want to be agile developers. Really, it may be as simple as that. Not everyone wants to code quickly and safely, or be able to change their mind, or do the things that agile techniques enable. If you look at it that way then you start to realize that someone who codes slowly and (at least in their mind) carefully will view writing unit tests as extra work that lowers their productivity. They may see putting prototypes in front of users before all the requirements are known as opening themselves up for (gasp) more work down the road.
If the view of people defining their identity by their habits, values, and attitudes is correct then the happier they are with their identity, the harder it will be to change how they see and do things. This may explain why the multi-decade veterans stick to their ways while the freshly minted grad will try out whatever you throw at him. It's not that the new guy understands better, it's that his identity isn't as firmly cemented which means changing what he does results in less of a change of who he thinks he is.
The next time you have an idea for process or organizational change, make sure that it either fits with who the organization is or who they want to be. If it's going to be a significant departure then spend extra time painting the picture of who they can be if your change is adopted. If you can't sell the idea of the new identity, chances are you won't be able to sell the technical aspects of the change. If, however, you can make people want to be who your change enables them to be then you'll find yourself surrounded by support instead of resistance.
The best way, the only way, I've found to help people move forward with agile who are set in their ways is to convince them the world, the environment, has changed. Techniques that may have been successful in another business climate or domain won't work in the business domain they are currently in.
For instance, I once worked with a developer from NASA, great guy, but did not take to agile at all. His way of working at NASA was absolutely necessary…slow, methodical…slow. No room for any kind of error, huge up-front design, and a domain that doesn't really change all that much.
But, we were working for a start-up.
I convinced him he was in a different business climate, he had to learn to roll with the punches…and Scrum is EXTREMELY disciplined in order to be able to be flexible. His ways weren't necessarily wrong they were just suited to a different set of conditions. After that, his ego was intact, and he understood why we needed to be agile. He was never a true believer, but he was good at keeping us honest, seeing problems down the road, and mentoring some of the youngsters on the team. We kept him.
Paradigm shift in seeing the world around them.
Jen