Most high-performing Agile teams have flexed and changed their own processes so much that they feel as if they own them (rightly so). Someone external to the team coming in and asking them to change again will meet resistance just because they're external to the team and don't share the team's context.
Instead of introducing the change, why not introduce the goal and let the team decide how to meet that goal? You didn't give examples of the changes, so here are some which I've met in the past:
- We've realised that only Ben knows XYZ technology, and we think this is risky. How can we reduce this risk?
- How can we make our deployments go more smoothly?
- How could we get them smooth enough to deploy every week?
- How can we help team B adopt the process you're doing so well?
- How can we get George on the team and up to speed quickly?
By getting the team involved in the solution you turn it into a problem for them to solve, rather than a change for them to adopt.
Also do the things which @Eric and @Bartosz mentioned. Since Eric's already mentioned the Evil Hat, I'll link to my other blog on gaming culture with Dreyfus modelling. This was for newcomers to Agile, but you can probably get some ideas for how to game experienced teams too.