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?

  • 4
    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, 2018 at 23:34

3 Answers 3


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".

  • 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. Nov 13, 2018 at 10:35
  • I like this answer; I'd like it so much more if the assertions were backed with references. I want to believe the assertions you're making "arguing takes more time..." or "making an arbitrary decision. . . ", but if I try to act on those beliefs, I'm going to be challenged by every stakeholder present. (heck, stakeholders from other projects in other departments will swarm like moths to a flame just to challenge me). Can you provide references? (Also concur with your P.S.)
    – MCW
    May 9, 2019 at 10:28

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.


With my little knowledge on Project management, I'd say that I believe everyone wants his/her opinion aired and implemented. One of the qualities of a PM is being a good listener and communicating with the people involved in the project to make the work productive and meeting the deadline.

However, it is important to note that as a PM you are meant to balance the competiting objectives of the project, where each teams are arguing on the best way to solve a problem. Your judgement/decision on certain problems is meant to be backed with facts and with the confidence that, without a doubt, you are making the right decision as a PM after listening to them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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