Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What would you do in a situation where a team member tries to take responsibilities are not initially assigned to him but to the Scrum Master?

share|improve this question

migrated from May 17 '11 at 12:16

This question came from our site for professional and enthusiast programmers.

Should this be moved to ? – Abdel Raoof May 17 '11 at 12:04
I'm not sure how this really relates to Scrum, or programming for that matter. "Dominant teammember overshadows everyone on team". – ozz May 17 '11 at 13:26
I don't agree with moving to because Scrum master is not PM and Scrum project should not have PM. – Ladislav Mrnka May 17 '11 at 13:59
In all reality if the team is producing working software in adherence to the Scrum process; let it be. Trying to give everyone equal footing is not the job of the ScrumMaster. Check out the stages of group development and identify where this team exists. They may be stuck in the forming stage. – Aaron McIver May 17 '11 at 15:06
Seems like you're the only one on your team who is concerned. Challenge him to a duel. – JeffO May 17 '11 at 17:08

The Scrum team is self organized so there can be somebody who is little bit more dominant and other ask him for his ideas about tasks they are working on but that dominance must be under control. What you can do:

  • Motivate others to be independent but collaborative - this can be best achieved if you cooperate with their boss and HR who will set some expectations for them which will be evaluated on regular basis.
  • During standups, planning, retrospective let other team members speak first. During review let other team members present user stories they implemented.
  • Let other choose tasks first so that dominant developer cannot choose tasks he only want to do.
  • Involve pair programming for some tasks so that dominant team member must cooperate with other developer.
  • Involve cooperation on user story - tasks from user story will be developed by more then one team member.
  • Involve democracy - the opinion of the main team member is not enough - it will work if other team members speak first
  • If none of this helps you can simply speak with the dominant team member and explain him the situation - there is no team leader in Scrum and job is collaborative. If you have support from management you can also threaten with some impact on his appraisal. This should be very last eventuality.

If dominant team member don't want to lose his dominance and passive team members don't want to be more active you will definitely need support from their boss and HR. This can be a problem if Scrum is not advocated by the management.

share|improve this answer

Presumably, the reason for this question is because you feel that the team is somehow under-performing because of this dominant person. Perhaps because the rest of the team aren't contributing 100% because, well, what's the point?

As a manager, if you are, it's your responsibility to make sure that all of your employees understand what their roles are. Specifically, what's expected of them and how they are going to be evaluated. As a team member in a Scrum team, each person is personally responsible for the success of the team. So this dominating team member needs to know that they're failing in that responsibility, and will be evaluated accordingly.

Feedback is a key point. If there's a team meeting and this person dominates the discussion, forces his designs and approach on the rest of the team and pushes the rest of them into passive roles then he needs to be told, bluntly and privately, that he's failing to meet the requirements of the role. If you spot him sneakily highlighting only his own personal achievements, then he needs to be called on it, and made to understand that personal achievements are valued far, far less than helping the team to have a group achievement.

All of which is tough, but that's what managers and Scrum Masters are for.

There's one other possible way to go about this. Make it a team problem. Call them together and tell them they are under-achieving and here's why. Ask them to come up with a solution. You might be surprised.

share|improve this answer
Simply excellent answer. – Ladislav Mrnka May 17 '11 at 19:54
I like your focus on the feedback. – cringe May 18 '11 at 10:37

Why not ask the alpha developer his opinion. It's entirely possible he has no idea of the effect he's having. Take him aside and tell him what you think. You could even couch the discussion of "hey you're our lead developer, but we need to bring these people up to your level, I need your help in working out how can we do it?". Turn his dominance into an asset. See if he can see ways of doing that.

If he's measured on how well he supports his team and brings them up to his level then he'll have more motivation to do just that.

You imply he's actually not working in the interest of the team (my guess), ie he's evil in some way, then yes, remove him. But a wise man once said to me: Don't assume ill will, when incompetance or simple ignorance are more likely.

share|improve this answer
That's an awesome way of re-framing the problem. Asking for his help completely changes the situation (and makes it a whole lot less scary). – Joe White May 18 '11 at 12:49

