Voting Someone Off the Island on an Agile Team

While I enjoy the discussion of how you go about dealing with a team member who's a bad fit, I don't see that this is a new problem in the world of management. Sometimes managers have to show people the door, whether it's due to poor performance, poor attitude, or both. It's a big part of the manager's job description, in fact - hiring and firing. And the same issue applies if the "manager" of an agile team is the team itself.

What a wonderful minefield to be discussing. The team (or influencial individuals) now has the power to eliminate team members they don't like.

Nice to see nasty corporate politics creeping in at every available opportunity. Especially in the very common case where there is no other place/team to realistically go.

Here are some examples with a team with high trust, and high commitment.

One player was eroding the codebase with undisciplined hacking, undoing other people's work. After several requests, and even attempts to improve his style through pair teaching, he remained impervious to the team's agreed-upon standards. The team "sandboxed" him - took him off the collective codebase and put him on special "swat" projects. Both team and player were happier, and productivity was improved.

In another case, someone was moved to another team whose style was more comfortable for him.

And in a third case, someone "voted themselves off" before we got to him. Collective code ownership and pairing were so uncomfortable for him that it was less stressful to quit than to stay. We were happy that he'd found more suitable work.

In all cases, frank discussion, guided by a desire to deliver more business value (not personal vendetta), led to better outcomes for all involved.

And, yes, I can also see how it could all go wrong. As always, malicious players make this a whole other game.

Heck, I hate how line breaks are removed from our posts here. Gonna have a word with our tech team. :-)

Are you saying this doesn't happen already? There've always been ways to get rid of someone you don't like.

Look, if you're on a team that is going to get rid of you simply because it doesn't like you, then you're already in a world of hurt. Who does the eliminating hardly matters on such a dysfunctional team.

I, too, have seen this work.

On "The Best Team I Ever Worked With" (tm), we had a team member that was just basically not up to the job. Steps were taken to try to help this individual but the problems were pretty deep. The team put up with it until it started to affect some of the others. At that point, the senior team members went, together, to upper management and basically said: "We're sorry, but we need this person gone. They are hurting the team".

Senior management trusted the team so much, the person was transferred off the team the same day.

What about the other interesting part

Self Selection. The principle talks about the ability of an individual to have the maturity to conclude that Agile is not for him.

If a team member is being disruptive, they should be asked to leave the team if the team can't help them improve. Team members aren't always going to get along right away, but as long as there is honesty and trust, most teams will get through something like this but again, the team should have the authority to ask a team member to leave if it gets that bad.

Should team members also take a pledge before joining a team?

More seriously - underperforming employee is an issue in itself and has nothing to do with a project management style. If a person does not deliver - no team or style can help. The talk about "fit to the team" can't be serious. After all, it's not a marriage we are talking about, team members to need some "chemistry". We are talking (or should be talking) about a team of professionals.

Sorry, but this sounds too naive, at best.

Actually, my experience tells me it IS like a marriage. I would contend that bad team chemistry has killed far more projects than technical challenges have, or ever will.

I'll make an analogy to the army: anyone can be taught to fire a gun. It's a whole other thing to mold 30 guys into a platoon. Developers sometimes hate to hear that because, in our world, technical skill is supposed to be king.

A good team has a wide variety of personalities and people playing different roles: Thinkers, Doers, "Doomsayers", etc. Getting all these personality types to play well together takes a lot of work.

Army is a hierarchical management structure with no democracy whatsoever, the opposite of an agile team. Try telling a platoon commander that platoon soldiers should be able to "vote off" somebody. You'll love the reaction.

Also, I am not saying that underperforming employee is not a problem, but excuse my skepticism: if somebody does not pull his/her wait off, a different team won't change that, so it's not an issue of a specific team. Underperforming employees should be taken care of by hiring managers in a manner that does not leave the company legally liable. Workplace is not a bootcamp. "Voting off" somebody sounds way too much like ganging up against somebody and you won't like the reaction of a judge if the voted off employee decides to sue you for discrimination.

I beg to disagree with virtually all of your points, with all due respect.

The army has forgotten more about team building than our industry will ever know. It may be ultimately authority based and hierarchical but the great feats performed by soldiers don't happen simply because someone ordered them to do it.

