Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We apply Scrum/Agile and we have two teams. The other team has a conflict of interest (or rather personalities) between two developers. I would like to help resolve this and would like to know how to deal with it should it ever happen in my team.

I am not a team lead as we use a flat structure.

The conflict mostly comes to light during the daily stand-ups and during the end-sprint retrospectives. So far there has been no open bursts of shouting or even "violence" but at the current rate i would guess either of those may be inevitable.

The conflicts are on areas of code or standards or ways of dealing with Scrum in the project. Neither team member is actually more wrong or sight than the other, so choosing a side is impossible. The effect of this underlining conflict is a negative impact of team morale and the newbies not feeling safe enough to give opinions or start taking charge of their tasks through fear of being involved in this or similar situations with the seniors.

Thus from a Scrum/Agile perspective how would / could one go about getting the developers to set their differences aside and work as a whole team again?

share|improve this question
2  
Pick a side. Heck, pick parts of both sides. Set some standards and settle the issue. Move forward. –  Anthony Pegram Feb 21 '13 at 6:19
    
The book "Software Inspection" by Tom Gilb has some examples and suggestions on this issue. –  eddyparkinson Feb 21 '13 at 6:24
1  
No matter the personality traits both the developers have strong and necessary skills for the project. So i would prefer not to 'alienate' any of them, or cause resentment by simply picking the 'other side'. That would probably further influence the team in a negative way. We also strongly apply a flat structure in the team, so it would not just be up to one person to simply choose a side and then things are settled. –  ddtpoison777 Feb 21 '13 at 8:48

2 Answers 2

up vote 8 down vote accepted

This is not a problem that is specific for agile/scrum, but it can crop up in any team.

The usual solution is to let someone in authority decide on the issue.
With the flat organisational structure of agile/scrum, there is not always someone with clear authority. So, the next best thing is to get the team to agree on (a middle ground of) the issue.

So, let the team's scrum-master convene a meeting to address the issue with the goal to reach a consensus that the entire team can live with and will abide to till the end of the project without bringing up the issue again and again.
If it is something that can be resolved by technical means (such as indentation or brace placement), the agreement can also be to have the repository reflect the majority view and to give the dissenters tooling to (automatically) transform the code to/from the repository format into their own preference.

share|improve this answer
    
Almost exactly my thoughts, though I'd add that sometimes getting someone in authority to step in and make the decision is the only solution. It needn't necessarily be a member of the team though. –  Baqueta Feb 21 '13 at 10:01
    
Accepted because having the team take control of events which effects it, is the best solution. The conflicting members then have a responsibility towards the whole team's needs/requirements/decision. This also helps maintain the flat structure of the team. –  ddtpoison777 Feb 21 '13 at 10:51

I don't think that the software development methodology really matters here. Scrum only highlights the problem due to daily meetings.

As a partial solution, the srcum master can solve the conflicts during the meetings. Scrum meetings have clear and strict rules: constraints on the duration of the meetings, certain topics that should be discussed, etc. Following those rules can reduce the possibility of such conflicts during the meetings. If those two people start arguing during the meeting, the scrum master should stop them and postpone the "discussion" to the end of the meeting (if there really is something to discuss), where only the interested parties should be present. The same can be done during the retrospective meetings.

This will not reduce the conflict itself, but will at least diminish it's impact on other members of the team, especially on novices.

To reduce the conflict at all someone should take the leadership and make decisions. Long-lasting decisions like coding-style or technology stack should normally be made once and not be discussed again until the next project. So should be the Scrum rules that you adopt. Someone in charge should speak to those two developers and make it clear to leave all their personal relationships out of their work.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.