Working with dominant or aggressive team members.

Is the request to "deal" with the aggressive or dominant team member (or Product Owner) coming from the Development Team?

Keep in mind that one of the responsibilities of a Scrum Master is to help remove impediments that hinder a Development Team's ability to deliver.   At times, this may be another member of the Development Team.

Is the request to "deal" with the aggressive or dominant team member (or Product Owner) coming from the Development Team?

Keep in mind that one of the responsibilities of a Scrum Master is to help remove impediments that hinder a Development Team's ability to deliver.   At times, this may be another member of the Development Team.

I asked the question sort of openly as in, what would you say to someone who asks such a question? Also, how do you deal with someone like that who also has management support? Do you learn to just live with that type of conflict?

Whilst, the Scrum Master may help to remove impediments, in this case, removing may be the last sort, What are the in between things that a SM can try before taking more drastic actions? Again, what if the Scrum Master can't remove a person because of the management support?

Lastly, if a Scrum Master has to consider removing someone, would it be from the perspective of removing an impediment for the Development Team (as in a Dev Team member) or otherwise for example in the case of the PO?

Steve,

I think this question of yours would benefit from more context.   

• Why is the team member or Product Owner being viewed as dominant or aggressive?   
• Is this observation coming from the Development Team?
• What does an aggressive or dominant Product Owner even look like?
• Is the Development Team still meeting their Sprint Forecasts and Sprint Goals?

@Timothy Baffa, I believe what I mentioned earlier is sufficient detail. It's more or less on the lines of "How would you deal with a difficult person?"

• Why is the team member or Product Owner being viewed as dominant or aggressive?   
• Is this observation coming from the Development Team?

PO or team member is viewed as dominant or aggressive because they control the shots, they do all the talking, they make all the decisions without consulting others, their tone of voice, their demeanour all are intimidating to others within the team or in the case of a team member, it could just be a difficult person who thinks highly of himself but is too powerful to be dealt with by junior members, sometimes even by a scrum master.

• Is the Development Team still meeting their Sprint Forecasts and Sprint Goals?

Though I think this is irrelevant to this topic, Let's say they are able to do so.

PO or team member is viewed as dominant or aggressive because they control the shots, they do all the talking, they make all the decisions without consulting others, their tone of voice, their demeanour all are intimidating to others within the team or in the case of a team member, it could just be a difficult person who thinks highly of himself but is too powerful to be dealt with by junior members, sometimes even by a scrum master.

Is this behavior because of the knowledge & skills this team member has ?

What are some ways the Scrum Master can help dealing with such people especially when the management supports the aggressive or dominant individual(s)?

I'd try to find out whether this "management support" is a new thing. If it is, then it might be possible to deal with it using a comparatively light touch before it takes root.

If it is well established on the other hand, then management may have to recognize and deal with it strategically. The first step they need take is to communicate a sense of urgency for change. Agile transformation requires organizational gravity to be overcome, and issues such as this are perhaps best addressed in that context.

their tone of voice, their demeanour all are intimidating to others within the team or in the case of a team member, it could just be a difficult person who thinks highly of himself but is too powerful to be dealt with by junior members, sometimes even by a scrum master.

I'm sorry, but it makes a significant difference whether this is feedback provided by team members, or this behavior is based on Scrum Master observations.

• Is the Development Team still meeting their Sprint Forecasts and Sprint Goals?

Though I think this is irrelevant to this topic, Let's say they are able to do so.

This isn't irrelevant at all, Steve.   If the Scrum Team is consistently meeting their Sprint Forecasts and Sprint Goals, and the dysfunction (aggressive/dominant behavior) is simply observed by the SM, why must any 'action' be taken at all?   Perhaps the "light touch" as Ian suggested is one option, but doing nothing is also an option, especially if the Scrum Team as a whole is functioning well.

I'm sorry, but it makes a significant difference whether this is feedback provided by team members, or this behavior is based on Scrum Master observations.

@Timothy Baffa, Thank you for being kind enough to repeat yourself. Yeah, I see what you're saying and I thought it would have been clear from my line of 

