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.

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.