Anything that's rigid is by definition not agile. For every practice it's important to understand the reason behind it and what it's supposed to accomplish, and then you can determine if that's something that you care to accomplish, or if perhaps there is a better way to accomplish it within your own team.

The converse is also true though. A lot of things will get resistance because people don't like to change, or they'd rather not leave their desk and talk to other people, or they only want to optimize for their personal productivity without considering the productivity of the team as a whole. That last one in particular is the source of a lot of friction with developers in my experience. Individuals like to optimize for their own personal productivity, and sometimes in order to increase the productivity of the team the individual productivity needs to suffer.

So as long as you're being mindful of your practices, what you're doing and why you're doing it, and looking to constantly improve the output of the team as a whole then feel free to adopt what makes sense and discard what doesn't work, and ignore anyone trying to sell you on dogma that they barely understand themselves.