Giving team members more decision-making power led to very long arguments, blocking progress since there is no one with the final say [closed]

Question

Currently we use Scrum with the exception that our Scrum Masters sometimes act as project managers rather than facilitators of the Scrum process. About half of the time team members pull tasks on their own, but half of the time the Scrum Master assigns the tasks to team members.

I would like us to fully adopt self-organizing teams. However when we tried giving team members more decision-making power, it led to very long arguments between team members, and since there would be no one with the final say, these arguments would block progress.

Do you think there is a way to minimize arguments with self-organizing Scrum teams?

Answer 1

since there would be no one with the final say, these arguments would block progress.

There's your problem, right there. Someone needs to have final decision-making authority. Figure out a way to make that happen.

You also might want to look into adopting a bit of informal parliamentary procedure. Folks highjacking a meeting is not a new problem, and there are already known solutions.

Answer 2

Start timeboxing your discussions. At the end, take a vote. Tie? Bring someone else in who can provide an unbiased vote. Although, it's not really recommended to involve "chickens" in decisions of magnitude.

At the heart of it, it seems like there is some toxicity within the team. Why? That may be a better question to start with. Bring it up to your Scrum Master. Maybe somebody is confusing ideality with reality.

You may also want to give your PM / PO (idealy) or SM final say. It's their responsibility to weigh the opinions and facts that others have presented.

Answer 3

Do you think there is a way to minimize arguments with self-organizing Scrum teams?

That's part of the scrum master job: get the team to take decisions efficiently and timely.

The blunt approach is to let someone (scrum master or other) to have the final say. But it's (imho) an abuse of power. A better approach is help the team to get a decision, for instance:

1. Get the team to agree when a decision is needed (now, in 30 minutes, tomorrow, in a month). This needs to be reasonable, don't force an artificial deadline (agile: take decisions at the last possible reasonable moment).
2. Get the team to agree on the importance of the issue and how much time it's worth spending debating it. I call that the bike shed limit. It's not a strict limit, but have them realize that spending a day arguing about something that in the end doesn't really matter is not the best use of their time. (Debate for the fun of it is another story, don't kill that!)
3. Tell them to work on an answer by the deadline, otherwise you're going to take the decision (don't tell them what your decision is going to be)
4. Actually do it. And stick to that contract.

Realize that's a scrummaster vs the team play, so tread carefully. You might end up taking more decisions than you're comfortable with, but any team worth its weight is going to figure out that they'd rather own at least some of the decisions and will work at it before you're forced to take them.

Answer 4

For many, giving a programmer control over task assignment is a privilege, so you have to make sure you operate under the business restrictions. In your case, it's the amount of time to decide.

Hopefully, everyone gets better at this with more practice. You could set a time limit and then the PM just steps in with an immediate ruling.

Also, your company has to decide if allowing the programmers to take a lot more time than the PM to assign tasks is better because they are more accurate, improves team morale and possibly holds everyone more accountable.

With some measurement, you can determine who actually does better assignments, estimates etc.

EDIT: Make sure team members aren't using this time to vent or possibly getting into technical/philosophical discussions. Arrange other meetings formal or informal to help them get this out of their system.

Answer 5

First I strongly disagree with the opionion stated in other answers that the SM should make a final decision. The scrum masters task is

• to get impediments out of the way, often by presenting them to the team, which otherwise might just ignore them.

• to help the team to become a good (scrum)team.

Taking a decision out of their hand is exactly the wrong thing to do.

Instead I'd aproach the problem the following way:

• observe: What is the actual problem? Possibilities might be

  • a conflict within the team, that manifests in constant opposition

  • not enough information thus, no proper basis for a decision

  • fear of being made responsible for a decision on thinks is wrong or at least not optimal

• present: make the team aware of the problem. Make the consequences of the behaviour obvious. The PO might want to present the damage this inability to decide makes. It also should be clarified that the PO demonstrates trust in the team and the team should act worthy of that trust.

• let the team solve the problem: In a moderated discussion (typical a retrospective) the team should come up with proposals for solutions and decide on one.

Actual solution might be:

• democratic voting with a way to break ties, for example by giving experienced developers a tenth of a vote more.

• decide on a team member that makes a certain kind of decision (probably after listening to the arguments of the others)

• timebox decisions

• properly prepare decisions by having clear phases: e.g. collecting of information, discussion, decision

• decision by consent, i.e. one doesn't look for a solution everybody (or the majority agrees to but, a solution which everybody can live with)

Answer 6

Someone on each team needs to learn some mediation skills. The scrum master is a logical choice, but it doesn't have to be him. You can hire people to teach a class to your company. Someone doesn't have to have the deciding say in order to effectively lead a group to consensus. Incidentally, even when someone has the authority to effectively dictate a decision, the team works much more smoothly when that person uses that authority sparingly, and instead uses mediation skills to come to a consensus as often as possible.

The topic is much too big for a post here, and also involves a certain degree of natural talent and a lot of practice, but here are some basic tips:

• As other answers have mentioned, agree beforehand to timebox your decision.
• Figure out how you will make a decision before trying to come to a decision. Possible methods for deciding who has the final say are:
  • Majority vote.
  • Take turns.
  • The person with the most to lose.
  • The person who touched the code most recently.
  • The person who touches that code most frequently.
  • The person who spent the most time researching that particular problem.
  • The person who has the best grasp of the customer requirements.
  • A manager or technical lead.
• Suggest compromises.
• Suggest competing ideas each submit a proof of concept for review before doing the final product.
• Often a decision is contentious due to lack of information. Figure out precisely what information you lack and suggest methods of finding it out before you come to a decision.
• Meet in smaller groups, or with both sides individually to hash out the concerns and get to the heart of the matter before trying to do it in a large group.
• Steer the team away from bikeshedding on trivial details. Suggest focusing on only the large decisions, then leave the details up to individuals doing the implementation.
• Point out areas where you agree, and see if you can proceed on only that basis.
• Realize sometimes you just need a ranting session when undertaking a large new project, to get the complaints out of everyone's system. Make sure everyone's concerns are heard and validated, ask for volunteers to investigate the uncertainties, then hold a second meeting. Almost always, fewer people come to the second meeting, and they're more in a mood to get things accomplished.

Answer 7

This is a very large question, much larger than just scrum. It reaches to the core of team play. The idea of giving more control to the individuals is to make them more efficient by removing red tape. However, there is a tradeoff. With red tape in the way, everyone is marching towards the same goal inefficiently. Take the red tape away, and everyone marches efficiently, but towards their own goal. If you have instilled a good sense of the overall project's goal in all of the individuals, this works great. If the individuals disagree on the final direction, then bickering begins.

I recommend two techniques beyond the obvious "unify your team goals a bit more": one is to give remove the red tape slowly. Give the team time to react to the changes, and see if they can re-align themselves. Sudden changes in development rules are much harder to get used to than the gradual ones. The second is to attack the problem from a higher vantage point. See if you can have a meta-control on the problem such as, "if I see bickering, the red tape comes back until we all calm down."

The last bit of advice I have is to never approach two team-members that are butting heads directly. By definition, they are in butting heads mode, and they won't mind butting heads with you as you try to fix things. Always seek to move them out of opposition, rather than trying to manually squelsh the opposition directly by making a decision for them.

Answer 8

I actually work using Scrum too.

We self-organize the tasks and whenever needed the Scrum Master have the final say. It's easy like that!

Just try to follow some directives:

• Team must agree when assigning tasks
• If they can't agree, don't waste time with endless discussion (never argue!). Take it to Scrum Master.
• Trust the Scrum Master's decision, everybody is on the same boat.

Hope these tips help.