I am dealing with a similar situation; previous teams merged into one with subsequent respecifying of roles and grades. Some legacy *political forces* were in play. As the Scrum Master you are the master-servant of the team including coaching. Many agile commentators forget the master part but the business is paying you to impose your will upon the team to make them a productive, cohesive unit. You are not a tea-boy. Reaffirm to yourself that you are in control of team. In the **immediate** instance I took the following actions ###Commitment to the Team Sit the entire team down including the warring developers and tell them that from now on the team will finish all discussions with the following [mantra][1] - Agree and commit - Disagree and commit Either way, the meeting will close with a commitment to the team that an approach will be used and each developer will do their utmost to see the course of action succeed. **Non-commitment will not be tolerated.** When Developer A and B next decide to engage in a lengthy debate about a particular aspect simply tell them that the matter is decided and as a team we (IE you) now expect commitment. I know some individuals on this forum may take issue with treating developers with such a hard line but in my experience not all team members respond to gentle encouragement to adopt a team spirit. People love change but some hate ***being*** changed. ---------- In the **longer** term you could invest time in ###5 Dysfunctions of a Team The 5 [DOAT][2] is a fairly popular framework for producing high-functioning teams. Each dysfunction is, coincidentally, mirrored by the 5 Scrum [Values][3] of - Commitment - Focus - Courage - Openness - Respect The 5D book is a very short read and a number of different workshops and team building events can be organised around the themes. I have attended two Workshops whereby we implemented the 5D and in each time the team emerged stronger, with more empathy and with a higher output. To illustrate the differences in the team considering using the **personal timeline** [tool][4]. Each team member draws up a personal timeline of high points and low points across a horizontal axis of time. It can be as detailed, colourful or personal as you like it. It requires high levels of **courage** to be the first presentation which is why the Scrum Master should go first. In our sessions normally half the team end up crying as people tell the stories on their life that led them to the current team. Stories of family deaths, heroic war actions, divorces, bankruptcies, abusive husbands followed by educational attainment, spiritual fulfilment, marriages. The personal timeline over a couple of bottle of wine was the best team building exercise we ever did to understand everyone's motivations and empathise with them. You will learn which developers fear being a bad father allowing you to prioritise their children's events, which developers were high achievers (harness their ambition), which team members suffered a life-event which impacted their productivity etc... It may be that Developer A and B both list joining the new team as a low point and by offloading that vital information to the team you see an immediate improvement. In short you build a tribe that has an inherent loyalty to itself. ---------- ###Lastly, consider letting one of the developers go. It does the following - Reaffirms who is in control during the forming stage. You. - Solves the issue - Sends a strong message to the team that you expect team loyalty and productivness - Will not tolerate negativity for the sake of old allegiances, it is a new day. Good luck. I personally do not believe that any new scrum team survives first contact with the process without losing an individual who refuses to accept the new status quo. [1]: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1642 [2]: http://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team [3]: http://www.thenetcircle.com/2011/10/18/the-five-scrum-values-and-why-they-matter/ [4]: http://toolkit.epic-hub.com/uploads/files/courses/five_dysfunctions_03.pdf