Read this excellent article from Ron Jeffries and you will understand what needs to be done.
If you want to do Scrum, you have to follow the rules. If you don't follow the rules, it's not Scrum. And you shouldn't expect it to work.
There is plenty of space in Scrum to adapt the rules to the local team, but only once the basics have been mastered. This sounds like a prime example of a group of people who decided to alter the rules before they truly understood what they were doing. The principle of Shu-Ha-Ri applies here (and in many other places).
In a lot of teams, including mine, the product owner is also a manager for some or all of the team members, so it's hardly uncharted territory. It does pose some difficulties, and for some teams is wholly unworkable, but this is what helped for us:
- The manager and the scrum master must have an open relationship. It won't work if the scrum master is afraid to address issues with the manager.
- The manager must have enough self awareness to realize when his actions are causing problems, and have enough self control to step back, at the very least when the scrum master brings it to his attention.
- The team must be confident enough to stand up to the manager when it is in the best interest of the process.
- The best thing may be for the manager to not always be there. When we noticed people doing the daily status update to the manager, he stopped coming to the scrums for a while. Some of our team members are still uncomfortable with increasing an estimate with him present, so he often steps out during more sensitive parts of our estimation meetings.
- Some meetings are explicit scrum meetings, like your daily standup, iteration planning, and retrospective, but you generally also have design meetings and reviews that are part of making good software. The latter are a lot more important to have experienced technical guidance in than the former.
Best Answer
You're right when you say:
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.