it could just be a difficult person who thinks highly of himself but is too powerful to be dealt with by junior members, sometimes even by a scrum master.

The situation is such, that team members are too afraid to talk about the person in concern, this could be the person on the Development Team or it could be the person playing the role of the PO. There is still a command and control mentality amongst some people within the organization, primarily because of their tenure and experience and as I mentioned before management support. I keep saying management support because the situation was so bad that it had to be brought to the reporting manager and yet the manager didn't take any action that was transparent to the team, the person who was creating the problem still had a free rein and the teams silently continued to work.

• Is the Development Team still meeting their Sprint Forecasts and Sprint Goals?

Though I think this is irrelevant to this topic, Let's say they are able to do so.

This isn't irrelevant at all, Steve.   If the Scrum Team is consistently meeting their Sprint Forecasts and Sprint Goals, and the dysfunction (aggressive/dominant behavior) is simply observed by the SM, why must any 'action' be taken at all?   Perhaps the "light touch" as Ian suggested is one option, but doing nothing is also an option, especially if the Scrum Team as a whole is functioning well.

So, when you made the above statement and I replied on the basis of only tackling the "problem" vs introducing other things like the Sprint Goal being met.

You are right, if everything is going smoothly inspite of the conflict, it may be okay for the Scrum Master to not butt in, but the question is, is the Scrum Master noticing a situation where silent frustration and dissatisfaction is festering. I think it is okay for a Scrum Master to gauge the situation and take appropriate steps when needed. Let's also further assume that these issues are not discussed in the Retrospective.

In the case I was describing, even the Scrum Master of this particular team felt helpless, there was nothing she could do other than live with the status quo.

In that context, I was trying to see if there are any further things that could be done before its just left the way it is.

First, @Steve I am sorry you are having to deal with this kind of situation.  But unfortunately I have seen it over and over. And I'm feel pretty confident in saying everyone reading this has also encountered it. I have even had a situation where management actually tried to address it, it worked for a period of time and then the difficult person reverted back to their old style.  I really sucks to have to deal with this and it will most likely be a ongoing battle. 

Scrum Masters remove impediments but there is nothing that say they have to do all the work to accomplish it. Just as the Product Owner can delegate some of the Product Backlog activity, so can the Scrum Master.  Plus if the Scrum Master always does the work, the team never learns how to address impediments on their own. 

One way that I have dealt with it is sort of a crappy way but it has worked.  The summary of the technique is to help the team come together and overpower the difficult person. I feel dirty every time I do it but it is effective and it comes from the team. Since it comes from the team, they will usually deal with it long term because they don't like the behavior. This removes this from being solely the Scrum Master's job and spreads it across all of the team. 

So how do I do it? Start with a Retrospective where you breach the subject. I bring it up something like this. "So I have observed and had a few people come to me with a concern about one member monopolizing conversations. Do any of you want to talk about this?" I remind everyone that the Retrospective observes "Vegas Rules" and the sole purpose is to improve the way we work together not to place blame on anyone. I will then constantly remind them during that Retrospective that nothing being said is an attack on anyone just constructive feedback. If that person is not their manager, it usually starts the discussion. It may stay generic in nature because people usually don't want to say "Bill you're a dick".  But as the discussion progresses, I start asking questions that start to identify the role the person plays in the team.  Then at some point I will address the elephant in the room and say "Are all of you talking about Bill?"  Then the conversation continues. This conversation will sometimes draw out frustrations about more than one person. At the end, I commit to the team to facilitate all gathering/discussions that they want me to be involved in. (Yeah I know that is SM duty anyway but sometimes it helps to remind them.)  When I facilitate I will actually interrupt anyone, not just the difficult person, that seems to be monopolizing so show that this is somewhat a common thing.  I interrupt with "I think we all have an understanding of your position. Now let's hear someone else. Jane what are your thinking about this?".  I usually will call on someone that is normally quiet to draw them out. 

