Two questions:

  1. I assume that when Scrum coaches say "the team should decide" they mean there has to be a consensus decision process usually facilitated by the Scrum Master?

  2. What if there is a disagreement between members of the Scrum team on the way to develop/design some feature and a consensus cannot be reached, who decides? The Scrum Master? The system architect? The funcional manager?


  • 2
    For Q #2, the unfortunate answer is that the team still decides. That is to say, the disagreement needs to be resolved in one form on another. The parties in opposition either need to come into agreement, or one party needs to accept it won't get its way this time and willingly concede. Bumping the decision to another party will only build resentment. Also, in my experience, conceding once in a while can be a good team builder. It means you show faith in the other party.
    – MetaFight
    Feb 1, 2014 at 14:40
  • 1
    The team should decide answers to both #1 and #2. They should decide if they need a consensus, or follow someone with enough clout, or however they want.
    – CMR
    Feb 1, 2014 at 14:45

3 Answers 3


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.

  • I've seen what you call the "benevolent dictator" approach work as well. And like in your case, the dictator only needed to exercise his authority once or twice over the span of about a year. As long as your dictator doesn't go power hungry this is a nice way to speed up decision making :)
    – MetaFight
    Feb 2, 2014 at 1:02

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.

  • We also tried the "majority vote" thing for a while. Unfortunately this didn't work out well for one of our team members. He didn't quite get Agile development at first and so his opposition was often misguided. After a while our majority votes consistently dismissed his opinion instead of addressing the discrepancy between his view of the issue and the rest of the team's view. Eventually the team member gave up on getting used to Agile and became resentful of the rest of the team. It became increasingly difficult to work with him. So, that's my warning about non-unanimous decisions!
    – MetaFight
    Feb 2, 2014 at 1:07

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.