I read an interesting post on voting someone off an agile team; you can only do it if you work in a self-managing team, just as it should happen when adopting agile methods. 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.
(Thanks to the site Implementing Scrum for the picture)
Mathematics cannot prove the absence of bugs
2 days ago