Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

My team is facing a difficult quandary, a couple of team members are essentially selfish (not to be confused with dominant!) and are cherry-picking stories/tasks that will give them the most recognition within the company (at sprint reviews etc. when all the stakeholders are present). These team members are very good at what they do and are fully aware of what they are doing.

When we first started using agile about a year ago, I can say I was quite selfish too (coming from a very individual-focused past). I took ownership of certain stories and didn't involve anyone else in it, which in hindsight wasn't the right thing to do and I learnt from that experience almost immediately.

We are a young team of very ambitious twenty somethings so I can understand the selfishness to some extent (after all everyone should be ambitious!). But the level to which this selfishness has reached of late has started to bother me and a few others within my team. The way I see it, agile/scrum is all about the team and not individuals. We should be looking out for each other and helping each other improve. I made this quite clear during our last retrospective, that we should be fair and give everyone a chance. I'll wait and see what comes out of it in the next few sprints.

In the meantime, what are some of the troubles that you have faced with selfish members and how did you overcome them?

share|improve this question

closed as off topic by Walter, Jim G., GrandmasterB, gnat, Dynamic Oct 2 '12 at 10:20

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here. If this question can be reworded to fit the rules in the help center, please edit the question.

I do not think that dealing with a selfish team member is different in SCRUM than in any other context: being selfish is against team play, regardless if you are in an agile team, V-model team, football team, basketball team, and so on. A selfish member puts his / her own interest before the interest of the team and I think there are only two solutions: either they change their attitude or they leave the team. –  Giorgio Sep 30 '12 at 9:03
Good point, I have slightly edited my question to make it less specific to agile. –  thegreendroid Sep 30 '12 at 9:14
How on earth can a single team member work on a story alone? –  Falcon Sep 30 '12 at 11:00
If there is enough traction on the other higher priority stories within a sprint, we often find ourselves working on a story alone. –  thegreendroid Sep 30 '12 at 15:05

6 Answers 6

up vote 10 down vote accepted

The main way of dealing with this is pair programming, code reviews, automated tests and documentation to spread around the knowledge. Once this is done, the team manager may have to "bend" the scrum rules by "encouraging" giving the workload to others to ensure that, if the selfish team members fell under a bus, the team would be able to continue. Similarly, if selfish team members go on leave, make sure to have others ready to pick up tasks in these areas.

If it continues and starts to be detrimental to the team, this becomes a performance issue for the manager and the team member(s). Scrum and agile are useful tools but, like any system, they have their flaws and can be abused.

This may be an issue with the wider corporate culture. For example, is the performance of team members compared and stack ranked or bell curved directly against their peers? Is there a limited bonus or pay rise pool team members are competing for? If so, the problem may be bigger than just scrum or agile.

share|improve this answer
I think your last paragraph nails it. This kind of "reality TV" behavior, complete with selfishness and sabotage, is common in organizations that use Rank and Yank methods. –  jfrankcarr Sep 30 '12 at 12:09
Completely agree, I think it comes down to the wider corporate culture in my company. We do use Rank and Yank methods as @jfrankcarr put it. –  thegreendroid Sep 30 '12 at 15:03
What company has unlimited means to give bonuses and/or pay raises? –  Chris Pitman Sep 30 '12 at 18:10
@Chris Few, if any, companies can provided unlimited bonuses or pay rises but companies where bonuses are a large proportion of remuneration with a competitive culture discourage teamwork. A change to base 50% of the bonus on team performance rather than solely on individual performance would discourage this type of activity. My point is that you may need to look beyond agile or scrum to find causes of the issue. –  akton Oct 1 '12 at 1:16
Our company splits the bonus basing like so: 30% based on company performance, 50% based on our group, 20% based on the other groups. This makes it more important for the groups to succeed, not for individuals to try to outshine each other. Meeting annual personal goals set by ourselves affects how much our individual total bonus might be, but if I do one or a dozen stories more than someone else that helps our group rating but doesn't push me ahead of anyone else. –  DaveE Oct 1 '12 at 22:56

Selfish team mates - well, that doesn't sound too unfamiliar. I am not sure about agile projects, but in a regular project, the easiest way to get around is using lottery. Use an un-baised lottery system (could be as simple as, drawing straws!) to allocate tasks to people - this way everyone will get a chance to shine.

