InfoQ

News

Voting Someone Off the Island on an Agile Team

Posted by Vikas Hazrati on Jun 26, 2008 03:44 PM

Community
Agile
Topics
Agile in the Enterprise ,
Collaboration ,
Teamwork
Tags
Interpersonal Communication ,
Self-organizing Team

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.

  • This article is part of a featured topic series on Collaboration

21 comments

Reply

Same as it ever was by Kurt Christensen Posted Jun 26, 2008 4:30 PM
great... by Mr Magoo Posted Jun 26, 2008 4:51 PM
Re: great... by Bruce Rennie Posted Jun 27, 2008 1:52 PM
I've seen this work well by Deborah Hartmann Posted Jun 26, 2008 6:35 PM
Re: I've seen this work well by Deborah Hartmann Posted Jun 26, 2008 6:36 PM
Re: I've seen this work well by Bruce Rennie Posted Jun 27, 2008 1:58 PM
Re: I've seen this work well by Vikas Hazrati Posted Jun 27, 2008 2:12 PM
Has anyone seen that work? by J. B. Rainsberger Posted Jun 30, 2008 9:15 PM
Re: I've seen this work well by Deborah Hartmann Posted Jul 1, 2008 6:44 AM
I agree... by Jason Little Posted Jun 27, 2008 10:23 PM
Sounds Like a Fraternity by Irakli Nadareishvili Posted Jun 28, 2008 11:52 AM
Re: Sounds Like a Fraternity by Bruce Rennie Posted Jun 29, 2008 10:52 AM
Re: Sounds Like a Fraternity by Irakli Nadareishvili Posted Jun 29, 2008 12:43 PM
Re: Sounds Like a Fraternity by Bruce Rennie Posted Jun 29, 2008 6:21 PM
Re: Sounds Like a Fraternity by Mr Magoo Posted Jun 29, 2008 7:27 PM
Re: Sounds Like a Fraternity by Irakli Nadareishvili Posted Jul 3, 2008 2:18 AM
Re: Sounds Like a Fraternity by Deborah Hartmann Posted Jul 1, 2008 6:52 AM
Sounds like by S Ninan Posted Jul 2, 2008 8:41 AM
Small realities by Andrea Maietta Posted Jul 3, 2008 3:58 AM
Total Cost of Jerks (TCJ) by Deborah Hartmann Posted Jul 17, 2008 7:39 AM
Re: Total Cost of Jerks (TCJ) by Deborah Hartmann Posted Jul 17, 2008 7:40 AM
  1. Back to top

    Same as it ever was

    Jun 26, 2008 4:30 PM 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.

  2. Back to top

    great...

    Jun 26, 2008 4:51 PM 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.

  3. Back to top

    I've seen this work well

    Jun 26, 2008 6:35 PM 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.

  4. Back to top

    Re: I've seen this work well

    Jun 26, 2008 6:36 PM by Deborah Hartmann

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

  5. Back to top

    Re: great...

    Jun 27, 2008 1:52 PM 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.

  6. Back to top

    Re: I've seen this work well

    Jun 27, 2008 1:58 PM by Bruce Rennie

    I, too, have seen this work.
    <p>
    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".
    <p>
    Senior management trusted the team so much, the person was transferred off the team the same day. </p></p>

  7. Back to top

    Re: I've seen this work well

    Jun 27, 2008 2:12 PM by Vikas Hazrati

    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.


    has anyone seen that work?

  8. Back to top

    I agree...

    Jun 27, 2008 10:23 PM 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.

  9. Back to top

    Sounds Like a Fraternity

    Jun 28, 2008 11:52 AM 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.

  10. Back to top

    Re: Sounds Like a Fraternity

    Jun 29, 2008 10:52 AM 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.
    <p>
    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.
    <p>
    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.

    </p></p>

  11. Back to top

    Re: Sounds Like a Fraternity

    Jun 29, 2008 12:43 PM 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.

  12. Back to top

    Re: Sounds Like a Fraternity

    Jun 29, 2008 6:21 PM by Bruce Rennie

    I beg to disagree with virtually all of your points, with all due respect.
    <p>
    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.
    <p>
    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.
    <p>
    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.

    </p></p></p>

  13. Back to top

    Re: Sounds Like a Fraternity

    Jun 29, 2008 7:27 PM 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. :)

  14. Back to top

    Has anyone seen that work?

    Jun 30, 2008 9:15 PM 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.

  15. Back to top

    Re: I've seen this work well

    Jul 1, 2008 6:44 AM 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.

  16. Back to top

    Re: Sounds Like a Fraternity

    Jul 1, 2008 6:52 AM 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 :-)

  17. Back to top

    Sounds like

    Jul 2, 2008 8:41 AM 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.

  18. Back to top

    Re: Sounds Like a Fraternity

    Jul 3, 2008 2:18 AM by Irakli Nadareishvili

    Mr Magoo,

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

  19. Back to top

    Small realities

    Jul 3, 2008 3:58 AM 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.

  20. Back to top

    Total Cost of Jerks (TCJ)

    Jul 17, 2008 7:39 AM 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

  21. Back to top

    Re: Total Cost of Jerks (TCJ)

    Jul 17, 2008 7:40 AM 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.

Exclusive Content

Diary of a Fence Sitting SOA Geek

In this presentation, Mark Little explains the history of SOAP/WSDL/WS-*-based web services and RESTful HTTP and highlights how the two approaches might converge into a single solution.

Flex for XML and JSON

Platforms need interoperability. In this article Flex interoperability with JSON and XML is explored including direct mapping to chart and grid components.

Measuring Agile in the Enterprise: 5 Success Factors for Large-Scale Agile Adoption

Michael Mah analyzes the development process in 5 companies: 2 Agile (one of them BMC) and 3 classic. He presents the factors which contributed to the success of BMC's Agile adoption.

Tom Preston-Werner on Powerset, GitHub, Ruby and Erlang

In this interview filmed at RubyFringe 2008, Tom Preston-Werner talks about how both Powerset and GitHub use Ruby and Erlang, as well as tools like Fuzed, god, and more.

David Laribee on Alt.NET and its Mission

David Laribee discusses the purpose of ALT.NET, its mission and future.

Discover RailsKits and Stop Writing Redundant Code

Ruby on Rails has become a popular Ruby framework for creating web applications in recent years. An aspect of creating a web application is the need to repeatedly create the same base functionality.

A Formal Performance Tuning Methodology: Wait-Based Tuning

Steven Haines talks about tackling web application performance tuning by proposing a method called wait-based tuning.

Shaw and Fowler About Forging a New Alliance

Shaw and Fowler talk about the need for a new relationship between the business department and the IT department. Studies have shown that projects mostly fail due to miscommunication between the two.