How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!  I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.).

Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messaging as the last resort.  And because this is new to all of you, you will feel stressed out, and you will not be at your best.  I guarantee that your first thought is going to be:  "how do I vote someone off?"

When this thought occurs to me, and I am sad to admit that it does occasionally, I always turn first to Mike Cohn's blog post on "Removing Team Members."  As Cohn says, no, you don't get to vote members off.  All of the great things that you are going to do as a team are purposely set up for you by management, following the Glenda Eoyang "CDE Model" of

• Constraint (team members, room, time frame, budget), 
• Differences between team members to generate productive discussions, and 
• Exchanges, which is where the real work gets done.

So the decision to remove one or more team members from a team is always a management decision, not a team decision.

What is good about this?

• Agile Zealots will tell you that in most cases, the self-organizing team frees you to do the right things in the right way.  Software developers of the world, unite into 8-10 person teams and throw off your TPS report cover sheets!  Spend your time doing something worth while! This is the real reason you should be cautious about removing people too frivolously.  Additionally, though,
• Research shows that once you get over the "storming" part and move on to "norming" and "performing," your agile team is actually less likely to generate a "social loafing" problem than its waterfall counterpart.  In other words, collocation, information radiators, quick feedback, and other agile practices create teams with fewer "free riders," and less of a "sucker effect," where people don't work because they see that nobody else is.
• Finally, empirically, you're likely to vote off the best collaborators first, because they "make the rest of you look bad."  Sad but true.  Agile team members are humans first.

So it's a good thing you can't vote anyone off.
 

But let's say things aren't going as planned.  Let's say you are saddled with one or more person on the team who is toxic in some way.  You wonder who they are blackmailing and for what, given that there seems to be no other reason for them to keep their job.  As a team, you quickly notice at the daily stand-up meetings that this person does not make progress on a day to day basis.  What is she doing, you all wonder, silently, then aloud to each other over beers and non-alcoholic equivalents.

Your scrum master is on the lookout for team problems, and he talks with the person's manager.  The manager explains that Ms. Mooch is "new," although others on the team were hired much more recently.  Can you really be "new" longer than a couple of months, your scrum master asks.  The manager reiterates that this employee is "new," and explains condescendingly that since this is an agile team, this one tiny questionable staffing decision should be no problem.  "An agile team," this manager declares, "should be like a 'family' where the 'strong ones carry the weak ones.'"

Okay, stop right there, Father Flanagan.  This is not a family.  "She ain't heavy, she's my sister" doesn't play here.  This is a work place.  Agile is not an excuse to force the strong to carry the weak.  That is cynical and it is just wrong.  There's a difference between "diverse" and "incapable," and don't let anyone tell you otherwise.  Just as it's management's prerogative to support agile by providing support to teams through carefully balanced constraints, differences, and exchanges, it is also a management responsibility to remove toxic people from the team as soon as it appears that there are serious problems.

That said, however, what do you do back on the Island of Misfit Toys once management shoots you down and asks you not to come back unless you have a REAL problem?  The same thing you would do on a waterfall team:  isolate and document.  Track each task the problem person commits to or has assigned, and whether it gets done correctly and on time.  If necessary, do the same tracking for the rest of the team to show you're not singling anyone out unfairly.  Once you can document a pattern, and you will be able to, then report and escalate the pattern to whatever level of management it takes.  It's no fun, but it's the only way.  Even on an agile team.

This post is from Pragmatic Agilist by Elena Yatzeck. Click here to see the original post in full.