Also, just because someone isn't a fit for MY team doesn't make them a bad employee. I've seen many instances where a change in team makes a huge difference. It might not work out that way but it's not a slam dunk that a poor fit on a team equates to a firing situation.

Finally, yes, we do have to worry about legal liability in this day and age. Part of voting someone off the team may be working with HR to get it done. Ultimately, I don't really care all that much so long as the square peg is removed from the team.

ahhh...what a minefield. Just like I figured. I am not saying it is not a good idea. Just that it is a minefield and corporate politics again has an avenue of assault.





The army comparisons are especially good. :)

Yes. I worked with a team for two weeks. During that time, one of the team members confided in me why pair programming wouldn't work for him. This was not the usual pushback: I found his reasons compelling. Within two months after pairing because standard operating procedure he quit with no hard feelings on either side. He realized that it wasn't healthy for him. Smart guy.

I've seen several people quit or request to move to other teams. Typically, we wish them well and everyone is happier - including them.

In fact, people cannot work as a team without common agreements. In my teams we sometimes call these "team norms" and "team values". These are living documents that exist to help the team pull in the same direction, and also to detect when they start pulling in different directions, so they can discuss the misalignment and correct. Correction may involve changes in an individual or group behaviour OR a revision of the norm to fit better for today's reality.

For me, implicitly, the "pledge" of a serious team member is: I commit to collaborate with you guys to pull in the same direction or else I will collaborate to help redefine our direction (and, if all else fails, I'll leave you and go off in my own direction, so as not to bother your work). Anything other than this is not teamwork, imo, it's something else. Something that lives quite nicely in cubicles :-)

I find the whole argument of Agile a bit too idealistic. Especially the article provides a highly textbook-ish advantages of the framework. Agile wants us to believe that people are able to make rational choices! However in reality, things are a bit different.

In the IT la-la land where egos are bigger than Hummer H2 or where people don't generally accomodate others and there pace of working, the whole setup slowly descend into ghettos. If you fit into the culture then everything's ok else you are ostracized. I read somewhere in these comments that it is like marriages. And we know that where marriages or families have been heading.

I'm skeptical about the benefits and I surely wouldn't want the teams to be totally self serving. Btw I am not a control freak.

Mr Magoo,

it's all about money, ma friend, and anythin else is just child's play :)

I pretty much agree with the practice, given that the outcast has been given enough time and support by the other members of the team to adapt.



Sometimes it can be very difficult, for example in small realities: if you work in a little firm and maybe there's just one team voting a member off pretty means having her fired, with all the consequences... but would that be wise? The (ex) team member might be a very good professional, and bring substantial benefits to the company, for example she can have good testing and problem solving skills, thus considerably shortening defect fixing time. She could also be a very good programmer and effectively contribute to the codebase. "Only" she would not fit in the team. In these cases you can be saved by the fact that in small firms you have to do pretty much everything, from screwing a second NIC on to your motherboard to planning for the next release with the customer. It can then be easy enough to factor out something for the "outcast", but you should be very careful dealing with the "human" part of the transition, you just can't say "hey you're a burden for the team, they don't want you to work in their projects, but you should stay in the very same office." After all, even if some technical people would strongly disagree, the most important thing for a team to be a good team is not technological eccellence but the chemistry of the relationships between the team members.



You want everyone to be happy while at work (also when they're off work, but at least that is not your responsibility) so you must act with intelligence and find the right solution.



Sometimes the right solution is just a sacking.



You can find this and other thoughts here.

I just spotted this ... it goes beyond "work style doesn't fit with the team" and "poor engineering skills" to workplace bullies - it does happen and should not be tolerated: <snip> There is a growing trend in companies to consider the Total Cost of Jerks (TCJ) impact on the work force, including several organizations on Fortune’s “100 Best Places to Work” ... </snip> tinyurl.com/6dtkpl

The article recommends: *** Institute a “no-jerk” policy. *** Nip jerky behavior in the bud. *** Institute 360-degree performance reviews that allow employees to honestly assess their bosses and coworkers. *** Allow employees, when possible, to transfer to new supervisors if there are serious conflicts. *** Obtain exit interviews and take action on them.