My approach when I start working with any new team or organisation is to spend a lot of time building relationships and trust. I take people for coffee (not just my own team members). I try to be a sounding board for both the good things and frustrations which my new colleagues experience. I look to show people that I don't have an agenda of what I would like them to be doing, or an agenda of "agile". I am there to facilitate improvement, not evangelise or force people to "do agile".
From an outcome point of view, I try and get some small, early wins on the board. The way I approach this is to understand the biggest current pain point from both the management and team's perspective (from listening/observing as well as directly asking - sometimes a pain point is obvious from my fresh, external perspective but not to my new workmates), and quite promptly join hands (metaphorically) with folks to take small steps forward.
When facilitating improvement collaboration exercises such as formal Retrospectives, I will guide the team to come up with their own options and process change experiments to reduce their pain. I will only provide options/suggestions/advice myself if I am asked to do so from someone's position of "don't know what I don't know" (Note - sometimes I need to directly ask the team if they want me to provide suggestions, and not assume they do or don't, or that my usually reliable inbuilt radar for such things is in tip-top working order).
Getting early runs on the board with the team is paramount, but I also explicitly seek ways to address management's concerns. For example, if one or more of the managers in my new sphere thinks that "the team is slow", I will look for signs of lack of transparency (both from management to the team and vice versa), especially in terms of unplanned work (the team spending a high %age of their capacity on bugs, incidents and ad-hoc requests is often a key culprit in a perception of "slowness") and disagreements in priorities (working on the "wrong thing" is another).
I will endeavour to not make the mistake of being such an advocate and protector of "the team" that I build enemies in management. An Agile Coach, or any kind of change agent or improvement champion for that matter, needs to be respected in order to get a seat at the table; to be able to influence genuine change for the better, and thus be effective in their role. This sometimes means sucking things up and picking my battles, particularly in the early stages. Even better if I can frame them not as battles against each other but rather battles against inefficacy.
I will always "ask the team"; try to go to my teammates with the problem to solve rather than trying to influence/cajole them down a particular path. I treat them as highly intelligent, creative problem-solving adults, because that's what they are. They are not underlings who need to be herded or managed. My job is to help the team collaborate more effectively with each other and "the business" (and stop perpetuating silo mentality in the first place) rather than tell them what to do or "protect them", and hopefully I never assume I know better than them in terms of how to improve things (I might have more expertise in agile/scrum/etc. but that is not the same thing).
So, these are a few things I look to do as an Agile Coach (or any type of leader, really) in the early stages of a new embedded team engagement. On certain occasions I will fail in what I am trying to do but, most importantly, I look to be self-aware and keep taking myself back to the core principles of my approach as described here.