I will have a discussion with the developers. During the discussion, I would: 1. Listen to each developer to fully understand their concerns. 2. Highlight the project goals and how the architecture needs to align with requirements, team standards, and our colleagues responsibilities. 2. Walk through the pros and cons of each approach, focusing on the technical aspects, team alignment, and the overall project objectives. 3. Once the pros and cons are clear, it’s easier to find common understanding. 4. If they still can’t agree, I’d make the final call, ensuring the decision serves the project’s best interests. 5. Follow up on the decision implementation. 6. Add the issue to the retrospective to learn and improve team collaboration.

There is well established process for this. Software industry exist for more than 30 years and there are industry standards, guidelines available and companies following them day to day. Let us not re-invent the wheel. If two developers has conflict, first i will ask them if the coding guidelines followed, intended design followed, and is review done by the appointed code review stakeholders. If there is still a conflict, now the ball is with review stakeholders, not with developers. If there are multiple options to implement the same logic, review panel to weigh in pros and cons (readability, stability, maintainability, scalability, etc…) of each of the options, and choose the best among all. There is no room for personal conflicts.

To resolve the conflict, facilitate a constructive discussion where each developer explains their reasoning. Focus on the project’s goals, evaluating the pros and cons of each approach. Refer to relevant best practices if needed and encourage compromise or a hybrid solution. Prioritize long-term maintainability and scalability, ensuring both developers feel heard and valued to foster collaboration.

First of all, considering that both are part of an agile team, let themselves figure out a solution for the situation. If they are not able to realm the conflict by themselves, you may facilitate an agreement by using different negotiation techniques, such as: pros/cons, accommodation, and so on. Usually, it works very well. After that, if the conflict evolves (in a destructive manner), you may need to adopt dramatic decisions, such as moving those members to new different teams.

If two developers come to me over a conflict, I would first appreciate that they are having a conflict, which could mean they are working on themselves and striving to get better. I would ask them to provide the pros and cons, along with the problem statement they are trying to solve. We would then sit together and evaluate the pros and cons, eventually making a decision. As long as it doesn't become a personal issue, we can always learn and grow together. This is a hypothetical scenario. In larger teams, architects are usually involved in making these decisions.