Here is one of the XP2006 workshop antipatterns the group worked on.

Poor solution:
Individuals volunteer to refactor for the team

Forces:
Trying to take responsibility on behalf of the team
Some people do not refactor enough
Some people are afraid to refactor
Because they don’t know how to do it
Because they don’t want to change someone else’s code
It is faster for the one who knows how to refactor to just do it than teach the others
Only one person knows how to refactor or has good OO skills
Schedule pressure does not allow the team to practice/learn refactoring
“if it ain’t broke” attitude.

Consequences:
Top producer no longer produces (busy refactoring)
Never enough refactoring, never improves
Generates refactoring stories which have no acceptance criteria and no direct business value
Hides the real problem – “failing late”
People never learn the real value of refactoring

Example:
XP enthusiast introduces XP to a new team
Team starts to practice TDD, but doesn’t refactor enough
Team learns to refactor slowly
Leader feels pressure to produce and “leaves” simple design to go faster

Better solution:
Plan for the learning curve
Refuse to refactor along
Remember to refactor only to implement a story
Don’t accept story submissions with obvious design smells
Review more until refactoring improves.

Exceptions:
Team made up of contractors
Short product lifecycle (maybe)
Single use utility