• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
  • Tim Holloway
  • Carey Brown
  • salvin francis

XP: Reform or Fire

Posts: 26
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In XP, we are supposed to 'reform cowboy programmers or fire them'. It seems to be difficult to carry out the firing part in the US due to the many laws and HR policies in place. Does anyone have any experience/suggestions in dealing with this situation?
Posts: 11962
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you spare developers into more than one team? It's not the best thing for the sense of belonging, but forming two separate teams (one XP, the other not) would let at least one team go fast.

If you can't do that, or you believe it's too risky, you could try to compromise agility by letting the non-XPers do architectural spikes, acceptance tests, etc. on their own. The compromising part comes from the reality that since the lone wolves don't participate in the flow of information as actively as the rest of the team (pair programming), you probably need to add a bit more documentation (for internal communication, not for documenting the software for external parties) into the mix.

Someone recently asked a similar question in the XP Yahoo! group -- you might want to browse the archive for a while...
Posts: 1332
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can fire people if you can document why you are firing them, especially if you give them a chance to fix their behavior first. That means identifying the counterproductive behavior to them - preferably in writing as well as verbally - and giving them a period of time, maybe a couple months, to fix it. Make sure you include a brief justification of why the problems are counterproductive in the context of your work environment. Then, after the period of time has passed, if they haven't changed their behavior, you should cite in writing why they are being released, citing specific, verifiable instances of where they haven't done what you told them to do. For example, if a problem is that they checked in stuff before running the tests, make sure you can demonstrate that the code state after their checkin fails tests. You also need to make sure that their behavior wasn't generally accepted of employees who weren't fired.

In the case of xp nonconforming behavior, you might also explain to them that the behavior they are engaging in doesn't necessarily make them a bad programmer, it's just a problem for your particular work environment because of your organization's commitment to XP. Taking a more supportive attitude is more likely to elicit cooperation, and even if it doesn't, it's more likely to result in a parting without rancor.
Willie Smits increased rainfall 25% in three years by planting trees. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!