Developer not integrating well with other developers

Try thinking about it the other way round. If there's a Developer who doesn't approach the others to resolve issues, you've got a problem. Developers are jointly accountable for the work they do and the culture should be one of swarming and collaboration.

Thanks Ian. I totally agree that developers are jointly accountable and the culture should be one of swarming and collaboration.

I had a few 1 on 1 with the other developers to gather their feedbacks on this issue, and they all have a common feedback here - The baby sitting and helping is significantly affecting their development work, and that particular developer is not taking the initiative to learn and perform 'due diligence' problem solving before approaching them.

I wish to not have this escalated out of the scrum team, and not to have this affecting the morale. 

How can I approach this matter and coach the developer/team?   

Have the other Developers brought this up directly and had a conversation about the problem and possible solutions?

It may be also to know your role and background. If you don't have a technical background like that of a Developer, it may not be the best idea to have a conversation about the individual's skills. If you are involved in the conversation, it should be facilitating a conversation among the Developers.

Thomas makes a great point about facilitating conversation among Developers. Key being "among Developers".

Developers are always accountable for:

Holding each other accountable as professionals.

How might the behind the scenes 1 on 1's with all other Developers be impeding the teams ability to self-manage and hold each other accountable? How well are we supporting Openness and Respect, with this approach? What prevents Developers from self-managing here? Why are you being used as the proxy?

Developers could Respectfully show Courage in being Open about this as a team. Conflict is not a bad thing for the team to work through. We want it to be constructive and respectful so consider how you can support this.

What Team agreements are in place that could be referenced? Could Team agreements be revisited and updated? 

Perhaps Developers could give guidance on how to perform "due diligence" problem solving. "Before I help you with this, what have you tried?", "What else could you try?", "Have you considered trying...."

To Ian's point...

If there's a Developer who doesn't approach the others to resolve issues, you've got a problem.

This is a Developer who is reaching out. The other Developers may be frustrated by this, but it shows a degree of commitment in that they are not just sitting back and doing nothing.

If this is truly a performance issue and the team can't work through it, you may need support from their leader or HR. I would start with the above first.

There's lots of great advice here. What immediately came to my mind is that you have an impediment, which is the Developers inability to work through this challenge themselves. Scrum Masters need to 'manage' this with what's in their toolbox to assist the Developers: retrospectives, facilitation, coaching, principles of self-management, etc., to help the team find their a solution and own it. This will build up their confidence. If a Scrum Master solves it they become the impediment to a self-managing team.

Try a Liberating structure such as a 1-2-all, or a 15% solution. Ask "what do you, the Developers, have the freedom to try?", "what could be a good first step to help this person without having to involve a manager?", or "what might be a good first step to take?".

Scurm on!

This is also a cultural issue and changes likely needed on both sides. The one developer like to ask questions quickly, as time doing research can be saved if the person next to you already knows the answer. Then the other developers don't like interaction that much as it breaks their rithm. 

I agree with the suggestions in previous posts. This needs to be an open discussion, even in a retro. 1 on 1 discussions is not good and only going to fuel the two side's resentments. 

Maybe the developer can be asked to be able to show what he already tried or done, when asking a question. However I think the problem is from both sides. The other developers need to be more approachable. Not saying it is the case here, but there can be a tendency among senior devs to hold back information and also a "don't talk to me" attitude. It might be a culture among the devs and just because the majority think in a certain way does not make them right. Is the one dev that asks questions new in the team? If so it might be the "storming" phase of team formation. 

Anyway open conversation is the best thing, but facilitate it well that it stays civilised  :-)

It's a practical situation which every Scrum team is facing once in a while.

In general this issue should be certainly addressed at the Sprint retrospective, and discussed openly.

The fact that developers are complaining about other developers behind his back is already the sign of unhealthy relationships in a Scrum team.

There are plenty of facilitation techniques, also at this resource, which discuss how to deal with such situations, encourage the exchange of opinion, and help find the understanding.

One thing which Scrum master has to establish, is if the behavior of the developer in question is an IMPEDIMENT-it means he or she is taking a time and efforts off the other developers, so they have to abandon own work to help him or her? If yes, then key question is if Developer is at least learning from the advice he or she is receiving, and if the skills are improving from Sprint to Sprint?

Or may be the developer in question is simply gathering more information from his or her team mates, to verify and increase the quality of own labor, without actually disturbing other peoples work? In that case it's actually a positive attitude, while the rest of the team lacks openness and respect.

Removing someone from a team should be always reserved as a last resort, even though you should keep in mind that its of course always possible.

Developers should be aware that a Scrum team collectively can recommend removing a member ( and of course HR department of organization fires people once in a while), but Scrum master cant remove or add anyone.

Scrum master does not manage the team, he or she manages framework.