Should a Servant Leader be attached or detached to the outcome of the Scrum Team?

Personally, I think it depends on the situation. The question you should always ask (as servant leader)  is: what would be most helpful for the team?

Self-organization is key, so if you can get the team to self-organize it would be the preferred option I guess.

Offering help by itsefl is not a bad thing, but in some cases it might hinder the team to solve things themselves.

The middle ground could be indicating to the team that if they are unable to solve it themselves, you might have some thoughts of your own on the subject.

Offering help does not mean giving answers, offerig help is also asking the right questions, challenging team members etc, so it depends what your help is.

I have a strong technical background myself as SM, and if my knowledge or experience seems important for me to share, I always do, but I prefer to do this after the team comes up with a plan. i can challenge the plan from experience, asking "did you take this into account" or "how would your plan cope with this or that situation".

In the end, it is them to decide, but withholding important insights in general is never a good thing I guess.

For me, the SM should be attached to a solid outcome, but detached from it beging his or her outcome.

I've found the Consulting Role Grid to be helpful to contextualize this type of problem.

In the 1990s, Douglas P. Champion, David H. Kiel, and Jean A. McLendon wrote "Choosing a Consulting Role: Principles and Dynamics of Matching Role to Situation". Although there context was a consultant that is brought in to a company, there are a lot of parallels between how they describe a consultant and more recent work done on agile coaching competencies and agile coaching stances by people like Lyssa Adkins, Rachel Davies, Liz Sedley, and Barry Overeem. One of the outcomes of this paper was a "consulting role grid" that identified nine different roles. The put this set of roles on a matrix where one axis was responsibility for client growth and the other was responsibility for client results. Then, depending on the agreed upon responsibilities between the consultant and the organization, the consultant would have a better idea of which role or roles would be most effective to help achieve those results. The situation, the characteristics of the client, the characteristics of the consultant, and the relationship would be among the factors that helped choose the roles.

From the perspective of the agile coach (which would include the Scrum Master role in the Scrum context), I do believe that some roles are more in alignment with the underlying lean and agile values and principles as well as make more sense for the business context. I try to focus on taking roles or stances with the teams that I work with that are more aligned with growth rather than results, and making the team assume the responsibilities for the results. At the same time, if the business doesn't succeed, then I'd be at risk myself, so I would not be entirely opposed to stepping into one of the roles that are lower in responsibility for client growth and higher for results if I have the required knowledge, skills, and experience to do so effectively and without detriment to the effort.

At the end of the day, it's up to you to make the decision. There are definitely risks of taking on roles that lead you to assuming responsibility for results that may need to be mitigated.

A Scum Master is part of the Scrum Team so they are attached to all of the outcomes the Scrum Team attempt. No wy around that.  How the Scrum Master participates in the outcomes is up for interpretation. I feel that as a Scrum Master contributes in any way that the Scrum Team needs them to.  But the Scrum Master's accountability and responsibility to the team is to help them understand and appreciate the Scrum Framework.  

I've got a strong technical background myself.  I have a lot of opinions and experience that I am more than happy to share.  If I am asked, I will provide it but I do my best to not get involved in the technical implementations.  Providing input to me is not actually doing the work. 

Should a Servant Leader be attached or detached to the outcome of the Scrum Team?

Perhaps this is a false choice, and the ability to do something of both is best if outcomes are to be achieved without judgment being clouded.

I think this is constant question for most Scrum Masters in practice. Is there anything limiting the Scrum Master from providing technical perspectives? There is a fine balance between providing a solution/telling what to do and helping the Dev Team out when they're stuck. 

I think the SM should have accountability for the outcome with the team. I think it helps the SM care more, dig into the details more, create a better Retro environment. They could also be the best ambassador and defender of the team when management comes calling. 

In my opinion, it is a very fine line for the SM to walk when it comes to participation with the Development Team.

Sometimes, the Scrum Master can see trouble coming, or understands what the Development Team needs to do to address a specific challenge.   However, the SM can easily deprive the Development Team of a growth and learning opportunity whenever they come to the aid of the Dev Team, or keep the Dev Team from experiencing failure.

Sometimes, the best approach for a Scrum Master is to let the Development Team touch the hot stove, so that they learn not to touch it in the future.   And it increases the likelihood of the Dev Team listening to the SM's advice in the future when they are told something is hot.

Why is it important to know if the SM can attach/detach to the outcome of the sprint? Helping or contributing to a common goal or vision is what matters.

I know that there is a thin line not to solve problems of the team because we do not want the team depending on the SM on fixing problems. If you are able to suggest something or influence them to have a better outcome, is that considered attached to the outcome? If you suggested an approach for a design simply because you had an experience previously, is that bad because the team is beginning to rely on you, no. You are just providing a suggestions which they can also think of.

Is there any issues if you did become a part of the outcome? You knew something, you just shared it. Is that so bad if you did share it to the team?