Picture the scene: As a ScrumMaster, you note that your team has gradually become deferential to a very dominant team member. This team member isn’t always right but their natural domineering style just sweeps the team along with them. You feel certain that it’s harming the team and want to address it. But how do you deal with it?

Having to deal with domineering, arrogant or ego-centric developers within Scrum teams is not common but, it happens. How you deal with the situation is a very important skill for ScrumMasters to learn. Here are some approaches.

Put a Bit of Stick About

We could fight fire with fire. When we observe the dominant developer (let’s call him Dominic. As in ‘Dominic the domineering developer. See what I did there? I know, I know. Humour’s not my strong point. Let’s move on), we could call him out on his behaviour. However, if we do this, the team are going to start to look to us, the ScrumMaster, for future guidance. All we’ve done is assert ourselves as more dominant and made the situation worse. This isn’t what we want at all. We want the team to be self-organising.

Have a Chat

We could pull Dominic to one side and have a chat about his behaviour. Is this likely to succeed? In my experience, probably not. Dominic probably isn’t dominant because he’s an ass. Dominance is more likely to be a part of his character. If we have a chat with him, he may try and tone the dominance down but when the pressure’s on, he’s likely to revert to type.

Take it to the Team

All good ScrumMasters know that it’s not their job to manage, or direct, the Scrum team. You can guide, mentor or advise but you categorically don’t tell the team what to do. So what do you do when you’re faced with a Dominic problem? Standard text for the ScrumMaster is, as Lyssa Adkins put’s it, “Take it to the Team”. But, in this instance, the team have already decided to defer to Dominic.

So, at this point stop and ask yourself a question. Are you SURE that Dominic’s dominance is bad for the team? You’ll need to be sure because you’re looking to override a team decision based on your belief and this is an arrogant step to take. Still sure? Ok. Let’s try the next option.

Influence, Don’t Command

Whenever you need to encourage a team to go your way, you need to call on the power of influence. A great way to achieve this is to adjust one of three things:

• Containers – The boundaries within which self-organisation occurs
• Differences – Personal differences between team members
• Exchanges – Interactions that change or influence team members

nb: For more information on Containers, Differences and Exchanges see Glenda Eoyang’s doctoral dissertation (2001)

Altering any of these three elements will influence how a team self-organises. In the case of Dominic, we could adjust the Differences element by adding in a new team member that would balance Dominic’s effect on the team.

Maybe we could add in a more technically able developer who is already well respected within the organisation. One who is not as dominant but has a gentler style? Perhaps we might try an equally dominant individual in the hope that they’ll balance each other out?

There are a myriad of changes you could make but do monitor the effect closely and don’t change too much at once. You don’t want to end up replacing one problem with an even worse one!