DistributedTeamPatterns describes ways to improve the functionality of DispersedTeams (those working at different job sites, often in different countries and/or timezones).  Here are ways to cripple it.  Some of these may or may not be AntiPattern''''''s depending on what you are trying to do (if entirely different product lines are located at different sites and the sites have no reason to communicate at other than management levels; many of these don't apply).

These practices are AntiPattern''''''s if it is your intent to have a distributed team working together on the same project or product line.

* PutThemInCompetition (for their jobs, especially).  Don't tell developers at site X how much more efficient the developers at site Y are (or how much harder they work, or how they make a fraction of what site X developers are paid).  

* AmbiguousRequirements.  Development methodologies (formal or informal) which require a great deal of context or HallwayConversations simply do not work for distributed teams--the context is just not there.