Dealing with selfish team member(s) [closed]

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Ethics

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.

Answer 5

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.

Answer 6

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.