You’re right when you say:

1. It’s a decision for the Scrum Team.
   AND
2. If the Scrum Team cannot agree on an approach then the Scrum Master may well facilitate a process to help the team decide.

Thereafter, if a consensus cannot be reached, the Scrum Team have effectively decided not to decide. This is a dysfunction that the Scrum Team have to address.

The Scrum Master should never decide for the team (and there is no such thing as a System Architect or Functional Manager in Scrum).

The Scrum Team have to resolve the situation for themselves. As a Scrum Master, I might encourage them to try one approach for one Sprint, and the other approach for another Sprint, and then review at the Sprint Retrospective. Inspect, adapt and move forward.

Your question is exactly the reason I believe that just because you (try to) practice Scrum or other form of Agile, it doesn’t mean that there shouldn’t be a technical team lead (aka benevolent dictator) on the project.

In my past experience, we had a project, where management came down and simply stated “no more management. No hierarchy. The team is responsible. Go” We had a number of strong voices (some of which came from guys with only 1 year of experience in project and language they were in) on a relatively large team and most meeting degenerated into arguments, some of which were for rather silly reasons. (can you imaging a 1.5 hour discussion if unit test project naming convention should be test_[projectname] or [projectname]_test or….)

So in reviewing with management how that team structure just didn’t work for us, my proposal is that some hierarchy is not a bad thing. For the next project, he gave me the label of a design lead (with basically dictator-like powers) and in a 1.5 years that it took us to complete the next release, I think I had to exercise those powers only few times and only towards the beginning of the project.

My role as a design lead and one of the scrum members was to be part of the team. We still had discussions and I welcomed/encouraged input. So in reality I only had to step in few times when a consensus couldn’t be reached. And I think because our meetings stayed productive and there was no yelling or arguing to the point where half the team just wants to leave, over time we as a whole got more aligned on the same page where the necessity for those dictator-like powers mostly went away.

The other thing that I think helped was to break up large development team into smaller teams of 3-5 people so that those strong voices would each have a chance to naturally lead without stepping over each other.

These are my subjective views:

1: A team decision does not have to be consencus-based. It can in fact be a majority vote, the choice of an elected representative or something else. But the team should somehow agree, yes. Considering who should facilitate this leads us directly onto answer number…

2: I have on multiple occasions encountered situations where the inability to resolve disputes has proven problematic. In these cases, having someone there to resolve the dispute really helps, even if resolving it only involves making a random decision. In my experience it works well if the team lead or technical lead takes this role.

In theory you could probably just as well adopt some sort of “rock, paper, scissors” policy to resolve disputes, but this would require non-stubborn and quite open-minded team members. It might work if you’re sitting on a group of experienced people or people who agree a lot.