There seem to be two camps of agile coaches, those that advocate deeply embedding into a team and essentially becoming part of the team, deeply involved in the day to day stuff that the team does, and those that prefer to take on more of a mentoring role rather than being an active part of the team's day to day activities. For a long while, I was very firmly in the coach as mentor camp, and to a large extent, I still feel that that's the most effective coaching style long term. However, I have changed my opinion somewhat on the value of deeply embedded coaching for new teams.

I am now of the opinion that a coach needs both styles available to them and to be able to choose which is best in the situation they find themselves in. As both approaches have their strengths and weaknesses it is worth taking a look at both to see where they can be applied best.

When a coach embeds deeply, they essentially become part of the team. It builds a lot of trust because the team sees that you are there with them working to do whatever it is they are doing, sharing in their problems and challenges. The close connection and the sheer amount of time spent with the team allows the coach to really get in there and show the team how it's done. By having a deeply embedded coach, new teams can make a lot of progress very quickly. So it is a very effective way of spinning up a team and getting it high performing very quickly.

On the negative side, the most obvious problem is that if you are deeply embedded in a team, you can't be helping other teams. So the embedded approach has a pretty significant scaling problem. A coach can really only look after one or maybe two beginner teams this way. Maybe 4 or 5 once they have some experience. But when you have a lot of teams, you rapidly run out of coaching support. So embedded coaching is really only possible when you have a small number of teams or you are prepared to take a long time to get a large number of teams working. If you want to start a large agile program quickly, embedded coaching may not be the best approach.

The other issues with embedded coaching are slightly less obvious. I have written before about the responsibility trap. Embedded coaches find it very easy to fall into the trap. If the coach is taking on all responsibility for agility within the team, it make it impossible for them to move on (and worsens the scaling problem). It also means that the team isn't really learning anything. They may be doing great but as soon as you leave, all that agility goes with you. Embedded coaches need to make very sure that the team is really learning. You also have to watch out for coach addiction. Embedding also makes it hard to let the team fail. I know that sounds odd but sometimes a team needs to be able to fail in order to learn and grow. If a coach is a team member, they may be so deeply invested in making the team succeed, that they will not take the opportunity to use failure as a teaching tool.

The last issue with embedding is that by making yourself part of the team, you are seen by the leadership of the project/program/whatever as one of the team - someone they can give work to and have it done. This is something management loves. They hate having coaches hanging around not directly contributing to the work done (there are indirect contributions of course) so they love "doers". Once you become a member of the project team, you are no longer a coach. You start being measured on the success of the project, not on the success of the agile transformation, so when the crunch comes, as it always does in projects, agility will take a back seat to getting stuff done and there is nothing you can do about it.

The mentor style of coaching is almost exactly the opposite of the embedded style. It scales better as you aren't deeply embedded in a single team but rather spread out across many as an advisor. While it scales more easily, results are also slower as you simply can't spend enough time with each team to really get them moving. Any learning though is definitely done by the team as you aren't there holding their hand the whole time. It's much harder to fall into the responsibility trap but you run the risk of being seen as an unnecessary project cost because you aren't in there actively doing stuff, so it is much harder to build a good relationship with management. Two different styles, almost exact opposite pros and cons.

So which to choose? Sometimes you have no choice. If you have a small team you need to get going quickly, you'd better embed. If you have 20 teams spinning up on a large program, you need to be a mentor. Often though, the best approach is a hybrid of the two - embed to begin with, then lift yourself out to a mentor role as soon as you can to avoid being sucked into the team permanently. Of course lifting out can be a problem but often the best way to lift out of one team is to embed in another - "those guys need my help more now...".  Of course, while you are embedded in the other team, you will have a hard time mentoring the first team as the new team now takes all of your time. 

If only there were a way of having both deeply embedded coaching plus mentoring at the same time. In fact there is - it's called having experienced scrum masters. A scrum master embeds with the team and does the rapid uplift of skills, with a good mentor coach to assist where needed.