Skip to main content

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 the island," Survivor-style?


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.

From the hilarious blog post at:

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.

Popular posts from this blog

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else.

Here's what you should think about:

1.Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that:
a.You need your user experience people (if applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
WBABA: in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…