Team members inexperienced in Agile often resist adopting this framework for a project. Maybe they've heard about some Agile practices, vaguely, and they've jumped to conclusions of their own. And the more strongly we insist on the practice, the more resistance we come up against.
This generally happens when we try to introduce this (or any) practice without providing time for the team to understand the principles behind it. A project manager who is interested in Agile wants his next project to adopt Agile, just like that. The common approach is to brief the team on the basic principles and then jump right into the practices. This is done informally, by gathering people around the workplace and talking to them, or by trying to use the stand-up meetings.
Both of these approaches are ineffective. The reason is that, during the initial stages, Agile is too new to the team. They're afraid of the uncertainties that Agile might bring about, and they need more education. Stand-up meetings have different agenda; they're not a vehicle for bouncing around such radical ideas.
One way of resolving this problem is to hold a formal introductory workshop at the beginning of the project. Arrange for a conference room with a good projector. Make a presentation to the team about Agile, its origin, its purpose, and how it differs from traditional ways of thinking about business projects. The reason for a formal setting is to emphasize the importance of Agile. And a presentation with real-time exercises will more likely bring team members to an attitude of acceptance, whereas a casual discussion might not. Take time to dwell on the principles, because people often read a little about a given practice and then shove it off as simply one technique they already know. When we provide insights into the principles, the team will truly understand why they were defined in first place. Later, when we begin to implement the practices, they will have already bought into the principles, and they'll more clearly see the real intent of the practices.
This relationship mapping should occur beyond the initiation period as well. During the course of the project, difficult issues and tough decisions will likely arise. At this point, refer back to the principles and practices that you already discussed with the team. A poster or a wiki page listing this information will come handy during such situations. The team will realize that the project manager isn't just dumping his or her own ideas but is basing decisions on those stated principles you've already discussed together. Team buy-in improves, and team members start making their own daily decisions based on the principles, rather than simply fighting the fire of the day.
In short, to introduce Agile, use a bit of formality and put extra attention on education before you begin a new project. This will convince your team of Agile's benefits, deepen everyone's understanding, and help make the transition a success.