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!
You make some really good points there Derek – I will be watching myself to make sure I don’t fall into that dominant category!
Does Scrum recognise the difference between followers and leaders? You need a healthy balance between the two I think. Too many followers and the team drifts along aimlessly; too many leaders and the tension prevents progress. But a team that has a different leader for each discipline or domain is a healthy team as long as one person doesn’t try to lead in everything.
Scrum is quiet on the topic of followers or leaders except to say that there is no concept of Team Leader or Head BA or Lead Tester etc. In Scrum, everyone in the Development Team is a Developer.
My experience has shown me though that it’s rare to have a Scrum Team that does not possess a mix of natural leaders and followers. That seems healthy to me.
I like this article.
How about an article that tells us how to deal with a team member who is not committed, not self driven, not motivated? More like..lazy to be honest.
For example he/she says i am working on this today.I don;t knwo how much time it takes.Tomorrow he says I am working on the same thing today, did not succeed yesterday, i don;t know how much time it takes.Even if you push him by constantly asking updates and ask for estimates. still..how to make him motivated?
Thanks for the comment and an excellent idea for an upcoming article. Watch this space 🙂