Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
There may be a situation when half of the self-organizing team isn't accepting a decision proposed the the other half of the self-organizing team. This situation effectively stops the project's progress.
Is it a flaw in self-organizing teams concept?
It doesn't matter whether the team is evenly split - even if only a couple of members of the team are disagreeing with the rest of the team, then the whole team may become just a group of individuals working on assigned tasks.
If the team is truly self-organizing, then the members would recognize that they have an issue that needs outside assistance and would, among themselves, find a way to resolve it. One option would be seeking someone else, either inside or outside the organization, who is a subject matter expert who can provide an expert decision. Another option would be to find someone who can moderate a discussion and facilitate a decision-making process. The team would be able to find these and other options and then select a method of resolution.
In Scrum, "the team" is ultimately deciding how to implement stuff (within constraints that may be given by the organization.)
Of course, this depends on the team being able to work together and come to a consensus. If one half insists that code must be written in C while the other half doesn't accept anything but Java you don't have a coherent team anymore.
It would be the Scrum Master's job to lead the team to come to a consensus, but he's not supposed to dictate a decision. Depending on the individual members of the team, this may be a pretty hard task. If someone said that Scrum Master is an easy role that you can do on the side they've been lying...
Self organizing is not an automatic statement about a SCRUM team. You don't get it simply by using SCRUM. The goal is to get to that point, and SCRUM's advocates claim that it helps you get there.
The self organizing concept is tempered by a key line from the SCRUM guide
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
While the development team is free to choose how to approach the work in the backlog (self organizing), they are accountable for completing the work. SCRUM says that leadership should not assign accountability/blame to any one team member, but they can assign it to the team as a whole.
If there is a major division in the team, but they can still be held accountable for getting the work done, that's just a particularly pathological version of a self-organizing team. And, of course, SCRUM won't recognize that particular division, but the team is welcome to be divided.
If they are not succeeding, then the team is held accountable. The SCRUM guide offers no guidance at all as to what this means. It's a case-by-case sort of thing. But it would certainly be reasonable for leadership to dissolve the SCRUM team and switch to another development model if SCRUM is not meeting business needs. Or, perhaps less drastically, implement an almost-SCRUM that includes some heavy handed forces on team dynamics to resolve a business concern. Maybe, after it is resolved and people's emotions are repaired, they can transition back from almost-SCRUM to true SCRUM.
I would hope that there would be substantial attempts to rectify the situation first. If you read between the lines on the Product Owner and SCRUM Master's jobs, you can see that part of their unofficial job is to help resolve these sorts of things before the team fails to accomplish their mission. Indeed, the Product Owner is identified as being accountable for the development effort as a whole, so they are on the hook to make the development happen.
Fundamentally, this is where the line between procedure and people sits. Good leaders know that they have to work with people, not just procedures. If your Product Owner and SCRUM Master are good leaders, they will already be trying to help you resolve this. If you have a team of aspiring good leaders, they will hopefully be trying to learn how to resolve this.
The chance that a team is evenly split on a decision between (options) and even after discussion becomes deadlocked exists but it is extremely small.
There is a higher chance that two people in the team have opposing opinions and adamantly hold to those opinions. In that case, the majority could push their idea through, but that will probably have the same result as when an appointed leader pushes their idea through: you get resentment in the team and the team starts to fall apart into a bunch of people that are assigned to work together.
The most common situation with self-organizing teams that I see is that various team members are seen as subject-matter experts in different areas of the project and when a discussion comes up involving their area of expertise, their opinion is given slightly more weight by the rest of the team.
If a deadlock threatens to occur in a team, self-organizing or not, then someone should either step up as a mediator or escalate the problem to get someone in as a mediator who is trusted by both sides to be impartial.
It is part of the Scrum Master's responsibility to remove impediments and the Product Owner's responsibility to optimise the value of the team's work. Clearly they should have a role to play in resolving this kind of problem. Other specialists could be consulted to provide another opinion.
Making teams self-organising doesn't guarantee co-operation, it just creates a good environment in which the opinion of team members is valued and innovation is encouraged. Ultimately, self-organising doesn't have to mean self-managing however and realistically a line manager or other senior will usually have something to say if progress is stalled by the team's indecision.
"Sometimes ... authority has its privileges."
You prefer not to have to use it, but if a "self-directing" team is deadlocked, sometimes you need to reach down, grab the log, pull it out of the stream and throw it up onto the bank.
