From http://en.wikipedia.org/wiki/Extreme_programming

Extreme Programming is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.

My Team Lead dislikes Extreme Programming as

  • May take more time to complete the project.
  • Increases initial cost (20% or more).
  • Constant interaction is tiresome.
  • Unit tests is hard for database, distributed and GUI.

Is there any evidence to support these claims about Extreme Programming or are these fabrications? What arguments can be made where Extreme Programming can actually be harmful to a team or project?

  • 6
    Don't do it? EP isn't the magic bullet for every situation. Maybe he is right for the kind of projects you do? Maybe pick parts of EP that would work and ignore other stuff? – thorsten müller Feb 21 '13 at 11:57
  • 1
    Does he propose something else in place? If it's a question of XP vs no organisation, than XP should be advocated vehemently. Otherwise, if for example your tech lead is proposing Agile Scrum instead, than he may have his reasons, you should see if, given his arguments (for his proposal), XP makes more sense or not. – Shivan Dragon Feb 21 '13 at 11:59
  • 3
    @MahbuburRAaman I undeleted and improved your question. I feel it is a much better question now. If you still disagree with my actions then go ahead and delete it again I will not reopen it a second time. – maple_shaft Feb 21 '13 at 12:05
  • 1
    @MahbuburRAaman: agreed, but as thorsten müller sais in the comment above, Agile in general and/or XP in prticular are not silver bullets. Does your tech lead prefer another project management paradigm, like maybe WaterFall or something a like? Also, here's a similar question, dealing with how to propose changes to the colegues/team/manager: programmers.stackexchange.com/questions/187702/… – Shivan Dragon Feb 21 '13 at 12:10
  • 3
    Ho to deal with a team member who is convinced that XP is a silver bullet? Have you tried to find out why, his reasons may well be correct for the business needs you have. – gbjbaanb Feb 21 '13 at 12:31
  1. Technically, there are 3 cases here. It may increase the time. It may not, and it may have no effect. Not trying to be flippant, but this is an unprovable condition. There are cases where switching to an Agile method saved the project. Likewise, there are cases where that switch killed the project. There are too many variables involved to make generalities at the level we're discussing. An assessment has to be made by those who know their current process best and evaluate whether XP (or any other methodology) is a good fit.

  2. This is true if you're not currently using XP. But this is true for any new methodology. There are start up costs associated with changing your development methodology. Employees need to be trained; management needs to be convinced; tooling needs to be modified; etc... XP is not a magical solution that waives away those transition costs.

  3. For introverts, this is very true. Pair Programming via XP is not for everyone.

  4. Unit tests are hard, period. It takes a commitment by the organization to create and maintain them. XP isn't a magical solution in this case either.

It doesn't really matter what the evidence is - your team lead has made up his mind. Forcing a confrontation and waiving published studies around will merely frustrate both you and him.

If you're committed to the benefits of XP, then you need to start adopting the methods that you can within your own work. When you start delivering higher quality work items faster than your peers, then your team lead may listen.

It's also worth noting that XP may be contraindicated for some industries. Defense sector work, for example, is very document / artifact heavy due to the contracts and multiple parties involved. XP and other Agile methods tend to be lighter on the documentation and therefore aren't appropriate. Likewise, projects that are being outsourced don't fit well with the Agile model as the requisite interaction for requirements gathering and verification simply aren't as easily accomplished.

I'm not trying to bash XP, it has it's value. But it's a tool and you have to know when it's appropriate to use that tool or not.

  • 2
    +1 If all you have is a hammer, everything starts to look like a nail. – Phil Feb 21 '13 at 14:33

With methodologies like XP and Agile, you are always going to get zealots on both sides, for and against.

With some people who are against, you may never change their mind.

So I would first of all think carefully about this, and evaluate realistically whether you think this person could ever be convinced.

Some battles are not worth fighting. Especially if you are for want of a better phrase "just a developer" - changing the whole software development process may be well outside your remit.

Instead, maybe go for the easy things that could help your dev team, pick and choose parts of XP you like and try and introduce them, instead of big bang trying to change the whole methodology.

If you still go ahead with trying to convince him, make sure you have well documented facts that answer/refute each of his concerns. Show that some of his concerns actually happen using your current methodology.


I don't know of any evidence proving adverse affects of extreme programming that would be usefully conclusive for XP teams in general. And proving them right might not be the most effective approach to influence change.

It's something that only experience and experimentation can demonstrate XP's effectiveness for the team as a whole.

The team lead sounds like they are understandably worried about XP's affect on 'velocity'. Take a look at Scrum (also the Scrum Guide is a very good introduction). Scrum focusses on the process of developing the product by breaking it into manageable chunks of product increment (called Sprints). This could be used to take XP/Agile practises (unit testing, pair programming) and prove to team leads/management that you can still maintain velocity whilst achieving increments in product. It would provide evidence over time that your team will spend less time fixing regression style bugs and more time on customer features.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.