This technique has been effective on may levels. It helps the team understand that tough conversations can be had in Retrospectives as long as they are not to place blame or attack an individual.  And it helps them to realize that constructive criticism can be useful. However, with all things agile, this is only effective if the individual(s) are receptive and willing to change. If this doesn't help, feel free to reach to me individually via LinkedIn and we can talk through this in private.  I am willing but warn you that I'm not an all knowing expert.  I have my own opinions and techniques but so does everyone else that contributes to this forum. I have learned a number of techniques or gained information that has influenced modifications to my ways from reading everyone that has contributed here.  I also know that sometimes it helps to have one person you can bounce ideas off of so that person can tell you if you are being an idiot. :-)

Good luck with this and always remember it will not change quickly but you can always affect change. 

Steve,

Thank you for the additional context.   It definitely helps understand your inquiry better.

For me, there is a clear difference between an overbearing Development Team member and an overbearing PO.

In my opinion, the PO situation can effectively be addressed through a Scrum Master's dedication of Scrum.   In Scrum, PO's are simply not allowed to exhibit command/control behavior over the Development Team.   They cannot push work to the Dev Team, and the Dev Team must have autonomy to decide what they are capable of completing each sprint.   The PO must perform their job within those constraints.   The Scrum Master has authority here to not only ensure correct Scrum is practiced, but also to educate everyone on why this is a better way to work.

It is a different case to me as a Scrum Master observing a team dynamic where members are silent in the face of a controlling or dominant Dev Team member.   Even when such an individual has the support of management to perform in a super-hero role within the team, the SM can highlight this behavior to all parties and point out the fragility behind it.   How does the organization expect to keep work moving forward if the super-hero team member becomes unavailable for a period of time for whatever reason (illness, personal reasons, time off)?



The SM can also educate everyone on strength in diversity, and how such a practice can apply to the Dev Team to encourage everyone to share their opinion.

Perhaps the SM can employ a few team-building exercises and outings to help the team familiarize themselves with each other and begin to support the team moving from Storming to Norming.   When one team member dominates like that, it also exhibits a lack of Respect for other team members, which is one of the 5 Scrum Values.   Education and discussion around the Scrum Values can also be beneficial.

Hope this helps.

What are some tactics members of a Development Team can use to deal with an aggressive or dominant team member (think from the side of junior members) or a Product Owner.

What are some ways the Scrum Master can help dealing with such people especially when the management supports the aggressive or dominant individual(s)? What can the Scrum Master do if all his/her efforts fail in this regard?

Agree with Daniel I think this is a common occurrence.

I have done a couple of things in the past; Changing the employee appraisal objectives to be behaviour focused as well as technical.

At each retrospective, I ask whether the team has or has not conformed to the Scrum values:

• Courage
• Focus
• Commitment
• Respect
• Openness

I have called out respect as it doesn't sound like that employee is displaying much of this, perhaps he needs drawing back to the values of the framework to which he is working in.

If you cant stick to the values, you loose your place on the team...

Also...

Collect evidence of the behaviour if necessary, employee statements, impacts to moral, its much easier to fight a case with management when you put it in evidence based facts in black and white in front of them.

I totally agree this isn't a situation you can ignore, otherwise your not conforming to the scrum value of courage to deal with the situation at hand out of respect for your wider team.

Just don't be a manager, be a coach. There maybe an underlying reason for this behaviour, have you tried talking 1 on 1 and asking whether they are ok? Everything ok at home? for me, the SM role goes beyond deliverables.

Interesting discussion. In the years I've been scrum master, I've learned there are many theories about team and group development which are very useful to a scrum master. For instance, Lencioni wrote a book about five dysfunctions of a team, but also Tuckman is a bit older but a useful theory.

It would be worth to investigate how your team is doing as a team and which dynamics create, encourage or sustain such a situation. Often you can find a good one to influcence this. You have more means to your disposal than just the Retrospective - imagine behaving differently during daily scrums or just during the day in the office.

Investigating your team culture and behaviour is difficult to do through a forum and that makes it difficult to directly hand you something to work with. It is difficult enough as it is, but once you get the hang of it, it makes the SM role so much more diverse.

Just found a wonderful example where the Scrum Master seems to be the dominant element. I am still not sure if this was written by a troll or if it is actually true. Anyhow, it is truly horrific: https://pm.stackexchange.com/questions/12693/how-to-deal-with-conflicti…