22

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?

Improve this question
6
  • 5
    Should this be moved to pm.stackexchange.com ?
    – Abdel Raoof Olakara
    May 17, 2011 at 12:04
  • 1
    I'm not sure how this really relates to Scrum, or programming for that matter. "Dominant teammember overshadows everyone on team".
    – ozz
    May 17, 2011 at 13:26
  • 5
    I don't agree with moving to pm.stackexchange.com because Scrum master is not PM and Scrum project should not have PM.
    – Ladislav Mrnka
    May 17, 2011 at 13:59
  • 3
    Seems like you're the only one on your team who is concerned. Challenge him to a duel.
    – JeffO
    May 17, 2011 at 17:08
  • 2
    I miss important context in this question. It could be that 'dominant' dev takes more responsibilities because he genuinely feel scrum master is under-performing and is trying to improve team performance, maybe he wants to feed his ego and superior skills, maybe he acts in a good will and is just not aware of potential destructive effect on team, maybe he is just jerk... or maybe scrum master himself is the problem.
    – MaR
    Dec 5, 2011 at 12:18

10 Answers 10

Reset to default
17

The Scrum team is self organised so there is room for somebody who is a little more dominant. Others should ask him for his ideas about tasks they are working on, but his dominance must be kept under control.

What you can do:

  • Motivate others to be independent but collaborative - this can be best achieved if you co-operate with their manager and HR who will set them some expectations, which will be evaluated on a regular basis.
  • During stand-ups, planning, and retrospectives; let other team members speak first. During reviews, let other team members present user stories which they implemented.
  • Let other choose tasks first so that the dominant developer cannot only choose tasks that he wants to do.
  • Involve pair programming for some tasks so that the dominant team member is collaborating with other developers.
  • Be Democratic - the opinion of one team member is not enough to make changes to the process - Scrum will only work if the team communicates clearly, or you will just be blocking each other.
  • If none of this helps you should speak with the dominant team member and explain the situation to him - but beware there is no team leader in Scrum for a reason. If you have support from management you could also threaten his job stability, but this should be the very last option.

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

Improve this answer
14

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.

Improve this answer
2
  • 1
    Simply excellent answer.
    – Ladislav Mrnka
    May 17, 2011 at 19:54
  • I like your focus on the feedback.
    – cringe
    May 18, 2011 at 10:37
7

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.

Improve this answer
1
  • 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, 2011 at 12:49
5

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.

Improve this answer
10
  • 3
    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, 2011 at 13:25
  • @james: could you tell me why?
    – user2567
    May 17, 2011 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, 2011 at 14:20
  • 1
    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, 2011 at 15:22
  • 1
    @Pierre - it's a lot harder to fire people in the UK than say the US. But showing a pattern of bad behaviour and warnings, then yes of course someone can be fired. I'm not sure this particular situation would be easy to fire someone from in the UK. I could be wrong though.
    – ozz
    May 17, 2011 at 15:30
2

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.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
0

The sole task of the Scrum master is to make sure everybody plays by the Scrum book rules. If non-scrum masters would do that by themselves without interference of the Scrum master, that would just show you are in great (Scrum-)shape! The less the Scrum master has to do, the meaner and leaner your team is from a Scrum perspective. Eventually the role of Scrum master could/should be eliminated, he is there to get you started and teach you Scrum.

Again, the Scrum master does not participate in the development process. He should make sure all stakeholders communicate in time about the right things, he knows Scrum and provides guidance doing Scrum, he is not a product owner or project leader. If you experience something different, you may not be doing Scrum in the agile spirit. Of course, in smaller settings Scrum master could be a role one of the team members or stake holders plays on the side. Then it is just a cap one puts on when it is time for formalities. Do not confuse it with a leadership role, it is a guidance role.

Improve this answer
-1

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.

Improve this answer