Looks like he tries to be the Scrum Master.

Clarify your positions, and act accordingly.

The role of the Scrum Master is to enable team spirit. If you are unable to make this one and only person be a team player, remove him from the team.

Quick note: Your dominant developer is no more problematic than your passive developer.

share|improve this answer
While a nice line, simply removing someone from a team is easier said than done in most cases I would have thought Pierre. – ozz May 17 '11 at 13:25
@james: could you tell me why? – user2567 May 17 '11 at 13:52
Well, having limited people to work on a project for one. Moving him to another team, the other team are inconvenienced and may resist. Knowledge retention on a project would be another (easy to say knowledge should be spread, but in reality it isn't). That's 3 very REAL reasons why it's easier said than done. Not that it can't be done of course. Of course maybe you mean fire him :-) ? – ozz May 17 '11 at 14:20
@james: Your first point is perfectly valid. Maybe it's not so easy to find a replacement. Because when I said removing, I was thinking about firing him. Being dependent on individuals is a real bad thing. Especially when he knows it, and plays with it. Which seems the case here :( – user2567 May 17 '11 at 14:43
I'm based in the UK, and having a dominant personality is not a reason to fire someone, you'd need a lot more than that! – ozz May 17 '11 at 15:22

currently sprint planning is a role that rotates across the team

Sprint planning should involve the entire team, not be handed to one person at a time. Unless there is a good reason for this I see this as a severe problem.

If what you are saying is true and objective then you have a major problem at your hands: people who do not participate and the "Dominator" who prevents a truly agile process. As the srum master it is up to you to take action. Maybe you would like to take your project manager into confidence about this situation.

share|improve this answer

Perhaps the "dominant" dev is rewarded by his individual performance rather than team achievements?

In the past I have made sure that people that are very vocal and have clear ideas are also rewarded (via their objectives) by fostering others contributions.

In general, I think it is a bad idea to reward scrum members solidly on their individual contribution rather than on team achievements.

You could also try doing a 360 feedback round in your team for all team members, only if you think the other team members will be truthful in their comments.

share|improve this answer

Many teams strays from the core of agile, and it is your job to bring them back. You need to teach and re-embed agile values into the the team. In fact, you should constantly be teaching agile values. Hold out your vision of agile, make it clear and powerful. Show them your commitment to "agile done well".

To do this, walk them through the agile manifesto and Scrum values. Ask them what collaboration means for them and why it is important. Ask them about the role of trust in agile. This is a great time to talk about why there is no team lead role and no project manager role in Scrum and that it is the whole team's responsibility to make great software, not the individual.

Plan an entire retrospective session around this. Get them to commit to some values and follow up during the next retrospective. Don't point fingers, use neutral methods.

Introduce methods that forces the other members to state their opinions safely. Something simple as fist-of-five is great for getting the silent voices in the team heard. It makes it painfully obvious that the team disagrees with the dominant guy. Planning Poker works well but the key is don't allowing any discussions before the cards are shown. Anything that helps getting the others heard without starting conflicts is helpful.

If that goes well, you're all set. Otherwise, talk to him about the problem. Use coaching and ask powerful questions that can help him realize the problem clearly. Try to get to the root cause why he has taken on the dominant role. Maybe he lacks trust in the team (why?) and maybe he feel he is responsible for success (why?). I suspect this role is not something he wants and quite possible he would like it to change. He may come around and realize it.

share|improve this answer

Propose that he becomes the Scrum Master for the following sprint.

People willing to take on responsibilities is not a problem (as long as they don't want monopoly over them), it's precisely what we're looking to achieve with self-organization.

Teams with a rotating scrum master role aren't uncommon, by the way.

share|improve this answer

Embrace individualism and individual performance, but also try to empower passive individuals to become more participative.

My experience says that although they might seem similar at first sight, communism and agile are not the same. Agile doesn't aim for a classless society (team) but for software that works.

Try to make your alpha developer understand that he could help you develop others skills by asking and coaching, rather than answering always first, and achieving individual accomplishments. Surely your alpha developer is one that cares about good software, and that's something you cannot allow yourself to lose.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.