Getting an entire team to all actually want the same thing can be quite difficult. It's often the case that seeing the value in something isn't enough in itself to encourage people to change ingrained behavior. Even those who value the change and who specifically want it can sometimes also be responsible for subconsciously fighting it.
The issue is really one of individual motivation and not team motivation as such. There comes a time when a moment of clarity reaches you, either as a result of something you felt you finally understood, or because of some new tool or some other subjective thing that makes the average programmer throw everything in and completely change the process. Your job - should you choose to except it - is to see if there is a way for you or the team to find out which things will be the triggers of clarity for each individual team member.
For me personally, it was simply discovering the StoryQ framework for BDD in DotNet, which made it too easy to ignore, and got me completely over the test-first vs test-simultaneously "barrier". Later I had my choices reaffirmed when I found NCrunch for Visual Studio. Half the battle sometimes isn't in selling the idea, but rather in simply lowering the effort required to introduce radical change in habits... and even then it can take a little time and work. These same personal triggers however weren't enough to sway the approach of my colleagues at the time, who are still writing as much of their test code simultaneously or even after their implementation code.
Sometimes also, there is a reluctance to change the way things are done, due to an inherent fear, distrust, or distasteful view of the effort required to learn to do something differently, even when the reasoning for the change is sound. If your entire test platform is tooled to work in a specific manner, it can be hard to justify changing the way things are done, and potentially changing the tooling, especially when old and new tests will need to continue to coexist for the lifetime of the project - and you certainly wouldn't want to need to rewrite every test you ever created. The strange thing is that sometimes people feel that this is the only way to adopt a new testing methodology, and that in itself makes it harder for those people to accept sensible change for the better.
Really, the only way something becomes reflexive is to force yourself to do it over and over again until you no longer notice yourself needing to concentrate overly much on how to do it. Sometimes, the only way to do this in a team is to set policies which may seen a little draconian, and to practice pair-programming and code-reviews, and anything else that can help team members back each other up and literally force the change in behaviour to occur. However, for such a strategy to really be successful, it still requires a firm and honest commitment from each and every individual team member to accept such measures as necessary, and to participate in the process... and a lot of patience from all involved.