I have a scrum team that consists of client developers and my company’s developers to form a team of 8. I’ve noticed a lot of friction/arguments between team members on what is the best way to solve a problem.

How would you go about resolving such issues, and make sure that both parties are satisfied and best method was used?

  • 2
    What “teams?” You described one team of 8 people, not multiple teams. You also can’t clump people together and call them a team. I smell an X/Y problem. – Todd A. Jacobs Nov 12 '18 at 23:34

Do "architectural spikes" of both. This means: set a reasonable time-box for the work (typically a day), make sure the work is totally hands-on (build out as much of each competing solution as possible), throw away the spiked work when done, and only then have a discussion to decide. One way to make this more effective is to get each sub-team to spike the other sub-team's proposal. This makes sure that you don't end up with a "fallacy of sunk costs" problem after the spikes are completed. Any theoretical argument will tend towards "analysis paralysis". Doing hands-on work is much more effective for discovering the best solution.

In Sprint Planning, this is an allocation of capacity to learning instead of implementation. As long as it doesn't consume your whole Sprint and the team still works on a potentially releasable product increment (in addition to the learning from the spikes), you should be able to stay on-track.

Another way to say this: arguing takes more time than just trying out the alternatives.

Interestingly, making an arbitrary decision is also better than trying to argue out the "correct" solution since it gives your team an opportunity to inspect and adapt faster. Argument is almost always waste.

As Ken Schwaber, founder of Scrum says, "use Scrum to build the wrong thing in a month" (paraphrased) and then "inspect and adapt".

PS. I agree with David Espina that your inclusion of "women" in your description shows a pretty serious bias and you might consider some leadership training and some bias awareness training for yourself.

  • I don't think arguing is almost always a waste. I don't think you'd want to go under the knife with team who has some disagreement and will opt to experiment to see what happens. Don't think you'd want your jury doing that, or your airline pilot. I see what you're saying but you should qualify it with decisions of minimal or tolerable consequences. – David Espina Nov 13 '18 at 10:35

I don't think "women" have anything to do with your problem. In addition, disagreement about path forward is also not a problem. What is a problem is the leader of this team, I assume you, is not managing the conflict properly. I am starting this answer rather confrontational because of the words you used to describe the issue: firstly, "women"; and secondly, you "noticed" a lot of friction / arguments.... These signal a bias and passivity on the part of the team leader.

Conflict and disagreement are good because it means your team is engaged, they're thinking about things, they're invested, they're looking for a successful solution, on and on. If you did not have any conflict, while it appears great, you could have a severely disengaged, low morale team, or a serious case of group think or similar phenomenon.

You need to work the disagreement. Create a path for the two or more team segments to argue their case, to talk through the pros and cons of various alternatives. You need to facilitate it to keep things unemotional and fact / sourced base. You can either play the decision maker or create some type of voting structure to work through an issue or a combination of both. It can seem like a lot of work and could seem like things are not progressing, but it is far better to get the most of your team's thinking versus moving forward with an inferior solution and then reworking the issue later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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