Voting Someone Off the Island on an Agile Team
- Share
-
- |
Read later
Reading List
A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.
Agile teams are known to be self organizing and full of energy. They show a high degree of camaraderie which results in high productivity and efficiency. However, at times there might be someone on the Agile team who does not fit well with the team and pulls down the velocity of the entire team. Various members in the Agile community discuss the scenario of “Voting Someone Off the Island”.
Joshua Hoover suggested, in his blog, that the concept of voting someone off the island should be burned into the memory of every Agile team member. He added, since the Agile teams are self managing, they have full right to vote out someone that they feel is not a good fit. The only thing to be kept in mind is that the same rule applies for everyone, hence the decision needs to be taken diligently. According to Joshua,
The point is that self-managed team members have the power to say who is and isn’t on their team. It’s healthy for teams to get an unproductive member off the team after working with that person to address his or her problem(s). If improvements aren’t being made then it’s likely time to consider voting that team member off the island…errr…team.
In a reply to the above post Richard Baldwin added, if a team member is bringing greater tax than value then it does not make sense to pay the tax. According to him, on many Agile teams team members remain silent about a non performing team member rather than professionally resolving the issue. This leads to difficult situations and a dip in team productivity.
In a similar discussion on the Scrum Development group, Brent Barton suggested
We used to use “voting off the island.” This was not a hire/fire event because sometimes it is a team “fit” issue. Some members have had great results on other teams. Too many of these events leads to separations for obvious reasons.
According to Brent it is important to use the concept of voting out in the right way. Some teams get to this without giving a thought to balanced conversation and conflict resolution skills which are also important. On other teams this concept is de-emphasized to the limit that they do not feel empowered.
In the same discussion, James S. Fosdick added, if a person is voted off one team he should be deployed onto another one to see the chemistry there. This would take care of the condition that the person might be a misfit on a particular team. However, at the end of the day if the team is not interested in working with a particular team member then, voting off is fundamental to the principle of self organization and should be respected.
In a similar view on Implementing Scrum, Michael Vizdos shared his view on the reason and the way to vote a team member off the island. He mentioned,
Either this person sucks at their job, has no interest in being on the team, or really is just the type of person who will bitch and complain about anything and likes being heard. A team can be a powerful [good] force. Usually with some one-on-one coaching with this person, and the team — through daily stand-ups, working through user stories or tasks, or other techniques — the person usually can find some other place within the organization where they can make a difference.
Michael tried to look at it from another angle too when he talks about the concept of Self Selection. The principle talks about the ability of an individual to have the maturity to conclude that Agile is not for him. According to Micheal, if a person believes that he cannot work on the team then, instead of moving him away from the team right away he asks the team member to commit to stay on the team till the end of the iteration. This helps in not disrupting the sprint and at the same time the coach can work one-on-one with the person to solve any issues and observe if the person can work in the given environment.
Members of the Agile community agree that voting someone off the island is fundamental to the principle of self organization. The decision need to be taken diligently and teams may want to try out different options but at the end the decision of the team needs to be respected.
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Same as it ever was
by
Kurt Christensen
Posted
great...
by
Mr Magoo
Posted
Re: great...
by
Bruce Rennie
Posted
I've seen this work well
by
Deborah Hartmann
Posted
Re: I've seen this work well
by
Deborah Hartmann
Posted
Re: I've seen this work well
by
Bruce Rennie
Posted
Re: I've seen this work well
by
Vikas Hazrati
Posted
Has anyone seen that work?
by
J. B. Rainsberger
Posted
Re: I've seen this work well
by
Deborah Hartmann
Posted
I agree...
by
Jason Little
Posted
Sounds Like a Fraternity
by
Irakli Nadareishvili
Posted
Re: Sounds Like a Fraternity
by
Bruce Rennie
Posted
Re: Sounds Like a Fraternity
by
Irakli Nadareishvili
Posted
Re: Sounds Like a Fraternity
by
Bruce Rennie
Posted
Re: Sounds Like a Fraternity
by
Mr Magoo
Posted
Re: Sounds Like a Fraternity
by
Irakli Nadareishvili
Posted
Re: Sounds Like a Fraternity
by
Deborah Hartmann
Posted
Sounds like
by
S Ninan
Posted
Small realities
by
Andrea Maietta
Posted
Total Cost of Jerks (TCJ)
by
Deborah Hartmann
Posted
Re: Total Cost of Jerks (TCJ)
by
Deborah Hartmann
Posted
Same as it ever was
by
Kurt Christensen
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.
great...
by
Mr Magoo
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.
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.
I've seen this work well
by
Deborah Hartmann
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.
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.
Re: I've seen this work well
by
Deborah Hartmann
Heck, I hate how line breaks are removed from our posts here. Gonna have a word with our tech team. :-)
Re: great...
by
Bruce Rennie
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.
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.
Re: I've seen this work well
by
Bruce Rennie
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.
Re: I've seen this work well
by
Vikas Hazrati
What about the other interesting part
has anyone seen that work?
Self Selection. The principle talks about the ability of an individual to have the maturity to conclude that Agile is not for him.
has anyone seen that work?
I agree...
by
Jason Little
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.
Sounds Like a Fraternity
by
Irakli Nadareishvili
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.
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.
Re: Sounds Like a Fraternity
by
Bruce Rennie
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.
Re: Sounds Like a Fraternity
by
Irakli Nadareishvili
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.
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.
Re: Sounds Like a Fraternity
by
Bruce Rennie
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.
Re: Sounds Like a Fraternity
by
Mr Magoo
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. :)
The army comparisons are especially good. :)
Has anyone seen that work?
by
J. B. Rainsberger
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.
Re: I've seen this work well
by
Deborah Hartmann
I've seen several people quit or request to move to other teams. Typically, we wish them well and everyone is happier - including them.
Re: Sounds Like a Fraternity
by
Deborah Hartmann
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 :-)
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 :-)
Sounds like
by
S Ninan
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.
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.
Re: Sounds Like a Fraternity
by
Irakli Nadareishvili
Mr Magoo,
it's all about money, ma friend, and anythin else is just child's play :)
it's all about money, ma friend, and anythin else is just child's play :)
Small realities
by
Andrea Maietta
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.
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.
Total Cost of Jerks (TCJ)
by
Deborah Hartmann
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
Re: Total Cost of Jerks (TCJ)
by
Deborah Hartmann
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.