share|improve this answer
Drawing straws - best randomization algorithm since childhood. –  mcwise Sep 30 '12 at 8:44
Team members feel less empowered and members may not be assigned tasks that match their skills or experience. However, if this truly is a problem, the team has demonstrated their inability to assign tasks themselves, anyway, –  akton Sep 30 '12 at 12:13
Nah, just give everyone a random (return 4; // chosen by fair dice roll) task. –  DeadMG Sep 30 '12 at 12:15

Team Formation

It is a common model that teams go through a kind of cycle than can be described as forming, storming, norming, performing. It sounds like there is still some storming going on, and hopefully you will have some tools to move forward.

Team Composition

You mention the team is composed of ambitious twenty somethings. If you hired a team with no diversity, it should be expected that rather than find niches, a battle for king of the hill breaks out. If it is a team where only twenty somethings are welcome, perhaps they figure they have to move up or out by the time they are thirty. It may not apply to you specifically, but for managers with teams that get more competition that cooperation, take a good look at the hiring (and perhaps firing) strategy. Sew the wind, reap the whirlwind.

Managers vs. the Cherry Pickers

Traditional organizations used supervisors and managers to define projects and assign work. A person who was ambitious, fast, sloppy, doing only the first 20% of a task that won 80% of the recognition, was accountable to one person, potentially for their entire tenure with the company. You may not have precise control over how tasks are assigned, but I hope you can reassign tasks to make things more equitable. I particularly like to put broken code back in the hands of the person who broke it.

As soon as you can quantify what behavior must stop, you can discuss it perhaps at first obliquely to the team like "in the interest of the team, I don't want to see XYZ." When, I mean if, that doesn't work, you have set an expectation so you have context to talk to team members who ignore it directly. If you are a manager or a lead with position power, perhaps you have control over the team members through employee evaluations, hopefully via regular one-on-ones or less optimally, quarterly progress checks.

Mixed Messages about Teamwork

Generally, managers are drawn from the most ambitious people. People who may be too ambitious for the good of the team may rarely be disciplined, but instead promoted because they show an attitude that the manager wants to see more often. However, those type A and type double A managers need high performing type B workers to do the detailed work, so what happens before the pecking order is sorted out may not be pretty.

Researchers have observed a thing called the "Tiger Effect" or sometimes the "Superstar Effect" where when a star like Tiger Woods played, the rest of the field played less well. Many people have seen organizations that tolerate or reward the bragger, the grand stander, the cherry picker, create teams that are out of control and have low productivity. Another unintended consequence can be that in short order, the manager may compete with that person as a peer or have that person as a manager.


The Association for Computer Machinery (ACM) and IEEE IEEE have a jointly developed code of ethics has some guidance on selfishly motivated behavior.

  1. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.

which is pretty general, but they expand it to be more specific.

Principle 7: COLLEAGUES

Software engineers shall be fair to and supportive of their colleagues. In particular, software engineers shall, as appropriate:

7.01. Encourage colleagues to adhere to this Code.

7.02. Assist colleagues in professional development.

7.03. Credit fully the work of others and refrain from taking undue credit.

7.04. Review the work of others in an objective, candid, and properly-documented way.

7.05. Give a fair hearing to the opinions, concerns, or complaints of a colleague.

7.06. Assist colleagues in being fully aware of current standard work practices including policies and procedures for protecting passwords, files and other confidential information, and security measures in general.

7.07. Not unfairly intervene in the career of any colleague; however, concern for the employer, the client or public interest may compel software engineers, in good faith, to question the competence of a colleague.

7.08. In situations outside of their own areas of competence, call upon the opinions of other professionals who have competence in that area.

share|improve this answer
That's such a comprehensive answer, I wish I could accept more than one answer! –  thegreendroid Oct 2 '12 at 3:17

If I were the project manager, I would work around this as follows:

  • If they are good give them responsibility for the deliverable and cut them a consistent and complete piece of work proportional to their capacity and skill set so that little interface is required with other team members, hence, their attitude problem will be contained without negatively affecting the end product.

  • If they are not good and behave in a way that affects the team or the end product negatively, well, you know what to do.

share|improve this answer

To the outside world, the team should be one. With some simple tricks, the Scrum Master and Product Owner can neutralize the ego's. hopefully you can turn that personal ambition into the ambition to make the whole team excel.

  • SM appoints a modest team member to do the entire show&tell. Don't let each programmer demo his own part.
  • at planning meeting, don't assign the tasks to people yet. Use generic resources (e.g. Programmer,tester)
  • PO should always address the whole team when commenting on a story. Or even on purpose look at the 'wrong' team member when (not) accepting a story.
share|improve this answer
Excellent suggestions, I'll definitely suggest these during our next retrospective! –  thegreendroid Oct 2 '12 at 3:14
Best answer! In fact scrum is about team work and not individuals. –  Oscar Feb 4 at 23:51

This sounds like a perfect scenario for your team to introduce the concept of Planning Poker.

Essentially it is a game that you play before the sprint begins, where everybody picks a card from their deck that represents a number of points for each story that they feel they would estimate the story if they were the one working on it.

In the end of the hand, the one with the lowest estimation gets the point, regardless of the visibility or recognition of the story. Unreasonable estimates require an explanation in the soap box and ultimately the moderator of the game can decide if the lowest estimate is reasonable. This helps avoid anchoring or favoritism.

The best part of this is that even if the selfish developers purposely play a low card on the highest priority user stories, they are now under the gun for that commitment and could very easily be setting themselves up for failure. This will just make them look really bad by comparison so it is the perfect incentive.

share|improve this answer
we are using planning poker to estimate our stories so this is not a problem. The problem is the members working on stories that provide the most recognition within a sprint. –  thegreendroid Sep 30 '12 at 14:55
@thegreendroid Then you are not doing planning poker correctly. If they are selfishly taking certain stories then they are always underestimating. If they get in a habit of underestimating too much then they will work long hard hours or get in trouble for not meeting their commitment. Planning poker if done right is more than estimation, it is also assignment. –  maple_shaft Sep 30 '12 at 20:31
@maple_shaft - The Wikipedia entry for planning poker doesn't talk about assignment. Nor IMHO is it a good idea - anything that makes estimation political is adding noise to estimates. –  psr Oct 1 '12 at 22:00
-1 for giving incorrect definition of planning poker and mixing up estimation and planning meetings. –  Kris Van Bael Oct 1 '12 at 23:07
@psr Yeah it turns out that I really have been doing it wrong all along. I guess in the last organization I was the PM's hijacked and modified the process into something political and to put even more pressure on the dwindling supply of developers willing to put up with their abuse. In hindsight this doesn't surprise me. –  maple_shaft Oct 2 '12 at 11:10

Not the answer you're looking for? Browse other questions tagged or ask your own question.