Jeremy D. Miller -- The Shade Tree Developer

EDIT:  Ayende's Anti Team additions is funnier than mine. 

We talk a lot about how to structure great teams -- defining team roles and the qualities that we want team members to have.  Just out of pure mischief, and to fill a request from a friend, let's turn this around and I'll describe my vision of the worst possible team role structure.  Just in case you're wondering, this is an amalgam of a lot of different projects over the course of this decade and is not pointed at anybody in particular (ok, that's a bald-faced lie.  How about not pointed at anyone that is likely to be reading this).  Here you go, my Bizarro team-->

• Non-coding Architect:  I fully believe that I can do a much better job designing and architecting software as a developer involved in the day to day construction of the code than a non-coding architect of equivalent skill.  Put it another way, designs get better faster when the designer has to feel the pain from clunky designs and adapts to alleviate that pain.  And frankly, I haven't come across too many non-coding architect's that had strong design skills when it came time to do detailed work.  You might say to me that the architect's job is simply the high level architecture and that the tech lead or developers should fill in the fine grained details.  I think that's mostly bunk because the fine grained "details" have an awfully lot to do with what the architecture should be in the first place.  I think the non-coding (or Powerpoint) architect position is a refuge for scoundrels.  Non-coding Architect is an order of magnitude worse when he/she is a member of a centralized architecture team that is the "keeper of the flame" for the enterprise architecture.  Traveling in packs reinforces the worst tendencies of Non-coding Architect guy.  For the sake of full disclosure, I was briefly a non-coding architect and have often clashed with non-coding architects.
• "Spec" Coder:  The coder who will faithfully muddle through whatever design specification you put in front of him without deviation.  He's useless without a spec, because that's just not his job to design.  Much worse in my mind is the fact that "Spec" Coder will code without thinking or providing feedback to whomever is doing the design.  Non-coding architect plus spec coder is the worst possible project team permutation.  Being a "spec" coder is a fate that you need to avoid.  It's not a particularly fulfilling role, and the job security is not great.
• UI Guy/Middle Tier Guy/Database Guy:  Dividing a team by horizontal layers has to be the worst possible developer team structure.  Too much specialization in a team is a bad, bad thing because your team becomes brittle when people specialize.  Think about this very realistic scenario, iteration #1 involves a lot of user interface programming but iteration #2 is almost completely about the backend.  Do you really want the backend developers idle in iteration #1 and the GUI folks idled in iteration #2.  When I'm a technical lead I've always found it more difficult to deal with specialists because their focus is so narrow.  I've always thought that specialists need a lot more hand holding to perform development tasks because they so frequently don't understand the context.  I'm a huge believer in "whole team" mechanics and purposely blurring project roles. 
• Legacy Guy:  AKA, the "Bottleneck."  You've got to talk to the legacy code at some point, or even worse, modify it.  This guy is the one guy in the entire company who knows how to sacrifice animals correctly to change the legacy application.  He's spread across many different projects with the same needs, so getting his attention is always difficult.  Making matters worse, he usually doesn't speak the same language you do, and the cultural referents between the way he builds code and the way you do are very sparse.
• Microsoft Project Project Manager:  This is the Project Manager whose world is completely bounded by and shaped by his Microsoft Project file.  Besides being extremely annoying, MPPM is completely incapable of adapting to changing conditions or even understanding that conditions are changing.  MPPM's primary tool is the "embarrassment meeting" where the entire team gives their actuals and gets called down on the carpet one at a time to be balled out for missing the original estimate.  Personally, I want my PM to be a road grader that gets out ahead of us and eliminates road blocks.  MPPM doesn't get that proactive style of management because they're too focused on the trappings of project management.  When I was an engineer on large petrochemical projects (250+ million), project controls and scheduling was a separate function from project management.  There might be something to that.
• Out of Sight Testers:  Testers who are very isolated from the rest of the development team, usually coming onto the project at the very last moment.  I know that some people are adamant that the testers must be independent of the developers to the point of being completely isolated, but think of the cost.  Testing is about removing defects, and that is going to be much faster when the developers and testers are corroborating very closely.  Developers can fix bugs faster when the testers demonstrate the reproduction steps and test automation efforts go much smoother with developer involvement.  Think on this too, when you use waterfall testing you always have a ramp up time for the testers to understand the system, and you *always* tussle with the testers because they arrive at very different interpretations of the specifications than the development team did.  You can dramatically cut down that mismatch in understanding by having the developers and testers working together throughout the project.  Moving testers offsite is even worse.
• Func'ky Spec Business Analyst:  The BA's that drop off a specification document and then disappear.  Any requests for clarification are automatically addressed by "didn't you read the spec?"  Grrrrrr.
• Disinterested or Hostile Customer:  One way or another they're either paying for the project or they've got a large stake in the project's success, but they aren't the slightest bit interested in helping you.  Disinterested customer just doesn't want to be involved in the software.  Hostile customer thinks the best way to succeed is to administer regular beatings to the development team.
• The Process Cop:  Somewhere, there's a group that is in complete charge of determining and enforcing the Process that all development teams will use.  They don't have to dogfood their own process, so they've got no incentive whatsoever to streamline things.  Chances are very likely that they haven't ever used the Process, but they've been to lot's of conferences.  They're also not particularly interested in your input, because that threatens their job.  One of many things that bugs me about CMMI is the Process Cop team.
• Agile Zealot:  Yep, I'm willing to bomb on my side too.  Most of the antipattern role definitions are a side effect of bad waterfall thinking, but a truly dogmatic Agile Zealot is eXtremely unpleasant to work with.  If your judgement of right or wrong approaches is completely based on what's more XPish, you're likely to make bad judgement calls.  Actually, for that matter, XP or Scrum generally encourages and requires a very adaptive approach to how the team performs it's work.  If you turn off the adaptive aspect of XP/Scrum you've lost most of the advantages.